Estoy trabajando para un sitio web de comercio electrónico escrito en C # .net (no se usa CMS, mucho código) donde la seguridad no ha sido una prioridad durante mucho tiempo. Mi misión en este momento es encontrar y reparar cualquier violación de XSS. Hay una gran cantidad de datos no filtrados escritos directamente en el HTML renderizado.
¿Cuál es mi mejor estrategia para corregir el código sin tener que leer cada página?
Propongo el siguiente programa de cuatro pasos, en el que primero escoges la fruta que cuelga para darte un mínimo de protección mientras trabajas en los problemas más grandes.
La configuración del siguiente encabezado de respuesta HTTP activará los navegadores integrados en la protección XSS:
X-XSS-Protection: 1; mode=block
Esto no es de ninguna manera impermeable, y solo ayuda contra el XSS reflejado, pero es algo. Algunas versiones anteriores de IE (sorpresa, sorpresa) tienen un filtro con errores que en realidad podría empeorar las cosas, por lo que es posible que desee filtrar algunos agentes de usuario.
Si no usa JavaScript en línea en su aplicación, un CSP puede ayudarlo mucho. La configuración de script-src 'self' (a) limitará las etiquetas de script para que solo incluyan scripts de su propio dominio, y (b) deshabilite los scripts en línea. Entonces, incluso si un atacante pudiera inyectar <img onerror="alert('XSS')"> , el navegador no ejecutará el script. Tendrá que adaptar el valor que utiliza para el encabezado a su propio uso, pero el recurso MDN vinculado debería ayudarlo con eso.
Pero de nuevo, esto no es impermeable. No hace nada para ayudar a los usuarios con un navegador que no implementa CSP (consulte aquí ). Y si su fuente está llena de scripts en línea, tendrá que elegir entre limpiar eso o abstenerse de usar CSP.
John Wu tiene una buena sugerencia en los comentarios:
Además, dado que esto es .NET, un cambio muy rápido y sencillo puede activar Validación de la solicitud de ASP.NET que puede capturar una variedad de ataques XSS (pero no el 100% de ellos).
Si está trabajando en otro idioma, podría considerar usar un firewall de aplicaciones web (como sugiere xehpuk ). La facilidad de configuración de un WAF depende de la aplicación que esté protegiendo. Si está haciendo cosas que dificultan el filtrado (por ejemplo, pasar HTML en los parámetros GET o POST) puede que no valga la pena el esfuerzo de configurar uno.
Pero, una vez más, aunque un WAF podría ayudar, todavía no es impermeable.
Use un escáner XSS automatizado para encontrar las vulnerabilidades existentes y corregirlas. Como complemento puedes realizar tus propias pruebas manuales. Esto le ayudará a concentrar su valioso tiempo en arreglar vulnerabilidades fáciles de encontrar, lo que le dará la mayor cantidad de dinero posible en la fase inicial.
Pero por tercera vez, esto no es impermeable. No importa cuánto escanee y pruebe, perderá algo. Entonces, desafortunadamente, hay un punto # 4 a esta lista ...
Sí, tendrá que "leer cada página". Ir a través de la fuente y volver a escribir todo el código que genera datos utilizando algún tipo de marco o biblioteca de plantillas que maneja los problemas de XSS de una manera sana. (Probablemente debería elegir un marco y comenzar a usarlo para las correcciones que hace bajo el # 3 ya).
Esto llevará mucho tiempo y será un dolor en la a **, pero debe hacerse. Míralo desde el lado positivo: tienes la oportunidad de hacer una refactorización adicional mientras lo haces. Al final, no solo habrá resuelto su problema de seguridad, sino que también tendrá una mejor base de código.
En resumen, no hay una solución fácil. Tengo una sugerencia para una solución "fácil" en la parte inferior, pero tenga en cuenta que tiene muchas advertencias, que discutiré aquí. Sin embargo, primero, empecemos por el panorama general y avancemos hacia abajo.
En mi experiencia (después de haber trabajado con muchos sistemas heredados), "la seguridad no ha sido una prioridad durante mucho tiempo" significa que es probable que tenga varios problemas de seguridad ocultos en su sistema. XSS es solo un problema, estoy seguro. Así que, a menos que sepa que alguien ya está encima de estos, me preocuparía:
Los números no tienen la intención de dar prioridad: todos son prioridades principales.
El punto de partida
Lo más importante es arreglar esto "institucionalmente". Esto va a ser lo más difícil de hacer, pero también es lo más crítico. Si pasa algunas semanas arreglando todas sus vulnerabilidades de XSS, pero la seguridad sigue siendo una prioridad de nivel inferior, el problema volverá a aparecer la próxima vez que un desarrollador envíe datos sin filtrar al navegador.
La mejor protección contra las vulnerabilidades de XSS es hacer que los desarrolladores sepan que deben tomarse en serio la seguridad y usar un motor de plantillas que maneje adecuadamente el escape de XSS por usted. La clave para recordar es que con XSS debe filtrar en la salida, no en la entrada. Es fácil ver esto como un problema de una sola manera: "Limpie los datos del usuario cuando entren en la entrada, y luego estará bien". Pero esto no protege contra todos los vectores de ataque, especialmente XSS agregado a través de SQLi. Sin embargo, en general, si la protección XSS es algo que sus desarrolladores deben hacer, recuerde que debe hacer todo el tiempo, terminará siendo olvidado. Es por eso que lo mejor que puede hacer es tener esa protección XSS incorporada en su sistema. Aquí es donde entra en juego un motor de plantillas. Cualquier sistema de plantillas competente aplica automáticamente el filtro XSS de forma predeterminada, y se debe informar específicamente si es necesario no filtrar por XSS.
Estoy seguro de que la refactorización de su sistema para incluir un motor de plantillas específicamente para ocuparse de las vulnerabilidades de XSS probablemente no va a suceder, pero también es importante entender que si no hace algo para solucionar el problema institucional Eso permitió que esto sucediera en primer lugar, el problema simplemente volverá y las semanas que demore en solucionarlo se perderán.
Primeros pasos prácticos
@Anders tiene algunos puntos de partida excelentes en su respuesta. Un CSP y el encabezado XSS funcionan de la misma manera: al indicar al navegador que habilite el lado del cliente de protección XSS. Tenga en cuenta (como mencionaron @Anders) que estos son dependientes del navegador y, especialmente para los navegadores más antiguos, es posible que no sean compatibles en absoluto. En particular, el soporte de IE para la CSP es muy mínimo, incluso hasta IE11 ( enlace )
El resultado es que, si bien estos pasos son buenos puntos de partida, definitivamente no puede confiar en ellos como su seguridad principal: todavía tiene que solucionar el problema. Obtener una buena herramienta de escaneo automatizada es definitivamente la mejor manera de comenzar. Le conseguirá algunos elementos de acción inmediata.
Una solución parcial
Otra opción que puede tener es colocar el filtro XSS en la pizarra en su aplicación. Normalmente no recomiendo esto, pero creo que la mejor opción para usted es una respuesta de varios niveles. La idea aquí es que agregue algo de código al proceso de arranque de sus aplicaciones que verifica todos los datos entrantes del cliente (datos de URL, datos de POST, cookies, encabezados de SOLICITUD, etc.). A continuación, realiza un filtrado para detectar las cargas de XSS comunes y, si lo encuentra, rechace la solicitud por completo.
El problema con el filtrado de listas negras es que puede ser muy poco confiable. Si lees la hoja informativa de evasión del filtro OWASP XSS obtendrás una buena idea de lo difícil que puede Ser confiable filtrar las vulnerabilidades XSS. Sin embargo, es una forma rápida de protegerse en cada solicitud, por lo que puede valer la pena en su caso. Sin embargo, un aspecto importante a tener en cuenta es que esto generalmente impedirá que los editores WYSIWYG funcionen. Eso puede o no ser un problema para usted.
Lea otras preguntas en las etiquetas web-application xss .net whitebox