Prevención de ataque XSS

Estoy desarrollando una aplicación web donde los usuarios pueden responder a entradas de blog. Este es un problema de seguridad porque pueden enviar datos peligrosos que se procesarán a otros usuarios (y se ejecutarán mediante javascript).Prevención de ataque XSS

No pueden formatear el texto que envían. No "negrita", sin colores, sin nada. Solo texto simple. me ocurrió con esta expresión regular para resolver mi problema: ". " "?"

[^\\w\\s.?!()]

Así que cualquier cosa que no sea un carácter de palabra (az, AZ, 0-9), no es un espacio en blanco,,," ! "," ("o") "se reemplazará por una cadena vacía. De lo que se sustituirá cada marca de quatation con: "& quot".

Compruebo los datos en la interfaz y los compruebo en mi servidor.

¿Hay alguna manera en que alguien pueda eludir esta "solución"?

Me pregunto cómo hace StackOverflow esto? Aquí hay mucho formato, por lo que deben hacer un buen trabajo con él.

Fuente

2010-05-06 Colby77

¿Cuál es el idioma del lado del servidor? –

Java. Yo uso Servlets – Colby77

No dijiste nada acerca de '<>', que es probablemente el personaje más importante usado en xss ... – rook

El front-end se puede pasar por alto con Fiddler, por ejemplo, al agregar la información del formulario. En el back-end usa la codificación html, p. <a> = & lt; a & gt;

De esta forma, el texto se mostrará como texto no como elementos html.

Fuente

2010-05-06 13:44:00

No permitir etiquetas HTML.
No muestre nada que un usuario haya ingresado sin que se escape primero HTML. ¡Este es el punto mucho más importante! Haga esto y nunca tendrá un problema XSS.
Proporcione una función de vista previa para que los usuarios puedan ver cómo se verá antes de publicarla.

Si debe permitir etiquetas HTML, defina una lista blanca y verifique la entrada del usuario en su contra. Incluso puedes usar expresiones regulares para esto.

Digamos que permiten <p>, <a href="..."> y <img src="...">:

encontrar todo en la cadena de usuario que coincide con <\S[^>]*>
para cada partido, lo comprueba contra <(p|a href="[^"]+"|img src="[^"]+")/?>|</(a|p)>
si no se ajusta a esa expresión regular rigurosa , tirar a la basura.
Vea el punto n. ° 2 arriba.
Intente romper su sistema deliberadamente. Pídales a otros que intenten romper su sistema.

Fuente

2010-05-06 14:03:48 Tomalak

Estoy de acuerdo con Tomalak, y solo quería agregar algunos puntos.

No permitir etiquetas HTML. La idea es tratar la entrada del usuario como texto y los caracteres html-escape antes de representarlos. Use el proyecto OWASP's ESAPI para este propósito. This page explains the various possible encodings que debe tener en cuenta.
Si tiene que permitir etiquetas HTML, use una biblioteca para hacer el filtrado por usted. NO escriba su propio diccionario; son difíciles de hacer bien. Use OWASP's Anti-Samy project - fue diseñado específicamente para este caso de uso.

Fuente

2010-05-06 17:52:49

Si simplemente desea el texto simple no se preocupe por el filtrado de etiquetas html específicas. Desea el equivalente a PHP htmlspecialchars(). Una buena manera de utilizar este es print htmlspecialchars($var,ENT_QUOTES); Esta función realizará las siguientes codificaciones:

'&' (ampersand) becomes '&amp;' 
'"' (double quote) becomes '&quot;' when ENT_NOQUOTES is not set. 
''' (single quote) becomes '&#039;' only when ENT_QUOTES is set. 
'<' (less than) becomes '&lt;' 
'>' (greater than) becomes '&gt;'

Esta es resolver el problema de XSS en el nivel más bajo, y que no es necesario algún complejo biblioteca/expresiones regulares que usted don' Entiendo (y probablemente es inseguro después de que toda la complejidad es enemiga de la seguridad).

Asegúrese de PRUEBE SU FILTRO XSS ejecutando free xss scanner.

Fuente

2010-05-06 18:04:05 rook

Recomiendo leer the XSS Prevention Cheat Sheet que detalla las mejores prácticas para evitar los ataques XSS. Esencialmente, lo que necesita filtrar depende del contexto en el que se utilizará.

Por ejemplo, en este tipo de escenario:

<body>...ESCAPE UNTRUSTED DATA BEFORE PUTTING HERE...</body>

que tiene que hacer:

& --> &amp; 
< --> &lt; 
> --> &gt; 
" --> &quot; 
' --> &#x27;  &apos; is not recommended 
/--> &#x2F;  forward slash is included as it helps end an HTML entity

Mientras que, en el caso de un ejemplo href="" que tiene que hacer un urlescape:

"Excepto caracteres alfanuméricos, escape todos los caracteres con valores ASCII menores que 256 con el %HH formato de escape. Incluir datos no confiables en los datos: no se deben permitir las URL ya que no hay una buena manera de deshabilitar los ataques con el escape para evitar el cambio de la URL. Todos los atributos deben ser citados. Los atributos sin comillas se pueden separar con muchos caracteres, incluido [espacio]% * +, - /; < =>^y |. Tenga en cuenta que la entidad de codificación es inútil en este contexto ".

Mientras que el artículo citado da el veredicto completo, es de esperar que haya suficiente información en esta respuesta para que pueda empezar.

Fuente

2010-05-24 14:07:14

Retire cualquier secuencia de caracteres malas primero, por ejemplo, overlong UTF-8, Unicode válido.

tendrá que ser más explícita si <y> son despojados o se convierte en entidades.

Usted también necesitará las tiras o codificar doble y comillas simples; de lo contrario, un atacante puede agregar un evento intrínseco que no esperaba, p. Ej. valor < name = entrada 'comentario' = 'foo 'onSomething = carga útil; a ='' >

Si realmente desea permitir algún subconjunto de HTML, tenga cuidado al intentar analizar con expresiones regulares, especialmente los que inventarte a ti mismo, por ejemplo los navegadores mostrarán etiquetas engañosas <a b=">"onMouseOver=alert(42)>, muy bien, donde una expresión regular podría no coincidir. Consulte el Anti-Samy anteriormente mencionado.

Si usted está permitiendo que las etiquetas HTML que tienen href o src atributos, asegúrese de que apuntan a http(s): esquemas, no javascript: queridos.

Fuente

2010-06-18 07:57:40 Mike

Respuesta

Cuestiones relacionadas