Estoy tratando de hacer un cargador de archivos usando PrimeFaces , pero es vulnerable a los scripts: si alguien intenta cargar un archivo (por ejemplo, un curriculum vitae) que incluye JavaScript, esto podría ejecutarse una vez que se complete la carga del archivo.
¿Hay formas eficientes de detectar código JavaScript? Sé que analizar el archivo puede detectar el código, pero considero que analizar cada archivo que se ha cargado es una mala idea porque consume potencia de procesamiento.
No debe intentar hacer esto, ya que no hay forma de detectar todos los scripts maliciosos. Hay varias formas de ocultarlo, ya que no está bien presentado dentro de las etiquetas <script> . Toma esta por ejemplo:
<BODY onload!#$%&()*~+-_.,:;?@[/|\]^'=alert("XSS")>
Echa un vistazo a la XSS Filter Evasion Cheat Sheet para algunos otros ejemplos.
Si está mostrando los archivos cargados en HTML, debe establecer una Política de seguridad de contenido para evitar que se ejecuten JavaScript y CSS en línea. (Usando CSS es posible incrustar JavaScript. Algunas versiones de Internet Explorer lo admiten)
El CSP puede evitar el script en línea, pero permite que el script se ejecute en archivos externos js desde su servidor o desde fuentes confiables (como el CDN de Google).
Debería asegurarse de que primero valide que el navegador es compatible con CSP (podría implementar una prueba para esto en una página antes de mostrar el contenido), y podría hacerlo en combinación con un desinfectante HTML que procesa la página. contenido solo en salida al navegador. Este será un acercamiento de cinturón y tirantes. Debería utilizar una solución bien probada para el saneamiento, como OWASP AntiSamy . Se han encontrado vulnerabilidades en versiones anteriores de la mayoría de los desinfectantes (incluso en este caso), pero usarlo en combinación con un CSP evitaría la mayoría de los ataques, ya que esto le daría la oportunidad de parchear a la última versión.
La otra opción sería agregar el encabezado Disposición del contenido a cualquier contenido servido, para que se descargue a la máquina del usuario en lugar de mostrarse en un navegador en el contexto de su dominio. Cualquier código que se ejecute en el contexto de su dominio puede aprovechar la Same Origin Policy para atacar a los usuarios que ven el contenido. Esto no sería posible sin conexión (Internet Explorer muestra un mensaje de advertencia con un mensaje de confirmación, y los navegadores como Chrome y Firefox consideran el sistema de archivos como el origen null para detener el script que accede al contenido en línea).
El archivo debe ser inspeccionado antes de almacenarlo. Para detectar el código JavaScript incorporado, no tendrá otra opción que analizar todo el contenido del archivo.
Definitivamente tienes que mirar ese archivo para asegurarte de que no haya JavaScript allí. Pero eso podría ser tan simple como buscar tokens como '(', ')' y ';' (Por ejemplo, no estoy seguro de si esto es suficiente ...). Por supuesto, al hacer esto, estas letras no pueden aparecer más en el contenido regular. Entonces, si su definición 'personal' de análisis es 'realizar operaciones complejas en el archivo como f.e. construyendo un árbol de análisis ', entonces esta es una solución sin análisis.
Sin embargo, la solución preferible a su problema sería asegurarse de que no se pueda ejecutar JavaScript, sin importar si está en el archivo o no.
Lo que intentas hacer es evitar un ataque de scripts entre sitios ("XSS"). Puede intentar ejecutar algunos reemplazos de cadena para reemplazar ciertos caracteres con sus entidades HTML (como <script> con <script> ) para evitar que un navegador web los reconozca como código para ejecutar mientras aún los muestra de la forma en que el usuario los ingresó, pero Cuando se trata de seguridad, siempre es mejor confiar en una solución probada que en rodar las suyas.
Hay una gran cantidad de casos de borde que permiten incrustar javascript en HTML que podría olvidar. Pero cuando utiliza una conocida biblioteca diseñada por especialistas en seguridad web y recomendada por otros especialistas igualmente capaces, puede asumir que tienen cubiertas estas eventualidades.
Hay muchas bibliotecas disponibles especialmente para este propósito. Etiquetó esta pregunta como Java, por lo que supongo que está utilizando Java (JSP?) Para la programación del lado del servidor. La pregunta " Prevención XSS en Java " en Stackoverflow enumera algunas bibliotecas que puede usar.
Intente sanear las entradas de los usuarios tan pronto como el servidor las reciba. Cuanto más tiempo se mantengan las cadenas sin sanear, mayor será el riesgo de que se filtren en algún lugar, como en un mensaje de error en un registro que alguien ve con un navegador web.
Básicamente tienes dos opciones aquí:
Analice los archivos y asegúrese de hacerlo bien. No puede simplemente eliminar las etiquetas de secuencia de comandos, también debe eliminar los atributos que permiten la creación de secuencias de comandos, asegurarse de que los enlaces no tengan javascript: URI de esquema, etc. Si elige esta ruta, sugiero usar algo como OWASP Java HTML Sanitizer , en lugar de intentar implementarlo usted mismo, ya que no es trivial.
Deja de preocuparte por ello. Coloca los archivos donde no puedan hacer ningún daño. Este es un enfoque adoptado por muchos sitios que ofrecen contenido generado por el usuario. Si las páginas se sirven desde un origen que no contiene contenido sensible & no tiene cookies confidenciales, entonces un XSS no puede comprometer nada. Si sirve los archivos de "useruploadedcontent.com", entonces debido a SOP los scripts solo pueden interactuar con "useruploadedcontent.com" y no "domainwithsensitivecookies.com".
Lea otras preguntas en las etiquetas attack-prevention javascript file-upload