Duda sobre procedimiento cuando buscamos vulns web

Debci · 28 Julio 2010, 15:31 PM

Hola a todos, hoy he estado leyendo unos papers (uno de ellos del Master en seguridad web SDC), he aprendido muchas cosas sobre SQLi y XSS.
ES muy bonito cuando tienes el source code a la vista, y ves que puede injectar.

Se me presentan varias dudas:

1-Que haceis para ver si una variable es vulnerable a SQLi o XSS? Cojeis todas las variables de un web (si es asi como las conseguiis) y probais una a una? Si probais una a una, que probais para los XSS o los SQLi usais siempre la misma prueba o cambiais el script o querie que le lanzais?

2-Mi experiencia me dice que los escaners de vulnerabilidades no sirven para mucho, personalmente en mi vida he encontrado ni una sola vulnerabilidad con un escaner, sera que soy muy torpe o que los targets que examino son muy seguros. Que opinais al respecto?

3-Que haceis para saber si una input en una web es vulnerable a XSS? Porque la mayoria de veces tienen filtros o magic-quotes y eso dificulta las cosas.Se pueden bypassear magic-quotes? Como se que tipo de filtro usa un input? En mi caso hace un tiempo me encontre uno con addslashes, que deberia hacer en ese caso?

4-Soleis descargar una copia del sistema web que estais intentando vulnerar (osea, si es un foro, bajais el codigo PHP) para posteriormente analizarlo?

5-En algun caso, de un ataque real es practico usar un ataque por fuerza bruta a un formulario para aceder?

Espero que puedan resolver mis dudas.

Saludos

Erfiug · 28 Julio 2010, 15:35 PM

puedes pasar el link del documento que estas leyendo?
gracias

braulio-- · 28 Julio 2010, 15:46 PM

1)
Para saber eso puedes encontrar las variables por medio de inputs, aunque muchas veces te puedes encontrar enlaces así

Código [Seleccionar]

 http://host/index.php?id=21

Y ahí puedes probar con los típicos payloads de lo que quieras buscar. Los XSS más fáciles de encontrar están en las típicas cajas de búsqueda.

2)
Yo personalmente no recomiendo los escaners ni por aprendizaje ni por eficacia ya que dan muchos falsos positivos.

3)
Primero puedes inyectar los payloads más típicos y ver como se comporta la aplicación dependiendo como filtre los carácteres, a partir de ahí puedes seguir investigando que puedes hacer.

Lo de saltar magic quotes depende de como estén puestas, de todas formas si solo filtra las quotes no protege nada ya que puedes inyectar algo así :

Código [Seleccionar]

<script>alert(/HOLA/);</script> o

Código [Seleccionar]

location = string.fromCharCode(numeros ascii de los caracteres) ;
4)
Si no encuentras otra forma es bastante útil.

5)
Yo nunca lo he intentado, pero si no tienes más remedio...

Debci · 28 Julio 2010, 15:58 PM

Entiendo, mas o menos lo que suponia, ahora por ejemplo, yo intento inyectar codigo en un input, y en el source se queda asi:

Código (html4strict) [Seleccionar]

</div></div><div id="mainContentMaster"><div class="fullPage"><div id="mainSearch" class="ovrh" style="padding-right:10px"><div><h1>0 search results for &lt;script&gt;alert AND () AND ;&lt;/script&gt;</h1>

Y la cadena que le he metido a la variable es:

Código (html4strict) [Seleccionar]

<script>alert();</script>

Osea, la basica.

Que alternativa me queda ahora?

Saludos

Erfiug · 28 Julio 2010, 16:17 PM

Cita de: Debci en 28 Julio 2010, 15:58 PM
Entiendo, mas o menos lo que suponia, ahora por ejemplo, yo intento inyectar codigo en un input, y en el source se queda asi:

Código (html4strict) [Seleccionar] Expandir
</div></div><div id="mainContentMaster"><div class="fullPage"><div id="mainSearch" class="ovrh" style="padding-right:10px"><div><h1>0 search results for <script>alert AND () AND ;</script></h1>

Y la cadena que le he metido a la variable es:

Código (html4strict) [Seleccionar] Expandir
<script>alert();</script>

Osea, la basica.

Que alternativa me queda ahora?

Saludos

Parece que codifican en HTMl los carácteres < y >, lo que hace que el tema esté jodido...

Puedes poner el link del paper que estás leyendo?

braulio-- · 28 Julio 2010, 16:20 PM

En ese caso me parece que es un filtro en plan htmlentities() y se podía saltar dependiendo de que codificación fuera. En el caso de que fuera utf-7 podrías mandar la siguiente cadena :

Código [Seleccionar]

+ADw-script+AD4-alert(/XSS/)+ADsAPA-/script+AD4-
y te devolvería el alert(/XSS/) , pero no creo que sea muy común eso.

Debci · 28 Julio 2010, 17:01 PM

Cita de: braulio-- en 28 Julio 2010, 16:20 PM
En ese caso me parece que es un filtro en plan htmlentities() y se podía saltar dependiendo de que codificación fuera. En el caso de que fuera utf-7 podrías mandar la siguiente cadena :
Código [Seleccionar] Expandir
+ADw-script+AD4-alert(/XSS/)+ADsAPA-/script+AD4-
y te devolvería el alert(/XSS/) , pero no creo que sea muy común eso.

a que te refieres con no muy común?

Saludos

braulio-- · 28 Julio 2010, 17:08 PM

Que no suelen estar en utf-7 para facilitarte este tipo de bypass del filtro.

Erfiug · 28 Julio 2010, 17:09 PM

Cita de: Debci en 28 Julio 2010, 17:01 PM
Cita de: braulio-- en 28 Julio 2010, 16:20 PM
En ese caso me parece que es un filtro en plan htmlentities() y se podía saltar dependiendo de que codificación fuera. En el caso de que fuera utf-7 podrías mandar la siguiente cadena :
Código [Seleccionar] Expandir
+ADw-script+AD4-alert(/XSS/)+ADsAPA-/script+AD4-
y te devolvería el alert(/XSS/) , pero no creo que sea muy común eso.
a que te refieres con no muy común?

Saludos

A que pocas páginas web utilizan esa codificación...

Para ver que codificación utiliza fíjate si hay alguna línea en la cabezera parecida a:

Código [Seleccionar]

<meta http-equiv="Content-Type" content="text/html; charset="'iso-8859-1','UTF-7',"

Puedes pasarme el link del paper que estás leyendo? O seguirás ignorándome?

bizco · 28 Julio 2010, 17:23 PM

y aun pareciendo mentira, los campos hidden en algunas paginas contienen informacion que puedes usar a tu favor. es decir, campos que tienen informacion sobre el usuario que envia el formulario y no es verificada, incluso campos en los que puedes injectar sql pq el webmaster asume que ese campo no se puede modificar.