Sylvain L. Sauvage wrote on Fri, Oct 09, 2015 at 05:03:48PM +0200 > Le vendredi 9 octobre 2015, 16:24:00 Dominique Asselineau a > écrit : > >[???] > > > D???un point de vue réponse HTTP, ces deux scripts vont > > > générer un 200 de la part du serveur HTTP : le fichier > > > 'index.php' a été exécuté et renvoie un contenu. > > > > Un script peut tout à fait retourner une réponse HTTP autre > > que 200. C'est ce que je fais lorsqu'on demande une ressource > > qui n'existe pas ou qui n'est pas autorisée pour la requête. > > Oui. Je donnais juste l???exemple de ces deux scripts : moisi et > moins-moisi. > On pourrait aller plus loin dans les détails et les > possibilités, p.ex. les redirections, les réécritures, ce que > veut dire « exécuter un script », etc. Mais bon, vu la longueur > du fil, les multiples explications, pour arriver à > « index.php?bla et /bla, c???est pareil », on se dit qu???il vaut > mieux rester simple??? > > > Quant aux scripts qui font des includes sur des fichiers dont > > l'adresse est passée en paramètre et sans vérification... ça > > me laisse pantois. Il y en a même qui laissent faire des > > includes sur des URL... Ce qui permet à un spameur de faire > > tourner un moulin à spams chez vous avec votre bande passante > > et surtout votre responsabilité. > > > > Faire vraiment attention aux gentils scripts qui veulent vous > > rendre mille services sans vous dire ce que fait le mille et > > unième. > > J???aimais bien l???époque des premiers CGI, en shell, c???était si > facile de se pendre avec ;o)
Détrompe-toi Sylvain ! C'est arrivé il y a quelques années avec un script PHP justement, trouvé sur le web bien que l'auteur du méfait n'a jamais voulu le reconnaître. Dans l'affaire il y a eu 2 pendus : celui qui a récupéré le script, probablement à Troie... et celui qui a configuré le php.ini en oubliant d'interdire l'inclusion d'URL car en effet, ça peut se configurer au niveau de PHP. Comme quoi il n'y a pas besoin de remonter au siècle dernier avec des CGI en shell pour voir ça. dom --