XSS es una forma de inyección de código, es decir, el atacante logra inyectar su propio código malicioso (generalmente JavaScript) en el código de confianza (HTML, CSS, JavaScript) proporcionado por el sitio. Es similar a SQLi en el sentido de que está causado por un código construido dinámicamente, es decir, sentencias SQL, páginas HTML, etc.

Pero aunque existen técnicas establecidas para resolver SQLi (es decir, usar el enlace de parámetros), es aún más difícil con XSS. Para defenderse contra XSS, todas las entradas controladas por el usuario deben escaparse correctamente, lo cual es mucho más difícil de lo que parece:

• Las reglas de escape dependen del contexto, es decir, HTML, atributo HTML, XHTML, URL, script, contextos CSS tienen diferentes reglas de escape.
• Estos contextos se pueden anidar, es decir, algo como <a href=javascript:XXX > es un contexto de JavaScript dentro de un contexto de URL dentro de un atributo HTML.
• Además de eso, tiene reglas de codificación para los caracteres (UTF-8, UTF-7, latin1, ...) que, de nuevo, pueden ser específicos del contexto.
• El contexto y la codificación deben ser conocidos al construir el resultado: aunque la mayoría de los motores de plantillas admiten el escape correcto de HTML, a menudo no son conscientes del contexto circundante y, por lo tanto, no pueden aplicar las reglas de escape específicas del contexto.
• Además de eso, los navegadores pueden comportarse de forma ligeramente diferente en relación con el escape o la codificación.
• Aparte de eso, a menudo encontrará en el código desarrollado sin una separación adecuada de lógica y presentación que los fragmentos de HTML se almacenen en la base de datos y no siempre está claro para el desarrollador si un valor específico ya está limpio de HTML o si es necesario ser escapado.

Y aunque hay algunas formas sencillas de protegerse contra XSS por diseño (especialmente la Política de seguridad de contenido), estas solo funcionan con los navegadores más nuevos, tienen que ser activadas explícitamente por el desarrollador y, a menudo, solo son efectivas después de grandes (y costosas) cambios en el código (como eliminar el script en línea).

Pero aún así, hay una buena posibilidad de hacerlo correctamente si tienes desarrolladores con los conocimientos adecuados y puedes comenzar desde cero utilizando los modernos kits de herramientas que ya se ocupan de XSS. Desafortunadamente, en muchos casos hay un código heredado que solo necesita seguir trabajando. Y el desarrollo normalmente lo hacen los desarrolladores que no conocen XSS en absoluto o no conocen todos los escollos.

Y mientras el desarrollo web se realice en entornos muy sensibles al costo y al tiempo, es muy probable que esto cambie. El objetivo en este entorno es hacer que el código funcione en poco tiempo y con pequeños costos. Las compañías generalmente compiten por características y tiempo de comercialización y no por quién como el producto más seguro. Y la protección XSS en la actualidad solo implica costos adicionales sin beneficios obvios para muchos gerentes.

Parece fácil, pero es difícil

En primer lugar, la superficie de ataque es enorme. Debe tratar con XSS si desea mostrar la entrada del usuario en HTML en cualquier lugar. Esto es algo que casi todos los sitios hacen, a menos que se creen puramente en HTML estático.

Combine esto con el hecho de que si bien XSS puede parecer fácil de tratar, no lo es. La hoja de trucos de prevención OWASP XSS tiene 4 000 palabras. Necesitas una hoja bastante grande para encajar todo ese texto.

La complejidad surge porque XSS funciona de manera diferente en diferentes contextos. Debe hacer una cosa si está insertando datos no confiables en JavaScript, una cosa si inserta en los valores de los atributos, otra cosa si inserta entre etiquetas, etc. OWASP enumera seis contextos diferentes que todos necesitan reglas diferentes, más una serie de contextos. donde nunca debes insertar datos.

Mientras tanto, los desarrolladores siempre están buscando panaceas y balas de plata. Quieren eliminar todo el trabajo duro a una sola función sanitize() a la que siempre pueden llamar datos no confiables, llamarlos un día y continuar con la programación real. Pero mientras muchas de estas funciones han sido codificadas, ninguna de ellas funciona.

Permítame repetir: XSS puede parecer fácil de tratar, pero no lo es. El peligro principal está en la primera parte de esa oración, no en la segunda. La simplicidad percibida anima a los desarrolladores a crear sus propias soluciones elaboradas en casa: sus propias funciones personalizadas de sanitize() , llenas de generalizaciones, listas negras incompletas y suposiciones erróneas. Ha filtrado javascript: en las URL, pero ¿pensó en vbscript: ? ¿O javaSCripT : ? Codificó comillas, pero ¿recordó incluir el valor del atributo entre comillas? ¿Y qué pasa con las codificaciones de caracteres?

La situación es bastante similar a SQLi. Todos seguían buscando la única función de saneamiento para gobernarlos a todos, ya sea que se llamen addslashes , mysql_escape_string o mysql_real_escape_string . Es la seguridad del culto de la carga, donde la gente piensa que es suficiente con llamar ritualmente a la función correcta para apaciguar a los dioses, en lugar de abrazar la complejidad del problema.

Entonces, el peligro no es que los desarrolladores no estén al tanto de XSS. Es que piensan que lograron controlar la situación, porque oye, programé una función para ello.

Pero, ¿por qué es difícil?

La web tiene el problema de que la estructura (HTML), la presentación (CSS) y la dinámica (JavaScript) se mezclan en largas cadenas de texto que colocamos en los archivos .html . Eso significa que hay muchos límites que puede cruzar para moverse de un contexto a otro.

De nuevo, esto es lo mismo que con SQLi. Allí se mezclan las instrucciones y los valores de los parámetros en una cadena. Para detener SQLi, descubrimos que tenemos que separar los dos completamente y nunca mezclarlos, es decir, utilizar consultas parametrizadas.

La solución para XSS es similar:

1. Separe los scripts del HTML.
2. Desactive los scripts en línea en el HTML.

Creamos una forma fácil de hacer la segunda parte: Política de seguridad de contenido . Todo lo que necesitas hacer es establecer un encabezado HTTP. Pero la primera parte es dura. Para una aplicación web antigua, una reescritura completa podría ser más fácil que desenredar quirúrgicamente las secuencias de comandos del HTML. Entonces, es más fácil simplemente confiar en esa magia sanitize() y esperar lo mejor.

Pero la buena noticia es que las aplicaciones más nuevas a menudo se desarrollan después de principios más estrictos, es posible el uso de CSP, y casi todos los navegadores lo admiten ahora. No estoy diciendo que vamos a reducir el porcentaje de sitios vulnerables al 0%, pero tengo la esperanza de que caiga mucho del 60% en los próximos años.

TL; DR: Esto se convirtió en una perorata bastante larga. No estoy seguro de si hay mucha información útil aquí, solo lea la excelente respuesta de Steffen Ullrich si desea un análisis claro.

Mi conjunto de opiniones sobre seguridad y XSS:

1. Regla de programación: No puedes saberlo todo. Tarde o temprano vas a cometer un error.
2. Regla del programador: un programador trabaja 12 horas al día: 3 está discutiendo con otros programadores cosas al azar, 3 está pensando en otras cosas, 3 está discutiendo sobre qué debería codificar, 3 está programando ... los proyectos están hechos para 12h al día de programación casi sin parar.
3. XSS es simple. Y hay una gran cantidad de entradas que esperan por XSS.
4. La seguridad sigue siendo la última y la mayoría de las veces se considera deficiente.

Como se mencionó en la respuesta a una publicación similar tuya ( la inyección de SQL tiene 17 años. ¿Por qué sigue existiendo? ):

  

No hay una solución general para SQLi porque no hay una solución para la estupidez humana

Los desarrolladores a veces se vuelven perezosos o descuidados y eso hace que no verifiquen la aplicación que están desarrollando.

Otra razón popular es que los desarrolladores no están conscientes de que hay un problema de seguridad. Nunca pasaron por un entrenamiento de seguridad y, por lo tanto, no saben qué es una amenaza de seguridad potencial y cuál no. Y para las empresas que no entienden que una prueba de penetración es importante, esta falta de conocimiento de seguridad es una amenaza potencial por sí misma.

Los problemas de seguridad simples, como SQLI y XSS, solo se solucionarán cuando una empresa decida dedicar tiempo a revisar y probar el código. Hasta entonces, tiene el 65% de todos los sitios web que sufren la vulnerabilidad XSS en todo el mundo.

El problema de la raíz

La web simplemente no fue diseñada para permitir una autoría múltiple o una interacción enriquecida. Nadie habló de separar el contenido de la presentación hasta finales de los años noventa. En ese momento, al igual que el teclado QWERTY, estábamos básicamente atascados sin una buena razón con un sistema existente. Nadie quería "romper la red", por lo que los errores se copiaron y se adaptaron a los navegadores más allá del "vector principal".

El factor agravante

Antes del ~ 2005, prácticamente todo lo que viste en un sitio web determinado fue creado o aprobado por las personas que controlan el sitio. A medida que avanzaba el movimiento "Web2.0" y la gente exigía interacción (¡al menos agregue comentarios, venga!), La presión para agregar estas funciones a los sitios existentes fue excelente. La gente de la red hizo lo que pudo para satisfacer las demandas de los jefes de cumplir una tarea que no conocían: interacción segura. Y por un tiempo, probablemente demasiado largo, se salieron con la suya. ¿Cuántas personas compran alarmas burgler antes en las que incluso se han introducido?

Tiempos modernos

El uso de un CSP reducirá en gran medida el potencial de daño de lanzar otra bola. Eso no significa que deba renunciar a la validación y el saneamiento de ninguna manera, debido a las copias de Guardar como .., guardadas en caché sin encabezados, etc., pero significa que puede estar MUCHO más seguro con un par de horas de esfuerzo. Sí, el encabezado es largo y tiene un formato confuso al principio, pero invierta la hora o dos que se necesitan para asimilar, y las pocas más que se necesitarán para probar su sitio. CSP es realmente fácil de probar ya que puede hacer una ejecución silenciosa de advertencia solamente (búsquelo).

Si haces un CSP y tomas las medidas tradicionales, esos viejos navegadores morirán cuando el disco duro deje de girar, y todos viviremos seguros y felices para siempre ...

Otros han abordado los problemas clásicos que rodean a los sistemas diseñados por humanos para otros humanos: la realidad es la pereza y, a veces, la estupidez, junto con la arrogancia "¿Por qué me pasaría esto a mí?"

Oh, cuántas horas de mi vida he pasado parchando sistemas y, lo que es más importante, luchando con la administración para obtener el tiempo / los recursos asignados a los sistemas de parches para que puedan ser "a prueba de balas".

Y tengo suerte al respecto: si bien estoy frustrado luchando con la administración en una organización para hacer que un sistema se parche, muchos lugares contratan desarrolladores para desarrollar un sistema pero luego no consideran que el mantenimiento básico (y aburrido) sea algo por lo que vale la pena invertir. ¿Por qué pagar a un técnico un retenedor mensual para mantener un sistema cuando a menudo es más barato dejarlo en pie hasta que se colapse y luego perseguir una solución en medio de una brecha?

Una onza de prevención es mejor que una libra de cura a menudo se convierte en un segundo plano para la gente que está en pennywise, libra tonta.

Dicho esto, lo mejor que puede hacer cualquier persona que administre un sistema es tener un plan sólido de recuperación en caso de desastre (o sin desastre). Controle la versión del código, automatice la configuración de la implementación del servidor en un script de aprovisionamiento y haga copias de seguridad de las bases de datos. De esa manera, si / cuando un sistema falla, la limpieza es rápida en lugar de ser un desastre tedioso.

La detección precisa de vulnerabilidades de seguridad peligrosas como SQLI y XSS durante la fase de implementación de código de SDLC todavía está limitada al tipo de lenguaje de programación.

• El análisis estático para tales vulnerabilidades se realiza más ampliamente en PHP.
• Algunos métodos dinámicos emplean técnicas difusas durante la fase de prueba o implementación.

Desafortunadamente, ambos métodos todavía son bastante limitados en su tasa de precisión. Además, las vulnerabilidades XSS y SQLI se dirigen a las aplicaciones informáticas y pueden aparecer en muchas formas disfrazadas que son desconocidas para los desarrolladores de software. Como tal, no creo que sea una cuestión de estupidez. Puedo asegurar que algunas compañías ya han capacitado a sus desarrolladores para la programación segura, pero no pueden bloquear totalmente estas vulnerabilidades. Estoy de acuerdo en que hay mucho más por hacer para prevenir ataques tan críticos.