Foro de elhacker.net

revisando la pagina de la empresa donde trabajo  descubri una parte en donde se le puede inyectar codigo html la estructura de la liga es la siguiente
http://xxxx.com/consultaexistencia/ubicacion/existencia.php?codigo=<h1>*****CODIGO-MALICIOSO***</h1>
mi pregunta es la siguiente que mas puedo hacer si se puede inyectar code html intente mandar un alert pero no me deja

ve como se presenta el código luego de ser inyectado buscándolo en el código fuente... ahí verías porque no hace el alert... la cosa también es que si la inyección sirve solo para tu maquina o si es un foro donde múltiples personas acepten

no pongas <script> o cosssas asi sino salta puedes ir probando asta k lo haga

ok si lo del msj de alert lo entiendo , pero mi pregunta es si puedo inyectar code html que mas puedo hacer guienme porfavor

Prueba con algún formulario de tu web y no desde su url. Cierra el input del mismo poniendo:

"><script>alert("xxx")</script>

Primero cierras con "> y luego inyectas el alert, prueba así :).

Si tu web es ésta: http://smail.coppel.com/ el <script> no se ejecuta porque filtra las comillas dobles de dentro de alert. Con StringfromCharCode() te servirá, así:

http://smail.coppel.com/consultaexistencia/ubicacion/existencia.php?codigo=%3Cscript%3Ealert%28String.fromCharCode%28111,118,101,114,120,102,108,111,119%29%29%3C/script%3E

ok overxfl0w13 te entiendo pero ahora como puedo empezar a sacar datos con ese tipo de error, tengo conociemientos en php y sql pero no se como implementarlo en esta parte

Pues yo de XSS no tengo mucha idea, pero puedes probar a poner un document.cookie en el alert, junto con window.location para que se escriba la cookie en un archivo de texto y enviar la url maligna por ahí a gente que sepas que está registrada.

Un saludo :)

Son cosas diferentes inyectar código html, embeber javascript payload aprovechándose de un XSS persistente que hacer inyección SQL. Igualmente no es lo mismo uyna vulnerabilidad que inyecta código del lado del cliente que del lado del servidor.

¿Qué exactamente es lo que quieres hacer y qué tipo de vulnerabilidad ('error') es lo que encontraste?

Deja de pensar en todos los demás. Piensa así, javascript se ejecuta del lado del cliente osea, que puedes hacer que el navegador realice cualquier acción sin que el usuario se de cuenta.

Por ejemplo, si encontrara un XSS en elhacker, yo pudiera hacer cualquier cosa, desde enviar mensaje y borrar post (en caso de ser mod), eliminar usuario, cualquier cosa que SMF le permita hacer al usuario.

Pero hay algo que me detiene, que seria una  captcha o una verificación de password.
Para hacerle un bypass a la primera (captcha), se me ocurre mostrar en el centro la  captcha y forzar el usuario para que escriba la captcha y poder hacerle el bypass. Para la verificación del password, se me ocurriría lo mismo.

Si ya eres programador, se te hara muy facil. Cuando necesitas hacer algo como programador no buscas codigos ya hechos, piensas en como lo podria hacer y lo programas. Algo similar pasa con este tipo de vulnerabilidad, pero en vez de pensar, la gente comienza a buscar códigos de como explotar, como el FAMOSO robo de cookie, en vez de comenzar a pensar la forma en que te podrías aprovechar de esta vulnerabilidad y crear un vector de ataque. Y estoy seguro que muchas personas no asocian XSS con javascript, supongo que para alguno la forma de sacar cookie por medio de un "XSS" viene siendo como magia.

El primer paso es estudiar el sistema.

Saludos.

tienes mucha razon ~ Yoya ~ ahorita me he alejado un buen de la programacion, y conforme a lo que me comentas  estoy conciente de que debo de estudiar el sistema primero, pero tu dices que con un xss puedes realizar varios cambios , pero para realizar tal cosa debes de conocer la estructura de la bd , y es ahi donde estoy estancado en que me puedo basar para lograr explotar al maximo la falla que he encontrado

Pues no me puedo imaginar cómo se podría explotar /*directamente*/ una vulnerabilidad en la que el objetivo del ataque es el cliente y que también, al mismo tiempo, sirva para inyectar 'código html' que permita modificar u obtener registros de la base de datos del lado del servidor.

No sé, será algo así como escribir un exploit para cierta vulnerabilidad de OpenSSH y quererlo usar para que al mismo tiempo nos permita hacer BOF al servico SMB. Si existe algo así quiero verlo..


Saludos.

La estructura de la DB no, la del sistema, por ejemplo si encontrara un XSS en el foro del elhacker, estudiaria SMF, para ver como trabaja.


Debes estar confundido sobre algunos conceptos.

En si con un xss tu no puedes obtener información directamente del servidor, pero si puedes obligar al usuario a que obtenga o realize una determinada accion por ti.

Ejemplo: quiero ser admin en foro en el hacker.net y encontre un xss, entonces busco como el SMF realiza la acción de agregar un Administrador y veo si es vulnerable a CSRF, con esto armo el html o javascript y se lo envio al Administrador para que este sin darse cuenta (generalmente), realize la acción de agregar a un nuevo Administrador con el usuario y pass que yo le pase.

Tambien esta lo del robo de cookies, o incluso puedes crear una pagina igual a la del login y caputar los datos de usuario y contraseña.

Saludos.

A eso me refería, un xss puede abrir la puerta a otros ataques y permitir explotar otras vulnerabilidades sin duda, pero en el contexto de cada una de éstas. En ese sentido se convierte en un medio y no en un fin.


Claro, es muy posible. Más si tomas en cuenta que RedZer y tú no han sabido expresar bien sus ideas: no he afirmado que no sea posible un server side attack aprovechándose de un xss, ni que estas vulnerabilidades se puedan explotar sólo en el contexto de javascript. Y si estoy confundido entonces mucha gente que define la vulnerabilidad Cross Site Scripting (aun en el caso de inyectar consultas SQL) como algo diferente de una vulnerabilidad SQLi también lo está. Sí, por supuesto que ambas tienen en común la posibilidad de inyectar código, pero estríctamente son diferentes. Así, digan lo que digan, para sacar datos de una base de datos no basta con tener un XSS (y también depende de si es reflected, asíncrono, etc.), se necesita otro bug asociado en la aplicación web o usar la primera para obtener la otra. Algo que inferí quizá erroneamente cuando RedZer anota "como puedo empezar a sacar datos con ese tipo de error, tengo conociemientos en php y sql pero no se como implementarlo en esta parte ".

Cuando digo que "no me puedo imaginar cómo se podría explotar /*directamente*/ una vulnerabilidad en la que el objetivo del ataque es el cliente" lo expreso así porque generalmente es el contexto en el que se da XSS (o por lo menos alguna variante de éste) y no que sea restringido sólo a eso.