Joomla et allow_url_fopen

Réduire
X
  • Filtrer
  • Heure
  • Afficher
Tout effacer
nouveaux messages

  • Joomla et allow_url_fopen

    Bonjour,

    On parle pas mal du probleme de register_globals pour les recents problemes de securite, mais je me pose une question vis a vis de allow_url_fopen.

    Les attaques recentes ont toutes la meme signature: injection d'un script par l'intermediaire d'une variable globale mal protegee, en y passant l'url d'un site hebergeant le script de hacking.

    Or, si je ne m'abuse, cela ne fonctionne que si allow_url_fopen est a on non?

    Donc est-ce que la piste de securisation la plus serieuse n'est pas justement ce parametre? Quelles sont les implication pour Joomla? J'ai teste sur mon install, et ca a l'air de fonctionner correctement, y compris pour le composant pour lequel je me disais que ca risquait de le mettre par terre (com_newsfeeds). En y regardant de plus pres il utilise une requete http pour recuperer le feed donc pas de probleme.

    Donc ma question: y a t-il des effet indesirables pour Joomla en mettant allow_url_fopen a off?

    Cordialement,
    Richard.
    Association d'entraide de parents de multiples: http://www.jumeaux-et-plus.fr
    École de Musique de Villers-lès-Nancy: http://www.apm-villers.org

  • #2
    allow_url_fopen=off

    pour ta question consernant le parametre allow_url_fopen=off et register_globals=on si tu as ces deux paramettres presenté idem dans ta configuration tu evites en effet un bon nombre de problemes et il n'est plus possible de passer via les failles de sécurités citées. Mais cette configuration n'est pas toujours viable selon les composants installé sur ton site.
    Pour info j'utilise cette configuration pour pluseurs de mes sites sans aucuns problémes meme avec des mises a jours tardivent aucune attaques n'ont abouties. En effet le serveur retourne un code 500 lors de tentative d'injections via une url externe.
    Je ne peux pas te dire si c'est une bonne solution mais d'apres les environs 19000 attaques recuent sur mes sites aucunes n'a aboutie. Donc visiblement fiable meme sans avoir fait des mises a jours sur un ou deux de mes sites auxilliaires.
    Salutations
    Greg

    Intermitant ( trop de job ces temps )

    Commentaire


    • #3
      Envoyé par greig
      pour ta question consernant le parametre allow_url_fopen=off et register_globals=on si tu as ces deux paramettres presenté idem dans ta configuration tu evites en effet un bon nombre de problemes et il n'est plus possible de passer via les failles de sécurités citées.
      C'est bien ce que je pensais... Ceci etant je pensais a register_globals=Off, mais j'ai quand meme bien l'impression que quel que soit la valeur de register_globals, mettre allow_url_fopen a false aurait suffit a proteger Joomla de toutes les attaques recentes.
      Envoyé par greig
      Mais cette configuration n'est pas toujours viable selon les composants installé sur ton site.
      Oui ben des extensions qui utilisent le fait que l'ouverture d'une url par fopen passe de maniere transparente je m'en passe. C'est la porte ouverte a du cross-scripting en masses. La preuve...
      Envoyé par greig
      Pour info j'utilise cette configuration pour pluseurs de mes sites sans aucuns problémes meme avec des mises a jours tardivent aucune attaques n'ont abouties. En effet le serveur retourne un code 500 lors de tentative d'injections via une url externe.
      Je ne peux pas te dire si c'est une bonne solution mais d'apres les environs 19000 attaques recuent sur mes sites aucunes n'a aboutie. Donc visiblement fiable meme sans avoir fait des mises a jours sur un ou deux de mes sites auxilliaires.
      Ok, c'est bien ce que je pensais. Je laisse donc allow_url_fopen a Off sur mon serveur, et tant pis pour les extensions mal foutues qui ont besoin de ce parametre a on.

      Pour tous ceux qui se sentent concernes par ces problemes de hack: il est peut-etre (je dis bien peut-etre) plus facile de demander a votre hebergeur de changer cette variable que de lui demander de changer register_globals. Mais bon c'est pas sur, on ne peux changer cette valeur que globalement, pas localement pour votre espace d'hebergement.

      Cordialement,
      Richard.
      Association d'entraide de parents de multiples: http://www.jumeaux-et-plus.fr
      École de Musique de Villers-lès-Nancy: http://www.apm-villers.org

      Commentaire


      • #4
        Vous avez de la chance.
        Chez OVH, dans les serveurs mutualisés, allow_url_fopen et register_globals sont tous à ON. Or, presque 80% des hacks des sites hébergés dans leurs mutualisés auraient pu être éviter en positionnant ces 2 variables à OFF. Mais, ils ne le font pas. Pire, ils n'ont aucun serveur mutualisés qui le fait... Pire encore, on ne peut pas modifier ces paramètres individuellement via .htaccess, car leur PHP est en mode CGI .
        Pour tous ceux qui sont hébergés chez OVH, que pensez-vous d'une lettre à pétition adressée à leurs responsables ?

        Commentaire


        • #5
          Envoyé par fan2
          Vous avez de la chance.
          Chez OVH, dans les serveurs mutualisés, allow_url_fopen et register_globals sont tous à ON. Or, presque 80% des hacks des sites hébergés dans leurs mutualisés auraient pu être éviter en positionnant ces 2 variables à OFF. Mais, ils ne le font pas. Pire, ils n'ont aucun serveur mutualisés qui le fait... Pire encore, on ne peut pas modifier ces paramètres individuellement via .htaccess, car leur PHP est en mode CGI .
          • Pour allow_url_fopen de toute facon c'est uniquement via le php.ini systeme.
          • pour register_globals normalement il faut passer par 2 manip: creation d'un php.ini local, et (et la je ne sais pas quelle est la bonne methode, parce que une fois de plus ca depend de leur config) mettre une ligne dans le .htaccess pour dire d'utiliser ce php.ini

            Normalement c'est une ligne du style PHPRC="/chemin/absolu/vers/php.ini", ou la meme avec suPHP_ConfigPath /chemin/absolu/vers/repertoire/contenant/php.ini/

          Bref il y a peut-etre des solutions mais encore faudrait-il avoir sufisamment d'infos pour savoir lesquelles sont valides.

          L'autre probleme des php.ini locaux c'est qu'a priori il faut d'abord partir du php.ini global, sinon on perd toutes les config globales etablies sur le serveur. Du coup attention, on peut aussi perdre des trucs importants, comme les repertoires de sessions, les valeurs de open_basedir (pas sur pour celui-la) etc etc.
          Envoyé par fan2
          Pour tous ceux qui sont hébergés chez OVH, que pensez-vous d'une lettre à pétition adressée à leurs responsables ?
          Si tu as du temps a perdre... Attirer leur attention sur le fait que leur config est particulierement peu securisee oui, mais pour une petition faut voir combien de % de leur clientele ca represente.

          Ce qui est terrible, c'est de voir des hebergeurs aussi mal securises et qui ne t'autorise pas a te securiser toi... Par contre ils seront les premiers a te sauter dessus si ton site est hacke et que grace a ca leurs machines sont utilisee pour un spam massif.

          Autre chose: si les restrictions open_basedir ne sont pas active et que votre hebergeur mutualise ne vous mets pas votre espace web en cage dans un chroot, ben c'est aussi la porte ouverte a du cross-site hacking si les droits de vos fichiers ne sont pas corrects (le piratage du site du voisin donnant acces au votre pour le hacker...). De l'importance d'avoir des chmod corrects.

          Cordialement,
          Richard.
          Association d'entraide de parents de multiples: http://www.jumeaux-et-plus.fr
          École de Musique de Villers-lès-Nancy: http://www.apm-villers.org

          Commentaire


          • #6
            Merci d'avoir fait avancer le chimilibilik
            Vous êtes developpeur, vous aimez joomla! et vous êtes plus malin que les autres puisque vous avez compris que pour recevoir il faut aussi savoir donner... venez nous rejoindre => http://forge.joomla.org/sf/frs/do/vi...ts.jfr_dev/frs (La Forge Francophone)
            Comment poser de bonnes questions ?!
            http://www.gnurou.org/Writing/SmartQuestionsFr
            Création d'un composant pour Joomla! 1.5
            http://wiki.joomlafacile.com/index.p...pour_Joomla%21

            Commentaire


            • #7
              Envoyé par pomelo
              Merci d'avoir fait avancer le chimilibilik
              Malheureusement on en est au même point, voire pire: au moins pour register_globals on a une petit espoir, y a qd même des hébergeurs qui t'autorisent à le modifier localement via un .htaccess ou un php.ini local.

              Pour allow_url_fopen, qui est finalement la vrai clef du problème, c'est un paramètre qui peut uniquement être changé dans la config serveur...

              Ceci étant, il y à une piste de sécurisation: prendre TOUS les sources de TOUTES les extensions, et protéger TOUS les include(), fopen() et autre include_once() par des file_exists(). Vaste programme...

              Dire qu'en Lisp c'est si simple (de mémoire, hein, mes souvenirs sont assez lointains):

              Code:
              ; sauvegarder le symbole de fopen en system-fopen
              (fset 'system-fopen (symbol-function 'fopen))
              ; on le redefini pour n'appeler system-fopen qu'apres verification
              (defun fopen (file) (if (file_exist file) (system-fopen file) nil))
              Et voila, on a remplacé fopen par une version safe, et ceci globalement pour tous les appels futurs a fopen...

              Remarque, imagine un php ou une fois que un hacker est rentré il peut changer toutes les fonctions du système par les siennes. En gros il te faut trois lignes pour écrire un keylogger efficace lol...

              Cordialement,
              Richard.
              Dernière édition par rcognot à 07/09/2006, 21h45
              Association d'entraide de parents de multiples: http://www.jumeaux-et-plus.fr
              École de Musique de Villers-lès-Nancy: http://www.apm-villers.org

              Commentaire


              • #8
                Positivons !!! tu voit la bouteille à moitié vide le coté plein c'est que maintenant si un site a besoin de beaucoup de sécurité (ils sont pas si nombreux dans le fond) on sait que le choix de l'hébergeur passera aussi par allow_url_fopen, çà mérite un

                Ceci étant, il y à une piste de sécurisation: prendre TOUS les sources de TOUTES les extensions, et protéger TOUS les include(), fopen() et autre include_once() par des file_exists(). Vaste programme...
                çà joomla! s'en charge
                Vous êtes developpeur, vous aimez joomla! et vous êtes plus malin que les autres puisque vous avez compris que pour recevoir il faut aussi savoir donner... venez nous rejoindre => http://forge.joomla.org/sf/frs/do/vi...ts.jfr_dev/frs (La Forge Francophone)
                Comment poser de bonnes questions ?!
                http://www.gnurou.org/Writing/SmartQuestionsFr
                Création d'un composant pour Joomla! 1.5
                http://wiki.joomlafacile.com/index.p...pour_Joomla%21

                Commentaire


                • #9
                  Envoyé par rcognot
                  Ceci étant, il y à une piste de sécurisation: prendre TOUS les sources de TOUTES les extensions, et protéger TOUS les include(), fopen() et autre include_once() par des file_exists(). Vaste programme...
                  Je suis pas reveillé moi...

                  Faire une moulinette qui remplace les appels include() par une fonction include_if_exists() c'est d'une simplicité biblique si tu as un accès en shell sur une machine avec perl installé:

                  Code:
                  find . -name \*.php -exec perl -i -p -e 's/include\s*\(/include_if_exists\(/' {} \;
                  Bon, apres faut affiner, on peut ne substituer que ceux pour lequels on passe en parametre non pas un chemin fixe (c'est pas la peine de proteger un "include(configuration.php)", par contre un "include($mosConfig_absolute_path .'/offline.php'" il le faut absolument. Et de meme, remplacer tous les require(). require_once(), etc...

                  Et ensuite mettre les fonctions include_if_exists, require_if_exists etc a un endroit strategique.

                  Cordialement,
                  Richard.
                  Association d'entraide de parents de multiples: http://www.jumeaux-et-plus.fr
                  École de Musique de Villers-lès-Nancy: http://www.apm-villers.org

                  Commentaire


                  • #10
                    Pour allow_url_fopen de toute facon c'est uniquement via le php.ini systeme
                    C'est pas ce qu'ils disent dans la faq
                    http://forum.joomla.org/index.php/topic,100847.0.html

                    Sur un hebergement j'ai rajouté
                    php_flag allow_url_fopen off
                    Je ne sait pas si ça marche, mais je n'ai pas de message d'erreur de apache.
                    Merci d'éviter les demandes de support par MP.

                    Commentaire


                    • #11
                      Envoyé par AniMo Voir le message
                      C'est pas ce qu'ils disent dans la faq
                      http://forum.joomla.org/index.php/topic,100847.0.html
                      Ben voir la doc de php... Il y est bien précisé que ce paramètre ne peut être changé que dans php.ini.

                      Sur un hebergement j'ai rajouté
                      php_flag allow_url_fopen off
                      Je ne sait pas si ça marche, mais je n'ai pas de message d'erreur de apache.
                      Ben mets un phpinfo dans le répertoire. Tu verra que malgré cela allow_url_fopen restera désespérément a On... A moins que ton hébergeur aie trafiqué son php pour l'autoriser, mais ça m'etonnerais franchement...

                      Cordialement,
                      Richard.
                      Association d'entraide de parents de multiples: http://www.jumeaux-et-plus.fr
                      École de Musique de Villers-lès-Nancy: http://www.apm-villers.org

                      Commentaire


                      • #12
                        effectivement, ça marche pas;
                        Bizarre cette faq
                        Merci d'éviter les demandes de support par MP.

                        Commentaire

                        Annonce

                        Réduire
                        1 sur 2 < >

                        C'est [Réglé] et on n'en parle plus ?

                        A quoi ça sert ?
                        La mention [Réglé] permet aux visiteurs d'identifier rapidement les messages qui ont trouvé une solution.

                        Merci donc d'utiliser cette fonctionnalité afin de faciliter la navigation et la recherche d'informations de tous sur le forum.

                        Si vous deviez oublier de porter cette mention, nous nous permettrons de le faire à votre place... mais seulement une fois
                        Comment ajouter la mention [Réglé] à votre discussion ?
                        1 - Aller sur votre discussion et éditer votre premier message :


                        2 - Cliquer sur la liste déroulante Préfixe.

                        3 - Choisir le préfixe [Réglé].


                        4 - Et voilà… votre discussion est désormais identifiée comme réglée.

                        2 sur 2 < >

                        Assistance au forum - Outil de publication d'infos de votre site

                        Compatibilité: PHP 4.1,PHP4, 5, 6DEV MySQL 3.2 - 5.5 MySQLi from 4.1 ( @ >=PHP 4.4.9)

                        Support Version de Joomla! : | J!3.0 | J!2.5.xx | J!1.7.xx | J!1.6.xx | J1.5.xx | J!1.0.xx |

                        Version française (FR) D'autres versions sont disponibles depuis la version originale de FPA

                        UTILISER À VOS PROPRES RISQUES :
                        L'exactitude et l'exhaustivité de ce script ainsi que la documentation ne sont pas garanties et aucune responsabilité ne sera acceptée pour tout dommage, questions ou confusion provoquée par l'utilisation de ce script.

                        Problèmes connus :
                        FPA n'est actuellement pas compatible avec des sites Joomla qui ont eu leur fichier configuration.php déplacé en dehors du répertoire public_html.

                        Installation :

                        1. Téléchargez l'archive souhaitée : http://afuj.github.io/FPA/

                        Archive zip : https://github.com/AFUJ/FPA/zipball/master

                        2. Décompressez le fichier de package téléchargé sur votre propre ordinateur (à l'aide de WinZip ou d'un outil de décompression natif).

                        3. Lisez le fichier LISEZMOI inclus pour toutes les notes de versions spécifiques.

                        4. LIRE le fichier de documentation inclus pour obtenir des instructions d'utilisation détaillées.

                        5. Téléchargez le script fpa-fr.php à la racine de votre site Joomla!. C'est l'endroit que vous avez installé Joomla et ce n'est pas la racine principale de votre serveur. Voir les exemples ci-dessous.

                        6. Exécutez le script via votre navigateur en tapant: http:// www. votresite .com/ fpa-fr.php
                        et remplacer www. votresite .com par votre nom de domaine


                        Exemples:
                        Joomla! est installé dans votre répertoire web et vous avez installé la version française du fichier FPA:
                        Télécharger le script fpa-fr.php dans: /public_html/
                        Pour executer le script: http://www..com/fpa-fr.php

                        Joomla! est installé dans un sous-répertoire nommé "cms" et vous avez installé la version française du fichier FPA:
                        Télécharger le script fpa-fr.php dans: /public_html/cms/
                        Pour executer le script: http://www..com/cms/fpa-fr.php

                        En raison de la nature très sensible de l'information affichée par le script FPA, il doit être retiré immédiatement du serveur après son utilisation.

                        Pour supprimer le script de votre site, utilisez le lien de script de suppression fourni en haut de la page du script. Si le lien de suppression échoue pour supprimer le script, utilisez votre programme FTP pour le supprimer manuellement ou changer le nom une fois que le script a généré les données du site et le message publié sur le forum. Si le script est toujours présent sur le site, il peut être utilisé pour recueillir suffisamment d'informations pour pirater votre site. Le retrait du script empêche des étrangers de l'utiliser pour jeter un oeil à la façon dont votre site est structuré et de détecter les défauts qui peuvent être utilisé à vos dépends.
                        Voir plus
                        Voir moins
                        Travaille ...
                        X