Este sitio utiliza cookies propias y de terceros. Si continúa navegando consideramos que acepta el uso de cookies. OK Más Información.

HTML Injection (post para novatos)

  • 1 Respuestas
  • 2375 Vistas

0 Usuarios y 3 Visitantes están viendo este tema.

Desconectado Olger346

  • *
  • Underc0der
  • Mensajes: 38
  • Actividad:
    1.67%
  • Reputación 1
    • Ver Perfil
  • Twitter: @Olger346
« en: Diciembre 25, 2017, 10:05:50 am »
Felíz Navidad a todos...

Hoy vengo a postear sobre lo que dice el título. Bien tal vez será que no lo veamos mucho en las webs de internet. Pero sigue siendo una de las vulnerabilidades que lleva mucho años en el top 10 de OWASP, y se da en parte porque obviamos algunas cosas o porque pensamos que nadie vendrá a atacarnos porque no tenemos nada importante. Sin embargo, no está dentro de las mejores prácticas en la gobernanza de activos de TI.

Qué es html injection (OWASP)
Citar
HTML injection is a type of injection issue that occurs when a user is able to control an input point and is able to inject arbitrary HTML code into a vulnerable web page. This vulnerability can have many consequences, like disclosure of a user's session cookies that could be used to impersonate the victim, or, more generally, it can allow the attacker to modify the page content seen by the victims.

Bien según owasp tenemos multiples variantes a insertar en una web vulnerable. Para efecto de prueba y ética usare bWAPP.
Ejemplo 1: Nivel bajo (validación de entrada de datos nula)


En este caso la validación de la entrada de los caracteres es nula y por ello se ve reflejada en la salida del navegador y por ello, los caracteres "<" ">" son tratados como una cosa normal ante el sitio y el navegador.


Hemos intentado insertando un script para mandar una alerta al usuario (esto sólo pasa si enviamos la url maliciosa a un usuario específico).

Ejemplo 2: Nivel medio (aquí es donde viene lo bueno del asunto). Cuando el programador cree que es más listo que el atacante.

Para explicar exactamente qué es lo que sucede, es que el programador ha decidido anular los caracteres "<" ">" que son indispensables para la inyección de código de html y javascript. Sin embargo sabemos que nuestra aplicación utiliza PHP como su lenguaje de backend y esta siendo procesado por el servidor. Si nos fijamos en la URL del navegador tenemos múltiples caracteres que aparecen dentro de ellos "%" y otros caracteres que son interpretados por PHP y que darán respuesta al navegador. Muy característicos de CMS como Joomla y Drupal que funcional bajo php

¿Entonces qué podemos hacer? Utilizaremos esta información que nos brinda la URL, bajo http://www.degraeve.com/reference/urlencoding.php esta tabla podemos convertir cualquier caracter normal a uno que interprete el servidor.

Código: [Seleccionar]
%3Cinput type="text" name="usuario"%3E
%3Cinput type="password" name="passwd"
Con esto bypaseamos las buenas intenciones del programador.

Bien, esta entrada de datos la podemos enviar a otro servidor y recojerlas y habremos obtenido un usuario y password que seguramente algún flojo no cambió en sus redes sociales. Claro que debe ser un poquito más de codificación en HTML

Ejemplo 3: Nivel Difícil
En este nivel vemos la mejor manera de evitar que un atacante intente insertar código en nuestra web.

Esta vez vemos que no podemos usar ninguna de las formas que intentamos anteriormente. Esto se debe a que el programador utilizó una función de PHP que nos ha mandado a "tomar por saco".

Sin embargo aquí no se queda todo, la función utilizada por el programador fue htmlentities(). Por sí sola esta función no para que los atacantes inserten código en el navegador.
Código: [Seleccionar]
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">Acompañada de la codificación que acepte el navegador esta función puede o no ser útil. En este caso el programador decidió que UTF-8 sería la entrada aceptada, de manera que no podemos bypasear la función utilizando UTF-7 u otro.

Si el programador hubiese puesto un documento normal de HTML probablemente seguiría siendo vulnerable el sitio.
por ejemplo:
Código: [Seleccionar]
<html> 
<body>
<input type="text" name="username" action="">
<input type="password" name="passwd">
<button type="submit" name="boton" value="Log in">
</body></html>
El código sería vulnerable porque no se ha especificado el valor de la codificación en el tag <meta> en la página.

Referencias
http://www.degraeve.com/reference/urlencoding.php
https://www.exploit-db.com/docs/english/42609-code-injection-%E2%80%93-html-injection.pdf
https://www.exploit-db.com/papers/13646/

Espero que les haya servido. :)

"Cuando se nace pobre, estudiar es el mayor acto de rebeldía contra el sistema. El saber rompe las cadenas de la esclavitud" -Tomas Bulat.

Desconectado DLV

  • *
  • Underc0der
  • Mensajes: 111
  • Actividad:
    0%
  • Reputación 0
    • Ver Perfil
« Respuesta #1 en: Diciembre 26, 2017, 11:37:27 am »
:)
« Última modificación: Abril 22, 2019, 03:09:06 pm por PlhaOGEOYceXkhd9rlYxJGzedkbolnxpnReqRiTk47d6JgDTRu »

 

¿Te gustó el post? COMPARTILO!



[Phishing] Página de phishing para Twitter

Iniciado por bernatixer

Respuestas: 8
Vistas: 6599
Último mensaje Enero 07, 2016, 10:23:35 am
por ANTRAX
Eternal - Un escáner para Eternal Blue

Iniciado por puntoCL

Respuestas: 2
Vistas: 3296
Último mensaje Julio 23, 2017, 10:37:05 pm
por puntoCL
Paso a paso para ser un verdadero < HACKER > lo mejor que hay

Iniciado por smown

Respuestas: 5
Vistas: 4187
Último mensaje Agosto 17, 2018, 09:20:02 am
por ANTRAX
Un Redirect en Facebook para hacer Phishing a Facebook

Iniciado por Stiuvert

Respuestas: 4
Vistas: 5994
Último mensaje Enero 09, 2014, 11:46:26 pm
por Snifer
Sniffer para windows "RawCap"

Iniciado por s747ik

Respuestas: 1
Vistas: 3239
Último mensaje Junio 12, 2011, 04:08:03 pm
por staRgan