Lista negra vs. caracteres de lista blanca para evitar XSS

No es solo un bloque de pocos caracteres lo que necesitas para la lista negra. En seguridad pasamos por este dogma:

  

"Hay cosas que sabemos que sabemos. Hay incógnitas conocidas. Eso   es decir que hay cosas que ahora sabemos que no sabemos. Pero hay   También se desconocen las incógnitas. Hay cosas que no sabemos que no sabemos.   saber. "

La lista negra podría ayudarlo a prevenir los primeros dos casos, una lista blanca ayuda a cubrir los tres :)

Si bien es fácil identificar y validar un conjunto de caracteres que son inofensivos, es difícil identificar todos los malos conocidos. La mayoría de los programas antivirus emplean un enfoque de lista negra (firmas), sin embargo, aún no logran alcanzar un día cero porque era algo que no conocían como mal conocido y, por lo tanto, no tenían una firma para eso.     

  

Además, ¿por qué el enfoque de lista blanca es mejor que el enfoque de lista negra como   mencionado por OWASP. ¿Por qué no solo bloquear un puñado de caracteres utilizados?   en XSS como < , > , etc

Las listas negras son estáticas en el sentido, evitan que ocurra "mal conocido". El problema con esto es que hay nuevos vectores de ataque que se encuentran todos los días y que necesitarías actualizar constantemente tu lista negra para estar seguro. La lista blanca, por otro lado, es más robusta porque puede crear un filtro exactamente sobre lo que desea. Eso responde a su pregunta sobre por qué las listas blancas son sugeridas por OWASP.

Creo que podrías haber rechazado ESAPI demasiado rápido. Para defenderse contra XSS, le recomiendo que realice una salida de escape: cualquier lugar donde inserte datos dinámicamente en un documento HTML, escape de los datos (de una manera adecuada para ese contexto de análisis). ESAPI proporciona bibliotecas para el escape y es muy útil. Esto no implica "cambiar tu entrada".

Para más información, lea XSS (Cross Site Scripting) y < a href="https://security.stackexchange.com/q/1368/971"> ¿Alguien puede explicar el XSS a un idiota? y ¿Filtra la entrada del usuario antes de la base de datos o en la pantalla? , y Canonicalization & Codificación de salida .

  

hacer filtrado de entrada

No, no, no.

De todos modos, ingrese validation : acepte o rechace la entrada según las reglas. No intente cambiar los datos de entrada. Si la interfaz entre su servidor web y el idioma de su aplicación permite contenido a través del cual se compromete el idioma de su aplicación, entonces hay algo muy, muy incorrecto. Ciertamente, no puede manejar este tipo de escenario dentro del código de su aplicación.

Las vulnerabilidades en las aplicaciones generalmente surgen en el punto donde los datos dejan el idioma de la aplicación, y en el caso de XSS, es donde siempre surgen. Entonces este es el punto en el que debe aplicar cualquier transformación a los datos. Una transformación debe ser apropiada para el lugar donde van los datos: cómo escapar de los datos que está escribiendo en una base de datos es muy diferente de los datos que se escribirán en html.

Lo ideal es que los siguientes pasos se realicen en la entrada:

1. Filtro (opcionalmente). Eliminar espacios en blanco alrededor de los valores. O, por ejemplo, para un número de teléfono es posible que desee eliminar espacios, guiones y puntos, porque algunas personas intentan ingresar cosas como 046 339 1312 .

2. Validar .

   a. Esto evita errores de usuario no detectados por el filtro.

   b. Las verificaciones de validación deberían funcionar como lista blanca. Con un escape adecuado (consulte el punto 3 a continuación), esto no debería ser necesario para la seguridad, pero puede bloquear un ataque no descubierto en el futuro. Sin embargo, tenga cuidado, a menudo es más difícil de lo que parece.

   Si debería optar por algo básico (como solo comprobando Un signo @ al validar las direcciones de correo electrónico) o una expresión regular exacta y estricta, depende de si conoce todos los valores posibles y de si realmente necesita hacerlo bien. Para un sitio con datos de tarjeta de crédito en su base de datos, es posible que desee pasar más tiempo investigando posibles entradas.

   c. También es posible que desee validarlo, ¿existe el dominio en esta dirección de correo electrónico? O ¿es este número realmente válido ? Incluso puede intentarlo si un servidor de correo acepta al usuario (Gmail generará un error cuando el usuario no existe, incluso antes de que usted haya enviado algo), pero el servidor podría estar inactivo. SMTP manejará esto por usted y retrasará la entrega, pero su verificador de dirección de correo electrónico en vivo le dirá al usuario que su dirección no existe mientras que exista.

3. Escape . Esto debe hacerse tanto para la entrada como para la salida . Ingrese cuando lo esté guardando en una base de datos, y salga cuando lo esté mostrando Sí, también evite los datos que vienen directamente de su base de datos. Un apóstrofe puede ser totalmente inofensivo en HTML, mientras que el uso en Javascript puede proporcionar una gran oportunidad XSS. O un < no se escapará por mysql_real_escape_string , pero si luego lo imprime en una página HTML, obtiene otro XSS.

No puedo pensar en ningún caso de uso en el que los pasos anteriores hagan que una lista negra sea práctica o necesaria, por lo que aconsejaría no usarla. Aunque siempre puede haber una razón. Escapar debería encargarse del resto independientemente, pero es bueno tener otra defensa.

Cuando sea lo suficientemente importante, también puede escribir una prueba de unidad para probar todas las entradas posibles y las vulnerabilidades comunes: ../, ', ", \, numerics, cadenas o incluso el conjunto ASCII completo.