Prevención de ataques XSS

Question

Estoy creando una página web donde el usuario puede interactuar y realizar operaciones básicas del sistema de archivos (crear archivo/dir, eliminar archivo/directorio, navegar sistema de archivos) en una computadora remota. La página web es HTML básico (codificación UTF-8) y Javascript. Necesito hacer que esta página web sea a prueba de XSS.

¿Sería suficiente escaparse de todos los caracteres no alfanuméricos en la entrada del usuario (para proteger contra DOM basado en XSS) y la información del nombre de archivo (para proteger contra XSS almacenado) usando Javascript (esto genera valores hexadecimales porcentuales)?

En esencia, soy una lista blanca solo para la entrada alfanumérica. Además, dado que estoy usando el porcentaje de valores hexadecimales codificados, supongo que la vulnerabilidad de codificación UTF no debería estar presente.

¿Alguien puede pensar en alguna laguna de seguridad en este mecanismo?

Answer 1

Este suena seguro, y probablemente lo sea, pero hay una trampa. Solo funciona si implementa correctamente. Es demasiado fácil equivocarse. Si quiere hacerlo, está bien, pero le sugiero que use algunas bibliotecas ya probadas para hacer esto, en lugar de hacer las suyas propias.

Answer 2

La codificación es buena para hacer. El mayor riesgo potencial es qué hacer con los datos y si/cuando los datos se decodifican/muestran. Si decodifica la entrada del usuario y la muestra, decodificando los datos, entonces puede tener problemas en ese punto.

Si no necesita presionar para admitir caracteres que son más riesgosos en términos de posibles vulnerabilidades XSS (como '<', '>', ';', etc.), entonces creo que es razonable incluirlas en una lista negra personajes también. De esta forma, en caso de que descodifique y muestre datos, no podrá expresar un problema de XSS.

Answer 3

El uso de javascript (que es lo que creo que está diciendo) para hacer el escape no parece demasiado seguro. Se ejecuta en la máquina de los usuarios y podrían, con cierto esfuerzo, eludir el mecanismo de escape.

Lo que intenta hacer suena bien, pero debe hacerlo desde el servidor.

Answer 4

La forma básica de defenderse contra XSS es utilizar expresiones regulares para validar la entrada siempre que sea posible y para codificar todas las salidas. La codificación de salida puede ser complicada, por lo que es mejor usar una biblioteca. Por lo menos, una entrada importante para su aplicación son los nombres de archivo, por lo que querría una expresión regular que coincida con cualquier nombre de archivo válido para su sistema operativo objetivo. Si acepta solo la entrada alfanumérica, su aplicación no podrá manejar muchos nombres de archivos en sistemas operativos comunes. No entiendo por qué usar% hex values ​​sería bueno. No hay motivo para que un script malicioso no pueda codificarse de esa manera. El mismo script puede tener muchas representaciones válidas de utf-8. Necesita leer más sobre las prácticas de codificación anti-XSS. Google OWASP para referencias.

Answer 5

Algunos punto de nota:

• Como @Alo dijo, esto debe hacerse del lado del servidor, para evitar que un atacante sin pasar por el Javascript en conjunto y el envío de la entrada maliciosa directamente al servidor. Sin embargo, como señaló, esto debe hacerse (en determinadas situaciones) TAMBIÉN en el lado del cliente, para evitar XSS basado en DOM.
• Mencionó que la página es UTF-8, necesita aplicar esto usando metaetiquetas, encabezados HTTP, etc. De lo contrario, es vulnerable a los ataques UTF-7.
• Espacios: ¿es alfanumérico condicional o no? (Algunos incluyen eso ...) Usando solo un espacio y letras, se puede montar un ataque XSS completo, en algunas situaciones.

Echa un vistazo a algo más de información en mi respuesta a Will HTML Encoding prevent all kinds of XSS attacks? Encontrarás todo lo que necesitas saber allí.

Answer 6

Una nota para complementar otros puntos señalados:

Asegúrese de que está utilizando GET y POST correctamente, ya que es el tipo más simple de agujero de seguridad en muchos sitios web.

Si la entrada del usuario va a desencadenar algún cambio en la base de datos, asegúrese de utilizar POST.

Solo el usuario GET si está recuperando información para mostrar.