Foro de elhacker.net

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

puedes pasar el link del documento que estas leyendo?
gracias

1)
  Para saber eso puedes encontrar las variables por medio de inputs, aunque muchas veces te puedes encontrar enlaces así
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í :
o 4)
 Si no encuentras otra forma es bastante útil.

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

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

</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:

<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?

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 :
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

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

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:


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

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.

http://hack-2600.mforos.com/967946/6444745-tutorial-de-inyeccion-sql-sql-injection-by-sirdarckcat/ (http://hack-2600.mforos.com/967946/6444745-tutorial-de-inyeccion-sql-sql-injection-by-sirdarckcat/)

Saludoshttp://hack-2600.mforos.com/967946/6444745-tutorial-de-inyeccion-sql-sql-injection-by-sirdarckcat/ (http://hack-2600.mforos.com/967946/6444745-tutorial-de-inyeccion-sql-sql-injection-by-sirdarckcat/)

aunque nadie recomiende scanners , yo te recomiendaria que al menos uses el crawler de acunetix , es el mejor , teniendo en cuenta que no consume recursos como ese ue es por fuerza bruta y ensima echo en java , y saca buenos resultados
despues bueno,, no lei lo que dijeron los otros users con detenimiento , pero ya te habran dicho casi todo ;D

un link que te puede servir

http://projects.webappsec.org/Threat-Classification-Enumeration-View

saludos

Utilizar o no utilizar escáneres depende principalmente del objetivo de la auditoria. Mas alla que un escáner no puede competir contra la creatividad de una persona, pueden ser útiles para comprobar que no estas dando nada por sentado. Aclarar que con objetivo me refiero a lo que se quiere lograr, mas alla de la buena u mala intención que puede haber en ello.

Ahora bien, si la idea es intentar pasar lo mas desapercibido posible, un escáner es la ultima opción. Mas allá de la flexibilidad que pueda proveer algún software en particular, siempre llaman la atención mas de lo que deberían.

Saludos

Ahora mi pregunta es esta:

Cuando analizan un posible vector de ataque como determinan, en el caso de XSS por ejemplo, cual es el filtro que esta utilizando?

Son todos los filtros, de una manera u otra bypasseables?


Saludos

Mirando el código fuente.. o probando con distintos inputs si no dispones de este.
Esto es equivalente a preguntar si todas las webs son vulnerables a ataques XSS

Otra cosa útil es usar :
Que te descarga todos los archivos de la web (que estén enlazados en alguna parte de la web accesible) y así puedes observar como van los directorios.

pero de que te vale ver el php interpretado a html si eso ya lo puedes hacer en directo con el browser?

Saludos

porque te descarga directamente toda la jerarquía de directorios de modo que lo puedas ver con el explorador de archivos de una manera más sencilla.