Chose Language:
Author: Admin/Publisher |finished | checked

How to prevent XSS attacks

In this post, we will see how to prevent XSS attacks, we will see how to partially avoid attacks of this nature on the Front-End, and we will see what we must do on the Back-End side.

Introduction

What is an XSS attack?

The acronym XSS stands for Cross-Site Scripting. What is this? It can be said that it is a type of injection very similar to SQL injection except that this time they will try to save script code on our website. Generally, this code is written in JavaScript or it can also be HTML that redirects to another website to carry out phishing.

Some examples of attacks that can be done to your site:

Redirección del Usuario
<script>
   window.location.href = 'http://sitio-malicioso.com';
</script>
Robo de Cookies
<script>
   var cookies = document.cookie;
   // Enviar cookies a un servidor controlado por el atacante
</script>
Keylogging
<script>
   document.onkeypress = function(e) {
       // Enviar las teclas presionadas a un servidor controlado por el atacante
   };
</script>
Manipulación del DOM
<script>
   document.getElementById('elemento').innerHTML = 'Contenido malicioso';
</script>

There are other attacks such as phishing and placing advertisements on your site without your consent.

Front-End

In the Front-End, it is recommended to separate your HTML from your JavaScript, so there should not be inline JavaScript codes.

The following code class should not be in your front-end.

inline-code
<button onclick="miFuncion()">Haz clic</button>
Javascript dentro del HTML tambien es considerado inline
<script>codigo de javascript</script>

Instead, something similar to the following is recommended.

tu boton
<button id="miBoton">Haz clic</button>
en tu archivo .js
<script>
  document.getElementById("miBoton").addEventListener("click", miFuncion);
</script>

Now what you should do is configure your CSP to not allow inline code and other settings you want, for example, not allowing the execution of scripts from other pages except those from Google, as we will need Google to register our page.

You can learn more about Content Security Policy (CSP) in PHP.

Back-End

In the Back-End, however, although we have practically prevented the attack, we should escape the user input. In PHP, for example, you can use the htmlspecialchars() function, although it is even more recommended to use filters.

filtros
$user_input = $_POST['user_input'];

// Escapar los datos ingresados por el usuario utilizando el filtro FILTER_SANITIZE_SPECIAL_CHARS
$escaped_input = filter_var($user_input, FILTER_SANITIZE_SPECIAL_CHARS);


// Sanitizar los datos ingresados por el usuario(eliminara los caracteres no seguros)
$sanitized_input = filter_var($user_input, FILTER_SANITIZE_STRING);

Although you can do this, it is even more recommended to create a validation class to validate that the input meets the requirements, for example, verifying if it is an email, if it is a number, etc., and in addition to that, sanitize it with the filters previously seen.

Sometimes we might want the user to be able to input HTML code, but not any HTML code, for example: the <script>, <object> tags, and some others.

To do this, you can use the PHP library HTMLPurifier.

Category: en-javascript
Something wrong? If you found an error or mistake in the content you can contact me on Twitter | @luisg2249_luis.
Last 4 post in same category