2011-03 Archives
20-03-2011 23:06:22
[Secu] Facebook URL Redirection
Dans l'idée du post précédent sur lequel je
reviendrai pour réévaluer tout ca, je vais vous
présenter une URL redirection applicable
directement sur le site de Facebook. Pour cela il suffit d'appeler 2
fois la variable "u" dans notre requete GET et le controle d'url se
retrouve bypassé et la 2e requete est executé.
Voici un PoC appelant la requete suivante:
Prudence donc à chaque clic !
Voici un PoC appelant la requete suivante:
http://www.facebook.com/l.php?u=http%3A%2F%2Fwww.facebook.com%2Fpages%2FCin%25C3%25A9ma%2F104202296279674&h=8ae77&cb=3&p=AQCd3-oYLWKIy8Qz9FddRczehHGXLbUokzXxGei4HBNDeBcDcMr0TpAuAQ36lsm-IYmzLy62Zl6R48mn9VH_M2Yye8DiDcyYpL0tpQ&u=http://blog.madpowah.orgOn peut imaginer les conséquences en mettant une URL avec un site de phishing Facebook à la place de mon blog ...
Prudence donc à chaque clic !
19-03-2011 19:32:58
[Secu] Les HTTP Parameter Pollution
J'ai été interpelé par le titre raccoleur d'un
article de Clubic
indiquant que
30% des sites web présenteraient une faille
exploitable.
Cette vulnérabilité se nomme HPP ou HTTP Parameter
Pollution.
J'ai donc creuser un peu pour voir ce qu'il en était.
Les HPP ont été présentées en 2009 par l'OWASP. Les slides sont disponibles ici. Des chercheurs ont en fait constaté que les navigateurs interprétaient différement le fait qu'une variable soit envoyée plusieurs fois dans la meme requete. En effet certains vont ne considérer que la 1ère, d'autre la dernière et les plus intéressants vont concaténer les 2. Il est ainsi possible de voir la réaction des serveurs Web d'après les tests présentés ci dessous.
Ainsi on constate que IIS principalement concatène les données. Sachant que IIS représente environ 30% des serveurs Web sur Internet, on peut supposer que le journaliste a fait un énorme raccourci pour annoncer ses résultats.
Car au final à quoi sert une HPP ? A Rien ? "Presque". Si un site web ne propose aucune vulnérabilité complémentaire, cela ne sert dans 99% des cas strictement à rien. En effet au mieux cela va servir à passer un WAF (Youpi!) ou à la rigueur bypasser une protection CSRF comme présentée via la vuln Yahoo (qui va quand meme nécessiter une phase de SE donc peu critique).
La ou cela peut etre intéressant c'est pour tester un serveur Web perso qui n'apparait pas dans la liste et qui peut avoir un comportement étonnant comme l'exemple donné dans les slides pour CUPS. Et comme il faut une exception qui confirme la règle et donc nos 1% restant, il y a eu récemment une vulnérabilité qui a été récompensé par Google pour sa découverte et qui impactait le site Blogger.com. Le serveur propre à Google sembl(ait) gérer bizarrement les doubles variables en prenant une fois la 1ere puis l'autre. Du coup, lors du test de valeur, la valeur était légitime et la valeur prise lors de l'action était la 2e qui était pirate. Pour plus de détail sur cette attaque cliquez ici.
En conclusion les HTTP Parameter Pollution sont pour moi inutiles lors d'un pentest (sans WAF) dans le cas de l'utilisation d'un serveur web connu mais peuvent présenter un intéret dans le cas d'une application utilisant un serveur web différent de l'habitude. En tout cas on est très loin des 30% de sites web vulnérables :)
J'ai donc creuser un peu pour voir ce qu'il en était.
Les HPP ont été présentées en 2009 par l'OWASP. Les slides sont disponibles ici. Des chercheurs ont en fait constaté que les navigateurs interprétaient différement le fait qu'une variable soit envoyée plusieurs fois dans la meme requete. En effet certains vont ne considérer que la 1ère, d'autre la dernière et les plus intéressants vont concaténer les 2. Il est ainsi possible de voir la réaction des serveurs Web d'après les tests présentés ci dessous.
Ainsi on constate que IIS principalement concatène les données. Sachant que IIS représente environ 30% des serveurs Web sur Internet, on peut supposer que le journaliste a fait un énorme raccourci pour annoncer ses résultats.
Car au final à quoi sert une HPP ? A Rien ? "Presque". Si un site web ne propose aucune vulnérabilité complémentaire, cela ne sert dans 99% des cas strictement à rien. En effet au mieux cela va servir à passer un WAF (Youpi!) ou à la rigueur bypasser une protection CSRF comme présentée via la vuln Yahoo (qui va quand meme nécessiter une phase de SE donc peu critique).
La ou cela peut etre intéressant c'est pour tester un serveur Web perso qui n'apparait pas dans la liste et qui peut avoir un comportement étonnant comme l'exemple donné dans les slides pour CUPS. Et comme il faut une exception qui confirme la règle et donc nos 1% restant, il y a eu récemment une vulnérabilité qui a été récompensé par Google pour sa découverte et qui impactait le site Blogger.com. Le serveur propre à Google sembl(ait) gérer bizarrement les doubles variables en prenant une fois la 1ere puis l'autre. Du coup, lors du test de valeur, la valeur était légitime et la valeur prise lors de l'action était la 2e qui était pirate. Pour plus de détail sur cette attaque cliquez ici.
En conclusion les HTTP Parameter Pollution sont pour moi inutiles lors d'un pentest (sans WAF) dans le cas de l'utilisation d'un serveur web connu mais peuvent présenter un intéret dans le cas d'une application utilisant un serveur web différent de l'habitude. En tout cas on est très loin des 30% de sites web vulnérables :)