Bienvenue sur PEBKAC.fr, le site qui recense les anecdotes où l’on se moque des utilisateurs ne maîtrisant pas l’outil informatique. PEBKAC est un acronyme signifiant « Problem Exists Between Keyboard And Chair ».
Le problème se situe entre la chaise et le clavier : soumettez vos histoires, donnez votre avis !
Ce site n'est pas le site original pebkac.fr. Je publie ici la liste des PEBKAC que j'ai pu sauvegarder avant que le site original ne soit mis hors ligne.
Un micro-blog mettait les logs d'accès à l'administration (horaire, adresse IP, User-Agent) dans un fichier PHP en commentaire. Le problème, c'est qu'en modifiant l'entête de la requête en mettant comme User-Agent : ?><?php [code PHP], alors ce code PHP inséré dans l'entête est exécuté lors de l'accès au fichier log, par quiconque.

J'envoie un e-mail au créateur lui expliquant la faille, et lui propose comme solution de les mettre dans un fichier log protégé tant bien que mal (.htacess, changer le nom du fichier en .ht.access.log, droit de lecture, etc.).

Il m'a répondu que tous les hébergeurs n'autorisaient pas les fichiers .htaccess, ce qui laisserait ces informations aux mains de quiconque.
La faille n'est toujours pas corrigée. PEBKAC.
PEBKAC #7772 proposé par but2ene le 11/05/2013 | 17 commentaires | 👍🏽 👎🏽 +156
« Il m'a répondu que tous les hébergeurs n'autorisaient pas les fichiers .htaccess »
C'est vrai, surtout ceux qui ne sont pas sous apache, mais il ne s'est jamais demandé si son hébergeur l'autorisait ?
Commentaire #92196 écrit par BSK le 11/05/2013 à 15h15 | 👍🏽 👎🏽
.htaccess ou pas, pourquoi stocker du log dans un fichier de script en commentaire ?
Il n'y avait rien de plus tordu ?

Même si le fichier n'est pas protégé, ya moyen de le caser dans un foutu txt, c'est pas comme si c'était des informations capitales pour la sécurité des utilisateurs ...
Commentaire #92214 écrit par iTux le 11/05/2013 à 18h15 | 👍🏽 👎🏽
L'erreur ici a été de proposer une solution au lieu de pointer le problème du doigt et s'arrêter à ça. Les gens ont souvent tendance à se focaliser sur la dernière chose qu'ils lisent ou entendent, en oubliant tout le reste. Donc, il faut mettre le plus important à la fin.

Bien expliquer le problème est le plus important dans ce genre de remontées.
Commentaire #92244 écrit par OzoneGrif le 12/05/2013 à 00h23 | 👍🏽 👎🏽
Joli faille trouvée, pas un truc habituel de script-kiddy qui a appris par cœur les failles les plus répandues. Dommage qu'ils n'aient personne chez eux assez débrouillard pour corriger ce problème...
Je n'ai pas très bien saisi la manière proposée de la corriger avec un .htaccess, mais il va de soi qu'il est ridicule de stocker ces données dans un exécutable.
Commentaire #92260 écrit par Noraa le 12/05/2013 à 12h35 | 👍🏽 👎🏽
Comme d'habitude c'est une version courte. J'ai montré le problème avec telnet, expliqué pourquoi ce qu'il fait est dangereux et montré plusieurs méthodes pour le résoudre. Tout cela dans plusieurs mails.

Je ne pense pas que s'arrêter au premier mail aurait changé quelque chose. Il a l'air assez têtu
Ce n'est pas vraiment mon problème.
Commentaire #92266 écrit par but2ene le 12/05/2013 à 14h54 | 👍🏽 👎🏽
Le but est de cacher le log. Donc la pire des choses est la méthode qu'il utilise. Une meilleure reste simplement de
d'écrire un fichier avec une autre extension .log me parait adéquate.
Puis rendre le fichier inaccessible au serveur web. Mais en même temps ce ne sont pas des infos sensibles.

J'ai pris l'exemple d'apache, équipant 65% de serveur web. Dans la configuration de base,il refuse de lire tout fichiers commençant par .ht., simplement ajouter une directive dans le .htaccess ou changer les droits du fichier.
Commentaire #92267 écrit par but2ene le 12/05/2013 à 14h55 | 👍🏽 👎🏽
Certains enfants sont allergiques au PVC. C'est donc mieux de laisser le contacteur de prises 220v à l'air libre. C'est plus sûr ;)
Commentaire #92268 écrit par but2ene le 12/05/2013 à 15h00 | 👍🏽 👎🏽
lapin compris…

Je disais juste que ça remarque est vrai dans le cas général, mais que l'on se fout du cas général pour un site en particulier.

À moins que tu parles dans ton PEBKAC d'un moteur de blog, destiné à être hébergé sur des serveurs divers et variés… auquel cas il a raison même si c'est mal implémenté.

Exemple d'un fichier de log de Joomal (logs/error.php) :
#
 #<?php die('Forbidden.'); ?>
 ...


Le véritable problème (et la solution), c'est qu'il a oublié de protéger ses chaines.
Commentaire #92270 écrit par BSK le 12/05/2013 à 15h56 | 👍🏽 👎🏽
S'il y a les IP, on peut considérer que ça relève de la vie privée, donc ça n'a pas à être public.
Commentaire #92271 écrit par BSK le 12/05/2013 à 16h03 | 👍🏽 👎🏽
Le die('Forbidden.') n'est pas sur. Php ne lit tout le fichier avant d'exécuter quoi que ce soit.
Je ne connais pas assez l'interpréteur PHP pour te dire qu'il n'y pas de directive spéciale. Mais ma fonction dodo est bien créée. Donc pourquoi pas d'autres ?

<?php dodo("HELO");?>
 #<?php die('Forbidden.'); ?>
 <?php function dodo($haha){echo $haha; } ?>
 


Mettre des log dans des fichiers PHP est une hérésie. Une règle de base en sécurité est de séparer les données du programme.

On le voit très bien dans les injections SQL avec les entrées «protégés», concaténées dans la requête.
Si la requête était en deux partie comme dans les prefetchs. On n'aurait pas ce problème.

En voyant ce genre de choses, ça ne me donne pas envie de l'utiliser.
Commentaire #92273 écrit par but2ene le 12/05/2013 à 17h03 | 👍🏽 👎🏽
Tu met tout hors du /www/, ou dans le /www/ mais avec un CHMOD correcte pour que seul PHP/le-user-FTP puissent agir dessus.

(c'est vrai que l'IP est une donnée de "vie privée" après tu la communique par défaut à tous les serveurs que tu contacte et on est loin de la criticité d'un mdp ou d'un n° de CB)
Commentaire #92276 écrit par blag le 12/05/2013 à 17h30 | 👍🏽 👎🏽
Les droits ça marche pas vraiment, car la plus part du temps php tourne avec les droits du serveur web. Pour ce qui est de le mettre hors du dossier du site, ce n'est pas toujours possible en fonction de l'hébergement.

Tu communiques ton IP à tous les serveurs, mais eux n'ont pas à la communiquer à tout le monde.
Commentaire #92278 écrit par BSK le 12/05/2013 à 18h04 | 👍🏽 👎🏽
Il y a beaucoup d'hérésies dans le développement web. Ici c'est l'une des rares manières portables.
Commentaire #92279 écrit par BSK le 12/05/2013 à 18h10 | 👍🏽 👎🏽
Enfin une rare manière portable de mettre de grosses failles critique dans son application.
Après chacun s'amuse comme il veut. Je n'ai rien contre :)

On ne peut pas dire que joomla est un exemple à suivre.
Commentaire #92280 écrit par but2ene le 12/05/2013 à 18h25 | 👍🏽 👎🏽
Pour les qqs serveurs web que j'ai eu à fréquenter, un chmod bien fait des fichiers via php sortais un denied sur toutes les tentative http, mais c'est vrai que tu tombe pas toujours sur un serveur correctement administré...
(et pour le hors /www/ de même, tu ne l'a pas toujours)

Après il faut parfois savoir ce que tu veux, si tu prend un truc gratos, il ne faut pas t'étonner de pas avoir d'axx SSH et d'être limité sur les options.
Commentaire #92286 écrit par blag le 12/05/2013 à 22h20 | 👍🏽 👎🏽
Ok, je ne savais pas pour les .ht*, c'est en effet une manière simple de le rendre innacessible.
Commentaire #92295 écrit par Noraa le 13/05/2013 à 11h22 | 👍🏽 👎🏽
Il y a
<?php __halt_compiler(); ?> dans le genre sécuritaire, car il est garantis que le compilateur n'ira jamais plus loin que cette ligne.

Très peu utilisé et connu, mais ça a quelques utilités dans le genre.
Commentaire #94799 écrit par Max-P le 29/05/2013 à 21h53 | 👍🏽 👎🏽