Journal : Faille Apache/PHP permettant du XSS

Posté par lilliput (page perso, ) le 01 février 2006
0
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(...)

> Lire le journal (25 commentaires, moyenne: 1,8).  

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

pour plus de precisions

Posté par lilliput (page perso, ) le 01/02/2006 à 10:29. (lien). Évalué à 1.

J'ai egalement mis les expressions regulieres sur la page web pour detecter ce genre d'attaque.
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 ...

Syntaxe concernée ?

Posté par L () le 01/02/2006 à 10:46. (lien). Évalué à 3.

Est-ce que ça fonctionne même avec la syntaxe _SERVER['PHP_SELF'] qui est la syntaxe recommandée par la documentation PHP ?

  • [^]Re: Syntaxe concernée ?

    Posté par lilliput (page perso, ) le 01/02/2006 à 11:12. (lien). Évalué à 1.

    tu veux dire $_SERVER['PHP_SELF'] ? vi :(

    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

Mod_security powaaaa !

Posté par inico (Jabber id, page perso, ) le 01/02/2006 à 11:22. (lien). Évalué à 4.

Je viens de tester sur mon serveur et j'ai une erreur 403. Dans mon fichier error.log:
[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 :)


--
"Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
  • [^]Re: Mod_security powaaaa !

    Posté par lilliput (page perso, ) le 01/02/2006 à 11:29. (lien). Évalué à 0.

    essaye d'ajouter juste des lettres genre
    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.

    • [^]Re: Mod_security powaaaa !

      Posté par inico (Jabber id, page perso, ) le 01/02/2006 à 11:44. (lien). Évalué à 3.

      Ben aucun effet sur ma page phpinfo (la chaine se retrouve aux endroits normals).
      J'ai du configurer quelque chose de façon trop paranoique ....
      Tu as un exemple ?

      --
      "Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
      • [^]Re: Mod_security powaaaa !

        Posté par lilliput (page perso, ) le 01/02/2006 à 12:02. (lien). Évalué à 1.

        google +
        /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.

        • [^]Re: Mod_security powaaaa !

          Posté par inico (Jabber id, page perso, ) le 01/02/2006 à 12:08. (lien). Évalué à 2.

          Attend, je crois que je n'ai pas compris.
          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 ?

          --
          "Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
          • [^]Re: Mod_security powaaaa !

            Posté par lilliput (page perso, ) le 01/02/2006 à 12:25. (lien). Évalué à 0.

            je disais que tu etais pas forcement obliger d'injecter du HTML enfin des tags quoi.
            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.

  • [^]Re: Mod_security powaaaa !

    Posté par TilK () le 01/02/2006 à 12:30. (lien). Évalué à 2.

    Et si tu ajoutes
    phpinfo.php/%22%20onError=%22alert('XSS%20Detected')%22%20fr=%22 ?

    • [^]Re: Mod_security powaaaa !

      Posté par inico (Jabber id, page perso, ) le 01/02/2006 à 13:29. (lien). Évalué à 2.

      La page se charge normalement et rien n'apparait ....

      --
      "Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
      • [^]Re: Mod_security powaaaa !

        Posté par inico (Jabber id, page perso, ) le 01/02/2006 à 13:32. (lien). Évalué à 2.

        En réalité, le code est bien présent au bon endroit sauf qu'il semble que mon php a transformer les "<" & ">" en identité html.
        Au faite, c'est un PHP 5, donc le pb est peut etre deja corrigé ...

        --
        "Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
        • [^]Re: Mod_security powaaaa !

          Posté par TilK () le 01/02/2006 à 15:03. (lien). Évalué à 2.

          Après en peu plus d'essai, je suis tombé grace à google sur des versions de php 5 (5.1.2) sur lesquelles cela marchait...

          Le plus souvent, c'est sur des sites d'hébergeurs professionnels que ça passe :)

          • [^]Re: Mod_security powaaaa !

            Posté par inico (Jabber id, page perso, ) le 01/02/2006 à 15:14. (lien). Évalué à 2.

            PHP Version 5.0.5-2ubuntu1.1 ....
            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 :) ).

            --
            "Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..
            • [^]Re: Mod_security powaaaa !

              Posté par lilliput (page perso, ) le 01/02/2006 à 15:31. (lien). Évalué à 0.

              ca promet avec un eval() on peut recrire des portions de la page avec des tags dechiffrer via une fonction js... arg ...

              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.

              • [^]Re: Mod_security powaaaa !

                Posté par lilliput (page perso, ) le 01/02/2006 à 19:30. (lien). Évalué à 0.

                j'ai essayé de passer a travers mod_security .. il faut mettre les encodages en utf-8 parce qu'il ne fait pas la transformation ..

                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 :)

                • [^]Re: Mod_security powaaaa !

                  Posté par DPhil (page perso, ) le 01/02/2006 à 22:21. (lien). Évalué à 2.

                  Rajouter htmlentities ne servira pas à grand chose, cette fonction n'est pas compatible avec certains encodage comme utf-7

              • [+] [^]Re: Mod_security powaaaa !

                Posté par Raphaël Gertz (Jabber id, page perso, ) le 01/02/2006 à 21:31. (lien). Évalué à -1.

                Je capte pas comment faire marcher votre bug...

                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 (page perso, ) le 02/02/2006 à 02:27. (lien). Évalué à 0.

                  pour tester tu fais

                  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.

                • [^]Re: Mod_security powaaaa !

                  Posté par inico (Jabber id, page perso, ) le 02/02/2006 à 08:32. (lien). Évalué à 2.

                  _SERVER["REQUEST_URI"] /~nico/phpinfo.php/Super/OS
                  _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 ...

                  --
                  "Les États-Unis sont le seul pays à être passé de la barbarie à la décadence sans connaître la civilisation." -- (origine réelle inconnue) Albert Einstein/Oscar Wilde/Georges Clemenceau/etc..

Tient donc :)

Posté par Nahuel ANGELINETTI (Jabber id, page perso, ) le 01/02/2006 à 11:45. (lien). Évalué à 3.

Eh beh, pure coincidence, ce matin en me levant j'ai eu une idée qui est la resulte de certains besoins :
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.

--
Jabber/XMPP : nahuel@ahtna.org
  • [^]Open Web Application Security Project

    Posté par Krunch (Jabber id, page perso, ) le 01/02/2006 à 11:59. (lien). Évalué à 2.

    C'est pas spécifique à PHP mais le guide de 293 pages couvre pleins de trucs bons à savoir.
    http://www.owasp.org/

    --
    Free Softwares Users Group Arlon (Sud Luxembourg, Belgique)
    pertinent, e adj. Approprié ; qui se rapporte exactement à ce dont il est question.
  • [^]Re: Tient donc :)

    Posté par Cali_Mero () le 01/02/2006 à 14:42. (lien). Évalué à 2.

    http://phpsecure.info peut sans doute t'éclairer un peu (Le plus ancien site orienté php & sécurité). Les articles y sont pour certains vieux mais toujours aussi pertinents.

    --
    #define MAGIC 0xdefaced /* I should've patented this number -cliph */
  • [^]Re: Tient donc :)

    Posté par Nahuel ANGELINETTI (Jabber id, page perso, ) le 01/02/2006 à 18:57. (lien). Évalué à 2.

    Merci pour ces liens :)

    --
    Jabber/XMPP : nahuel@ahtna.org

tiny url

Posté par fabien () le 01/02/2006 à 20:46. (lien). Évalué à 2.

d'apres ce que j'ai lu, c'est une option d'apache qui permet d'ajouter a $_SERVER['PHP_SELF'] les parametres accepté par la syntaxe suivante :
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.

Revenir en haut de page