Un servicio RESTful está actualmente protegido contra ataques XSS al aplicar la validación de entidades y esquemas XML. En ambos casos, esto se hace a través de una expresión regular como:
<xs:pattern value="[0-9]{1}[0-9a-z/\ -]{0,7}" />
¿Se puede considerar esta validación como una contramedida confiable contra XSS, o debo implementar medidas de seguridad adicionales?
Aquí hay algunos ángulos:
(1) La mala interpretación del tipo de respuesta no HTML correctamente generado como HTML peligroso. De esto es de lo que habla la respuesta de Rook, en el supuesto de que su servicio REST esté devolviendo una respuesta como JSON o XML. El problema aquí es que algunos navegadores (en particular IE) podrían ignorar el Content-Type indicado y tratar un documento como HTML porque tiene una cadena mágica como <html en la primera / n / bytes.
Una defensa contra esto en los navegadores modernos es usar el encabezado X-Content-Type-Options: nosniff , lo cual es bueno en todas las respuestas en general. Para cubrir todos los casos, puede usar reglas de codificación para su formato para evitar poner texto variable potencialmente sensible en una forma de codificación que no pueda ser malinterpretada como HTML. Normalmente, esto significa escribir < como \u003C en cadenas JSON, aunque < normalmente no es un carácter que deba escaparse en JSON. Con XML está cubierto para eso, ya que necesita codificar un literal co2de% a < de todos modos. Otros caracteres que existen argumentos para la codificación (aunque los ataques son extremadamente marginales) son < y + .
(2) Respuesta generada incorrectamente, falta la codificación correcta para el formato.
La validación de entrada es una buena medida de defensa en profundidad, así como una buena manera de hacer cumplir las reglas comerciales. Pero no lo protege contra las vulnerabilidades de inyección. Si reúne una respuesta XML o JSON agregando cadenas sin escape explícito, tiene la posibilidad de que un atacante cause respuestas mal formadas que pueden ser interpretadas por otra persona que llama. Es probable que esto no resulte en XSS directos, pero sin duda podría causar problemas lógicos específicos de la aplicación.
Use la forma correcta de codificación de cadena para su contexto cada vez que agregue cadenas, o, mejor, use bibliotecas de salida de datos que lo hagan automáticamente (por ejemplo, serializador JSON o XML estándar). Esto asegura que su respuesta sea correcta y que la seguridad sea un efecto secundario de esa corrección.
(3) Tipos de documentos XML. Esta es una mezcla de (1) y (2), donde la inyección le da la posibilidad de interpretar XML como un tipo diferente de XML. Si tiene un problema de inyección de XML, un atacante podría incluir un elemento en su respuesta con un { que apunta a los espacios de nombres de XHTML o SVG. Si el documento se carga directamente en un navegador web, estos pueden incluir contenido de script que se ejecuta en el origen de ese sitio, y es posible que nuevamente tenga XSS.
(4) DOM XSS: manejo inadecuado de la respuesta por parte del cliente. Si la secuencia de comandos del navegador web consume la respuesta de REST, la cual toma un valor en la respuesta y establece xmlns , aún tiene una vulnerabilidad de inyección de HTML, solo que en un lugar ligeramente diferente.
El content-type utilizado por los servicios web debe indicar al navegador que no interprete la respuesta como código JavaScript ejecutable. Por ejemplo, un servicio web RESTful puede usar application/json o application/xml dependiendo del tipo de cálculo de referencias utilizado. Es imposible para un atacante obtener XSS con estos tipos de contenido, independientemente del contenido del cuerpo.
Algo a tener en cuenta es establecer accidentalmente content-type en text/html u omitirlo por completo, ya que esto podría llevar a XSS en un servicio web.
Lea otras preguntas en las etiquetas appsec xss attack-prevention rest web-service