¿No sería posible usar un método de este tipo para envolver áreas donde se espera la entrada / salida del usuario (por ejemplo, cuadros de comentarios), de modo que incluso si un script se inyecta con éxito mediante la evasión de expresiones regulares, el script no se ejecutará ya que ¿Se encuentra dentro de un determinado contenedor de HTML configurado para deshabilitar todos los scripts que contiene?
Problemas con su enfoque
No, esto no funcionaría. Los problemas son:
</disablescripts> para inyectar scripts y así ganar XSS. You can use </disablescripts> to exit the new HTML6 feature. After that, anything in <script>alert(1)</script> will be executed . Ese comentario no se mostraría correctamente. Y eso ni siquiera está considerando la practicidad de esto. El problema con XSS es que los desarrolladores a menudo no saben dónde se espera la entrada del usuario. Si lo supieran, ya lo codificarían en HTML. Pero por alguna razón, perdieron de vista lo que es la entrada del usuario y lo que no.
El mismo problema existe con su idea propuesta: ¿Cómo sabe un desarrollador qué áreas probablemente contienen JavaScript? Incluso si estuviera funcionando, su enfoque sería, en el mejor de los casos, una segunda línea de defensa, además de las soluciones adecuadas para XSS.
Mejores enfoques para XSS
Los mejores enfoques son:
script-src self https://cdn1.com . Solo los navegadores modernos lo seguirán, pero no ejecutarán ningún script en línea inyectado, y solo cargarán scripts externos de los sitios permitidos. Hay una manera perfectamente buena de detener los ataques de secuencias de comandos entre sitios. Escape sensible al contenido; por ejemplo, si el contenido generado por el usuario se inserta como contenido en un documento HTML, entonces HTML-escape &<>"'/ (posiblemente permita una pequeña lista blanca de etiquetas permitidas como <b> o escape todo y use un lenguaje seguro similar a markdown para permitir una pocas etiquetas), si el contenido generado por el usuario se inserta en javascript, luego javascript lo escapa, etc. (Consulte OWASP para más detalles .)
Este ataque fallará gravemente cuando alguien intente usarlo para evitar ataques en páginas web generadas dinámicamente.
Imagina que tienes una página web que lee tu comentario de una base de datos y coloca ese comentario en una página HTML que se entrega al usuario.
Usted escribe su página HTML como tal:
<disablescripts>
{{ untrusted_user_content_read_from_db }}
</disablescripts>
Bueno, cuando {{untrusted_user_content_read_from_db}} se establece en el valor:
</disablescripts><script>alert("XSS -- gotcha!");</script><disablescripts>
entonces este método de prevención falla porque el servidor web acaba de enviarse a su navegador a través de la página web html como:
<disablescripts>
</disablescripts><script>alert("XSS -- gotcha!");</script><disablescripts>
</disablescripts>
Esto es más o menos lo que hace una política de seguridad de contenido .
A través de un encabezado HTTP, el autor del sitio web puede deshabilitar la ejecución de scripts en línea y "bloquear" los dominios remotos desde los que la etiqueta de script puede cargar su origen desde ( <script src="" ).
por ejemplo
Content-Security-Policy: script-src 'self' https://apis.google.com
La ventaja de esto sobre su método sugerido es que está configurado en un encabezado HTTP donde el contenido de la página no lo puede desactivar. En su ejemplo, un atacante podría simplemente incluir </disablescripts> al comienzo de su carga útil para evitarlo.
Algunos propietarios de sitios web han intentado evitar XSS con la etiqueta <noscript> HTML. El problema es que, si no imprime correctamente la codificación, puede salir de la etiqueta <noscript> y obtener XSS de todos modos. Lo correcto es a) validar la entrada (por ejemplo, un número es un número) yb) la codificación de salida.
Lea otras preguntas en las etiquetas web-browser html xss javascript