Bonjour, Ceci pour l'écrire quelque-part et vous faire part d'un constat relativement affolant sur la manière de pratiquer l'expertise.
Cela concerne une ``faille de sécurité'' inexistante dans les paquets de bases mais qui devient effective sur des sites installés par des novices, voire par certains scripts d'installations réalisés par des ... (Je ne trouve pas de qualificatifs pour rester poli;) Bref, cela à probablement commencé par: http://httpd.apache.org/docs/2.2/mod/core.html#limit La documentation officielle de Apache, ou l'on peut voir un exemple: <Limit POST PUT DELETE> Require valid-user </Limit> De là, une recherche rapide sur google ``"LIMIT GET" "require valid" CMS'' m'a permi de trouver plein de sites où l'on recommande cette syntaxe: http://www.reubenyau.com/protecting-the-wordpress-wp-admin-folder/ ``This will limit access to this folder by IP address. Any attempts at accessing any file within this folder will be greeted with a Forbidden error message.'' http://forum.joomla.fr/showthread.php?44748-.htaccess-pour-les-nuls http://aide.joomla.fr/questions-diverses/securisez-votre-administration http://fr.w3support.net/index.php?db=so&id=123499 http://www.clicasso.fr/outils/htpasswd.php http://www.exotux.info/2011/06/un-fichier-htaccess-pour-developpeur-web-malheureux/ ... et plein d'autres exemples... C'EST FAUX!!! En fait, il *ne faut pas* utiliser de balises ``<LIMIT>'' du tout!!! (sauf si vous savez ce que vous faite, bien entendu;) Dans la page de la doc de apache, c'est pourtant bien écrit: ``L'exemple suivant n'applique les contrôles d'accès qu'aux méthodes POST, PUT, et DELETE, en laissant les autres méthodes sans protection'' =============================== =============== C'est à dire que la balise ``<LIMIT>'' sert à limiter la condition aux seules méthodes indiquées!! (voir LimitExcept) Bon, il se trouve que pour interroger une pages HTML, Apache n'autorise que la méthode GET (ou HEAD), et donc cela fonctionnera bien. Par contre, accéder à des pages PHP pose un autre problème: Si APACHE connait les méthodes GET, POST, HEAD, PROPFIND, etc, il reste ouvert aux méthodes (futuristes) qu'il ne connait pas... Laissant ainsi le soin au script PHP de gérer la méthode utilisée. Par défaut, PHP se contre-fout de la méthode par laquelle il est accédé. Pour réagir en fonction de la méthode, il faut implémenter la gestion des méthodes dans le script lui-même. Le résultat est qu'il suffit d'``inventer'' une méthode ``ZORGLUB'', et créer une requête HTTP du style: $ echo $'ZORGLUB /dossierprive/script.php?command=dbdump HTTP/1.0\r\nHost: www.unsite.net\r\n\r' | nc www.unsite.net 80 pour envoyer ``command=dbdump'' à http://www.unsite.net/dossierprive/script.php En effet, Apache laisse passer la requête parce qu'elle n'est pas dans la limite des requêtes qui *doivent* satisfaite ``require valid-user''. Et script.php va s'exécuter *avec* les arguments... Si le ``script.php'' ne vérifie pas: - la méthode utilisé ou - le nom d'utilisateur loggué via apache ou - les droits via un autre système d'autentification alors la faille est béante! +++ A l'attention des ISPs: Voici comment j'ai créé un patchfile qui m'a permi de corriger tout # cd RootDomainsDirectory # for corrupt in $( find $PWD -type f -name '.htaccess' -print0 | xargs -0 perl -e ' my @fields=("<limit","require\\s+valid","</limit"); while (my $fname=shift @ARGV) { open FH,"<".$fname; my $lcnt=0; my $note=0; while (<FH>) { $lcnt++ if /<limit/i; $note++ if /$fields[$note]/i; }; close FH; printf "%s\n",$fname if $note > 2 && $lcnt eq 1; };' ) ; do sed -e '/^<[Ll]imit/d;s/<\/[Ll]imit[^>]*>//' < $corrupt | diff -u $corrupt - done | tee /root/correct-limit-apache.patch Après un petit coup d'oeil sur le fichier patch: # vi /root/correct-limit-apache.patch Ou peut l'appliquer: # patch -p0 </root/correct-limit-apache.patch -- Félix Hauri - <[email protected]> - http://www.f-hauri.ch _______________________________________________ gull mailing list [email protected] http://forum.linux-gull.ch/mailman/listinfo/gull
