Omitir filtrado de caracteres - seguridad Shephard

3

Estoy atrapado en la parte XSS de la aplicación de seguridad OWASP. No estoy buscando a alguien que me diga la solución, solo necesito aprender a encontrarla yo mismo, estoy un poco oxidado en XSS. Así que lo que sé hasta ahora.

  • sustituirá la char "i" y yo por "."
  • eliminará " <script> " para un espacio en blanco
  • sustituirá ":" por un "!"
  • también sustituirá "on", por lo que cualquier onload, etc., mostrará carga en su lugar, etc.

Así que el filtro no es a lo que estuve acostumbrado durante años, he intentado muchas cosas, pero no he podido encontrar una manera de evitarlo ... pero tiene que haber una manera por la cual el desafío está en. .. La curiosidad me está matando aquí ..: / Cualquier consejo será bienvenido y esperamos que ayude a otras personas en el futuro.

    
pregunta cfernandezlinux 20.04.2016 - 01:52
fuente

1 respuesta

3

Mi respuesta se prolongó más de lo esperado, así que solo para darte la respuesta: <body onpageshow="alert(1)"> probablemente funcione, y si no lo hace, <body onpaonpageonpagonpageonpageshowshoweshowshowgeshow="alert(1)"> lo hará.

Cómo intentar omitir un filtro personalizado

Dice que trata de aprender cómo hacerlo usted mismo, por lo que aquí hay algunos de los primeros pasos que tomaría:

  • marca de verificación: no todos los filtros distinguen entre mayúsculas y minúsculas. ¿ I también está sustituido, o solo i ?
  • verifique las codificaciones alternativas: : no está permitido, pero &#58; puede estar (y funciona igual en la mayoría de los contextos).
  • comprueba lo que realmente hace el filtro. ¿Los reemplazos siempre se hacen, o solo en ciertos contextos (por ejemplo, i siempre se filtra, o solo en script , o solo está rodeado de caracteres, o ...)? ¿Los filtros solo se aplican una vez (por ejemplo, <scri<script>pt> se convierte en <script> )?

El último punto es el más complejo. Por ejemplo, usted dice que i siempre se sustituye por . . Pero luego en los comentarios, usted dice que <scri<script>pt> se convierte en <scri<scr.pt>pt> . Entonces, tal vez i solo es sustituido en script ?

También dijiste que on se filtra. ¿Estás seguro? ¿O solo se filtran algunos de los atributos de eventos específicos? ¿Has probado onFooBar ? Si se filtra, todos los atributos on serán filtrados. Pero si no, algunos podrían pasar por alto el filtro. Si es así, debería probar especialmente los nuevos HTM5, algunos de los cuales a menudo se olvidan. Aquí hay una lista de atributos de eventos para verificar.

Lo que podría funcionar en tu caso

No fuiste lo suficientemente específico con tus reglas [*] para dar una respuesta definitiva, pero aquí hay algunas ideas:

  • <meta http-equIv="refresh" content="0;url=data&#58;text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="> funcionará si el filtro i no distingue entre mayúsculas y minúsculas (es menos probable), o si solo se aplica a script (lo que parece ser el caso en su ejemplo). Tenga en cuenta que &#58; funcionará en lugar de : .
  • si el filtro i no distingue entre mayúsculas y minúsculas, pueden funcionar muchas cargas útiles: <scrIpt src=http://localhost/s.js></scrIpt> (no contiene <script> ), <a href="javascrIpt&#58;alert(1)">click</a> , etc.

[*] E incluso te contradices un poco; si <script> se convierte en un espacio en blanco, y i se convierte en . , entonces ¿por qué <scri<script>pt> lleva a <scri<scr.pt>pt> , en lugar de <scr. pt> , que coincidiría con sus reglas?

Cuál es el filtro real en tu caso

Los filtros XSS se pueden ver aquí .

Desde la descripción de tu filtro, estás en el nivel dos (o posiblemente en el nivel tres). El filtro es:

  • script se convierte en sc.pt
  • onclick se convierte en o.ick
  • onmouseover se convierte en o.ver
  • onload se convierte en o.oad
  • onerror se convierte en o.err
  • ondblclick se convierte en o.dbl
  • & se convierte en !
  • : se convierte en !

O alternativamente para el nivel tres, el mismo, excepto que los filtros on son un poco menos malos.

¿Qué carga útil evitará estos filtros

Ahora que tenemos una descripción adecuada de los filtros, podemos omitirlos fácilmente.

Pero primero, los bypass que realmente no funcionarán:

  • <meta http-equiv="refresh" content="0;url=data&#58;text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="> : no funcionará. i en realidad no siempre se reemplaza con . (lo cual tiene sentido, ya que tal filtro destruiría toda la entrada real), pero no podemos usar & , y por lo tanto no podemos usar una URL de datos.
  • <a href="javascript&#58;alert(1)">click</a> : problema con script , y también & .

Puede ver que el primero solo falla debido a una regla que no ha mencionado: el & replace.

Pero ahora a una solución que funciona. Para el nivel dos:

  • cualquier atributo on que no sea onclick , onmouseover , onload , onerror o ondblclick . Hay mucho, por ejemplo, <body onpageshow="alert(1)"> .

Para el nivel tres, el truco es que hay muchos más filtros de atributos on (no verifiqué si es todo), pero son reemplazados por nada (cuatro veces). Eso significa que si incluye la palabra clave en sí mismo cinco veces, omite el filtro:

  • <body onpaonpageonpagonpageonpageshowshoweshowshowgeshow="alert(1)">

Conclusión

Su descripción del filtro es inconsistente e incompleta, por lo que no puede obtener una respuesta basada en él.

Al probar un filtro como este, debe probar tantos casos de esquina en torno a las reglas que definió como sea posible, para obtener una descripción del filtro que sea lo más parecida a la realidad posible.

Entonces solo es cuestión de encontrar la carga útil correcta para evitar estas reglas.

    
respondido por el tim 20.04.2016 - 12:04
fuente

Lea otras preguntas en las etiquetas