Métodos de prevención de XSS, formas, maneras.Recuerde que un ataque XSS es un tipo de inyección de código: la entrada del usuario se interpreta erróneamente como un código de programa malicioso. Para evitar este tipo de inyección de código, se necesita un manejo de entrada seguro. Para un desarrollador web, hay dos formas fundamentalmente diferentes de realizar un manejo de entrada seguro:
- Codificación , que escapa a la entrada del usuario para que el navegador la interprete solo como datos, no como código.
- Validación , que filtra la entrada del usuario para que el navegador lo interprete como un código sin comandos maliciosos.
Si bien estos son métodos fundamentalmente diferentes para prevenir el XSS, comparten varias características comunes que es importante entender al usar cualquiera de ellos:
Contexto
El manejo seguro de la entrada se debe realizar de manera diferente dependiendo de dónde se inserta la entrada del usuario en una página.
Entrada/salida
El manejo seguro de la entrada se puede realizar ya sea cuando su sitio web recibe la entrada (entrante) o justo antes de que su sitio web inserte la entrada en una página (saliente).
Servidor de cliente
El manejo seguro de la entrada se puede realizar en el lado del cliente o en el lado del servidor, los cuales son necesarios en diferentes circunstancias.
Codificación
La codificación es el acto de escapar de la entrada del usuario para que el navegador la interprete solo como datos, no como código. El tipo más reconocible de codificación en el desarrollo web está escapando HTML, que convierte los caracteres como en <y >, respectivamente.
El siguiente pseudocódigo es un ejemplo de cómo una entrada de usuario se puede codificar utilizando el escape HTML y luego se inserta en una página mediante una secuencia de comandos del lado del servidor:
print "<html>"
print "Latest comment:"
print database.latestComment
print "</html>"
Si la entrada del usuario fuera la cadena: «<script>...</script>«, el HTML resultante sería el siguiente:
<html>
Latest comment:
<script>...</script>
</html>
Debido a que todos los caracteres con significado especial se han escapado, el navegador no analizará ninguna parte de la entrada del usuario como HTML.
Al realizar la codificación en su código del lado del cliente, el lenguaje utilizado es siempre JavaScript, que tiene funciones integradas que codifican datos para diferentes contextos.
Al realizar la codificación en el código del lado del servidor, confía en las funciones disponibles en el lenguaje o marco del lado del servidor. Debido a la gran cantidad de idiomas y marcos disponibles, este tutorial no cubrirá los detalles de la codificación en ningún lenguaje o marco específico del lado del servidor. Sin embargo, la familiaridad con las funciones de codificación utilizadas en el lado del cliente en JavaScript también es útil al escribir código del lado del servidor.
Validación
La validación es el acto de filtrar la entrada del usuario para que se eliminen todas las partes malintencionadas, sin eliminar necesariamente todo el código que contiene. Uno de los tipos de validación más reconocibles en el desarrollo web es permitir algunos elementos HTML (como <em>y <strong>) pero no permitir otros (como <script>.
Existen dos características principales de validación que difieren entre las implementaciones:
Estrategia de clasificación
La entrada del usuario se puede clasificar utilizando listas negras o listas blancas.
Lista negra
Instintivamente, parece razonable realizar una validación definiendo un patrón prohibido que no debería aparecer en la entrada del usuario. Si una cadena coincide con este patrón, se marca como no válida. Un ejemplo sería permitir que los usuarios envíen direcciones URL personalizadas con cualquier protocolo excepto javascript:. Esta estrategia de clasificación se llama lista negra . No obstante suele resultar complejo y es preciso estarla actualizando para prevenir sorpresas indeseables como que el navegador se actualice.
Lista blanca
La lista blanca es esencialmente lo opuesto a la lista negra: en lugar de definir un patrón prohibido, un enfoque de lista blanca define un patrón permitido y marca el ingreso como inválido si no coincide con este patrón.
Esto resulta mucho más sencillo y longevo (de larga duración).
Resultado de la validación
La entrada de usuario identificada como malintencionada puede ser rechazada o saneada.
Resultado
Cuando la entrada se ha marcado como no válida, se puede realizar una de dos acciones:
Rechazo
La entrada simplemente se rechaza, evitando que se use en otros lugares del sitio web.
Desinfección
Se eliminan todas las partes no válidas de la entrada y el sitio web utiliza normalmente la entrada restante.
De estos dos, el rechazo es el enfoque más simple de implementar. Dicho esto, la desinfección puede ser más útil, ya que permite una mayor variedad de comentarios del usuario. Por ejemplo, si un usuario envía un número de tarjeta de crédito, una rutina de desinfección que elimine todos los caracteres que no sean dígitos evitará la inyección de código y permitirá que el usuario ingrese el número con o sin guiones.
Si decide implementar la desinfección, debe asegurarse de que la rutina de desinfección en sí misma no utilice un enfoque de lista negra .
¿Qué técnica de prevención utilizar?
La codificación debe ser su primera línea de defensa contra XSS, ya que su propósito es neutralizar los datos para que no puedan interpretarse como código. En algunos casos, la codificación debe complementarse con la validación, como se explicó anteriormente. Esta codificación y validación deben ser salientes, porque solo cuando la entrada se incluye en una página, usted sabe para qué contexto codificar y validar.
Como segunda línea de defensa, debe usar la validación de entrada para sanear o rechazar datos que son claramente inválidos, como los enlaces que usan el protocolo javascript:. Si bien esto no puede por sí solo proporcionar una seguridad total, es una precaución útil si en algún punto la codificación y la validación de salida se realizan incorrectamente debido a errores o equivocaciones.
Si estas dos líneas de defensa se usan de manera consistente, su sitio web estará protegido de los ataques XSS. Sin embargo, debido a la complejidad de crear y mantener un sitio web completo, puede ser difícil lograr una protección completa utilizando solo el manejo de entrada seguro. Como tercera línea de defensa, también debe hacer uso de la Política de seguridad de contenido (CSP), que describiremos a continuación.
Política de seguridad de contenido (CSP)
La desventaja de proteger contra XSS utilizando solo el manejo seguro de entrada es que incluso un solo lapso de seguridad puede comprometer su sitio web. Un estándar web reciente llamado Política de seguridad de contenido (CSP) puede mitigar este riesgo.
CSP se utiliza para restringir el navegador que visualiza su página, de modo que solo puede utilizar los recursos descargados de fuentes confiables. Un recurso es un script, una hoja de estilo, una imagen o algún otro tipo de archivo al que hace referencia la página. Esto significa que incluso si un atacante logra inyectar contenido malicioso en su sitio web, el CSP puede evitar que se ejecute.
CSP se puede utilizar para hacer cumplir las siguientes reglas:
- No hay fuentes no confiables
Los recursos externos solo se pueden cargar desde un conjunto de fuentes confiables claramente definidas. - No hay recursos en línea
- Inline JavaScript y CSS no serán evaluados.
- No eval. La función
evalde JavaScript no se puede utilizar.
Leer también: ¿Qué es lo peor que puede hacer un atacante con JavaScript? ; ¿Qué es JavaScript malicioso? Consecuencias ; Consecuencias de un ataque XSS, daños
This post is also available in:
Español
