voila une nouvelle faille avec $_SERVER[PHP_SELF] et la manipulation d'url
server/phpinfo.php/"<img src=url/perl.png>
affiche une image a la place de celle de php.
J'ai egalement expliquer pourquoi cette technique de XSS peut-etre tres tres mauvaise; on peut re-ecrire a la volee des formulaires (javascript et innerHTML )et surtout la destination de celui-ci sur un autre server (marche egalement en SSL)
pour plus d'explication ici: http://www.internetdefence.net/weblog/2006/01/31/xss-another(...)
Journal Faille Apache/PHP permettant du XSS
1
fév.
2006
# pour plus de precisions
Posté par ~ lilliput (site web personnel) . Évalué à 1.
La difficulte pour proxy est que " index.php/feed/ " est souvent utilser pour les RSS et autres blogs. Par contre de base et tout ce qui y ressemble doivent etre bloque (ainsi que <.*>)
Malgre les expressions regulieres l'ajout de texte dans la page web est possible.
Cela pourrait nuire a des sites web cible. Et pour ce proteger contre cette attack la methode htmlentities() ne suffit pas.
En utilisant les url-rewrite dans htaccess et en prennant le / comme charactere separateur de variable la technique ne marche pas mais c'est plus tot de l'obscurantisme. Rien ne vaut un bon squid en front avec une whitelist.
voila c'etait les 2 secondes de protections pour le serveur.
Cote client .. ben js .. enfin bon ...
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
# Commentaire supprimé
Posté par Anonyme . Évalué à 3.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: Syntaxe concernée ?
Posté par ~ lilliput (site web personnel) . Évalué à 1.
perso quand je veux indiquer le script utilise j'ai toujours utitliser
action="?" qui pointera sur lui meme. Je parcours pas mal de script php et ils y utilisent tous +/- cette variable sans verification. Je ferai des testes cette aprem pour savoir si le bug est reproduisible sour IIS avec php.
Je sais pas si faut faire une depeche pour ce genre d'info vu que ca touche pas mal de site web
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
# Mod_security powaaaa !
Posté par inico (site web personnel) . Évalué à 4.
[Wed Feb 01 12:19:21 2006] [error] [client 127.0.0.1] mod_security: Access denied with code 403. Pattern match "<(.|\\n)+>" at THE_REQUEST [hostname "xavia.thenico.fr.eu.org"] [uri "/~nico/phpinfo.php/%22%3Cimg%20src=url/perl.png%3E"]
Voila, avec les bons logiciels, on peut oublier ce genre de pépin :)
[^] # Re: Mod_security powaaaa !
Posté par ~ lilliput (site web personnel) . Évalué à 0.
info.php/hello%20world
ouvre le source et fait une recherche :) pour le moment y a pas trop de parade contre ca. En gros on peut faire de l'injection de texte information qui peut etre tout aussi grave. ( genre un mail - yahoo a fait une depeche sur Microsoft XXX elle a ete supprime 5 minutes apres mais elle est toujours accessible via cette url regarde depeche toi vite ... ) enfin bon...
parcontre je suis d'accord avec toi mod_security est INDISPENSABLE pour proteger son server. Fait une petite experience avec google y'en a plein qui sont pas proteger par contre.
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
[^] # Re: Mod_security powaaaa !
Posté par inico (site web personnel) . Évalué à 3.
J'ai du configurer quelque chose de façon trop paranoique ....
Tu as un exemple ?
[^] # Re: Mod_security powaaaa !
Posté par ~ lilliput (site web personnel) . Évalué à 1.
/info.php/%22%3E%3Cimg%20src=http://www.perl.com/images/75-logo.jpg%3E%3Cblah
ca c'est le premier proof of concept. Celui sur http://www.internetdefence.net/weblog/2006/01/31/xss-another(...) montre une autre facon d'exploiter le XSS (cad sans utiliser un iframe exploit et virus a la clef.. enfin sous IE .. ) Dans cette exploit TOUS les browsers sont vulnerables sauf si JS desactive.
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
[^] # Re: Mod_security powaaaa !
Posté par inico (site web personnel) . Évalué à 2.
J'ai mod_security qui bloque tous ce qui ressemble à du code html dans les GET.
Donc on ne peut pas faire du XSS sur mon serveur.
Qu'est-ce que je risque d'autre ?
Et puis, ce n'est pas plutot une erreur des scripts au lieu d'une faille dans php ?
[^] # Re: Mod_security powaaaa !
Posté par ~ lilliput (site web personnel) . Évalué à 0.
Si y a un formulaire qui est vulnerable tu peux simplement injecter du texte du genre.
"Desoler suite a des raisons techniques nos serveurs sont instables veuillez vous loguer ici http://xxxxxxx.com/backup " enfin apres ...
Je vois passer pas mal de fishing et avec ce genre de method ca devient vraiment de plus en plus dur de les voirs.
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
[^] # Re: Mod_security powaaaa !
Posté par TilK . Évalué à 2.
phpinfo.php/%22%20onError=%22alert('XSS%20Detected')%22%20fr=%22 ?
[^] # Re: Mod_security powaaaa !
Posté par inico (site web personnel) . Évalué à 2.
[^] # Re: Mod_security powaaaa !
Posté par inico (site web personnel) . Évalué à 2.
Au faite, c'est un PHP 5, donc le pb est peut etre deja corrigé ...
[^] # Re: Mod_security powaaaa !
Posté par TilK . Évalué à 2.
Le plus souvent, c'est sur des sites d'hébergeurs professionnels que ça passe :)
[^] # Re: Mod_security powaaaa !
Posté par inico (site web personnel) . Évalué à 2.
Bon, je vais fouiller mon php.ini pour comprendre.
C'est surement un truc obselete (et ne devant plus etre utilisé) que j'ai désactivé chez moi et que les hebergeurs pros laisse actifs (ou un patch d'ubuntu mais je doute quand mem :) ).
[^] # Re: Mod_security powaaaa !
Posté par ~ lilliput (site web personnel) . Évalué à 0.
d'apres http://blog.phpdoc.info/archives/13-XSS-Woes.html cette faille est cause par apache. Je suis en train de tester sur IIS pour voir si c'est tjs vrai et determiner si c'est a cause du php ou pas.
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
[^] # Re: Mod_security powaaaa !
Posté par ~ lilliput (site web personnel) . Évalué à 0.
sinon de la meme facon y'a des facon de passer a travers genre
%%%%20 = %20
%2525252520= %20
pareil en mettant la version utf-8 de % a sa place enfin bon voila y'a de quoi faire c'est recursif ....
je suis en train de bosser sur une librairie qui permet de decoder tout ca; ca pourra aider sur des proxy ou pour detecter du XSS dans les mails;
voila
sans ca pour patcher son code php
enfin a tester ..
find . -iname "*.php" --exec sed -i 's/$_SERVER\[\'\PHP_SELF'\]/htmlentities\($_SERVER\[\'\PHP_SELF'\]\)'
enfin c'est preferable au cas par cas.
Je viens de faire des audits rapide de blogs et y'a certain theme qui serait vulnerables.
je vais remonter les infos :)
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
[^] # Re: Mod_security powaaaa !
Posté par DPhil (site web personnel) . Évalué à 2.
[^] # Re: Mod_security powaaaa !
Posté par Raphaël G. (site web personnel) . Évalué à -1.
j'ai créé une page comme ça :
<?php
echo $_SERVER['PHP_SELF'];
?>
Mais ça me génère rien du tout...
Chez moi ça m'affiche le texte de manière toute bête...
Bon je pense que mon code dois être this bug proff, un grand coup de basename() sur toutes mes entrées et un preg_replace() pour virer tout ce qui est pas d'alpha-numérique avec les quelques caractères genre : _/*+-
J'ai bon ?
[^] # Re: Mod_security powaaaa !
Posté par ~ lilliput (site web personnel) . Évalué à 0.
page.php/hello_world
regarde la source et si hello_world apparait tu es pas **bug proof**
vu qu'il y a des encodages super bizarre sans passer par les <,>,(,)
necessaire a executer du javascript onLoad(), onError(), , ..
utf-8, hexa, utf-7 comme d'écrit au dessus et certainement d'autre.
sachant que tu peux corser le tout en melangeant le tout (voir mon post sur les %%% .. )
Le danger d'une telle faille vient que tu peux récrire le formulaire a l'aide des document.getelementbyID ou document.All[XX]
fuite de donnée genre login password ou autre information tres sensible peut alors avoir lieu;
Le probleme avec cette faille et que c'est largement utilisé dans le monde php. Avec un peu d'exercice j'ai reussi a faire passer pas mal de truc a travers squid et mod_proxy cette aprem.
http://www.theatre-eibel.fr http://www.isc2chapter-yorkshire.co.uk
[^] # Re: Mod_security powaaaa !
Posté par inico (site web personnel) . Évalué à 2.
_SERVER["SCRIPT_NAME"] /~nico/phpinfo.php
_SERVER["PATH_INFO"] /Super/OS
_SERVER["PATH_TRANSLATED"] /var/www/Super/OS
_SERVER["PHP_SELF"] /~nico/phpinfo.php/Super/OS
Mon serveur semble avoir le comportement normal ...
# Tient donc :)
Posté par Nahuel . Évalué à 3.
Il me faut des tutos de développement php sécurisé.
Comme il est réputé pour ne pas l'être, mais c'est juste dûe à chaque fois à un mauvais développement, et/ou mauvaise configuration du serveur.
Donc je me suis mis a fouiner un peu, et j'ai trouvé ceci :
http://www.phpsec.org/
Le consortium de securité php, avec un bon petit pdf en français de 33 pages qui explique les failles et comment corriger, puis une petite librairie de liens qui sont tout autant interessent.
Si vous en avez d'autres, n'hésitez surtout pas à les faire tourner.
[^] # Open Web Application Security Project
Posté par Krunch (site web personnel) . Évalué à 2.
http://www.owasp.org/
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
[^] # Re: Tient donc :)
Posté par Cali_Mero . Évalué à 2.
[^] # Re: Tient donc :)
Posté par Nahuel . Évalué à 2.
# tiny url
Posté par fabien . Évalué à 2.
url.example.net/path/monscript.php/parametres
d'un autre coté, il faut donc que cette option dans apache soit activé.
moi perso je prefere la notation ?parametre ca evite de tout melanger.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.