Saltar al contenido

¿La mejor expresión regular para atrapar el ataque XSS (Cross-site Scripting) (en Java)?

Este dilema se puede tratar de diversas formas, pero en este caso te damos la que en nuestra opinión es la solución más completa.

Solución:

No hagas esto con expresiones regulares. Recuerde, no solo está protegiendo contra HTML válido; estás protegiendo contra el DOM que crean los navegadores web. Se puede engañar a los navegadores para que produzcan DOM válidos a partir de HTML no válido con bastante facilidad.

Por ejemplo, consulte esta lista de ataques XSS ofuscados. ¿Está preparado para adaptar una expresión regular para evitar este ataque del mundo real en Yahoo y Hotmail en IE6/7/8?






¿Qué tal este ataque que funciona en IE6?

¿Qué hay de los ataques que no están listados en este sitio? El problema con el enfoque de Jeff es que no es una lista blanca, como afirma. Como alguien en esa página señala hábilmente:

El problema con esto es que el html debe estar limpio. Hay casos en los que puede pasar html pirateado y no coincidirá, en cuyo caso devolverá el html pirateado string ya que no coincidirá con nada para reemplazar. Esto no es estrictamente una lista blanca.

Sugeriría una herramienta especialmente diseñada como AntiSamy. Funciona analizando el HTML y luego recorriendo el DOM y eliminando cualquier cosa que no esté en el configurable lista blanca. La principal diferencia es la capacidad de manejar correctamente HTML mal formado.

La mejor parte es que en realidad realiza pruebas unitarias para todos los ataques XSS en el sitio anterior. Además, qué podría ser más fácil que esta llamada a la API:

public String toSafeHtml(String html) throws ScanException, PolicyException 

    Policy policy = Policy.getInstance(POLICY_FILE);
    AntiSamy antiSamy = new AntiSamy();
    CleanResults cleanResults = antiSamy.scan(html, policy);
    return cleanResults.getCleanHTML().trim();

Extraje del mejor complemento Anti-XSS de NoScript, aquí está su Regex: funciona sin problemas:

<[^w<>]*(?:[^<>"'s]*:)?[^w<>]*(?:W*sW*cW*rW*iW*pW*t|W*fW*oW*rW*m|W*sW*tW*yW*lW*e|W*sW*vW*g|W*mW*aW*rW*qW*uW*eW*e|(?:W*lW*iW*nW*k|W*oW*bW*jW*eW*cW*t|W*eW*mW*bW*eW*d|W*aW*pW*pW*lW*eW*t|W*pW*aW*rW*aW*m|W*i?W*fW*rW*aW*mW*e|W*bW*aW*sW*e|W*bW*oW*dW*y|W*mW*eW*tW*a|W*iW*mW*a?W*gW*e?|W*vW*iW*dW*eW*o|W*aW*uW*dW*iW*o|W*bW*iW*nW*dW*iW*nW*gW*s|W*sW*eW*t|W*iW*sW*iW*nW*dW*eW*x|W*aW*nW*iW*mW*aW*tW*e)[^>w])|(?:

Prueba: http://regex101.com/r/rV7zK8

Creo que bloquea el 99% de XSS porque es parte de NoScript, un complemento que se actualiza periódicamente

No estoy demasiado convencido de que usar una expresión regular sea la mejor manera de encontrar todo el código sospechoso. Las expresiones regulares son bastante fáciles de engañar, especialmente cuando se trata de HTML roto. Por ejemplo, la expresión regular que aparece en el enlace Sanitize HTML no eliminará todos los elementos 'a' que tienen un attribute entre el nombre del elemento y el attribute 'h ref':

< a alt="xss injection" href="http://www.malicous.com/bad.php" >

Una forma más robusta de eliminar código malicioso es confiar en un analizador XML que pueda manejar todo tipo de documentos HTML (Tidy, TagSoup, etc.) y seleccionar los elementos para eliminar con una expresión XPath. Una vez que el documento HTML se analiza en un documento DOM, los elementos para revocar se pueden encontrar de manera fácil y segura. Esto es incluso fácil de hacer con XSLT.

Aquí tienes las comentarios y puntuaciones

Agradecemos que desees amparar nuestro análisis ejecutando un comentario o dejando una puntuación te estamos agradecidos.

¡Haz clic para puntuar esta entrada!
(Votos: 0 Promedio: 0)



Utiliza Nuestro Buscador

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Respuestas a preguntas comunes sobre programacion y tecnología