In article <48db6cf5$0$13330$426a74cc***news.free.fr>,
"Antoine\.L" <nepa***mec.rir> wrote:

> Bonjour
>
> Voici ce que j'ai trouvé dans les logs d'accès à mon site internet :
>
> http://urldemonsite/index.php?x=http....com/test.txt?
>
> Quel est le rôle de ce fichier test.txt ?
>
> Que cherchait on à faire ?

En général, c'est pour faire une injection de code PHP.
Ça fonctionne si le serveur est hyper mal configuré.

patpro

--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133

In article <gbg06e$u75$1***news.httrack.net>,
Xavier Roche <xroche***free.fr.NOSPAM.invalid> wrote:

> patpro ~ Patrick Proniewski wrote:
> > En général, c'est pour faire une injection de code PHP.
>
> Ie. si vous faites quelque chose comme un ***include($x.'.php')
>
> > Ça fonctionne si le serveur est hyper mal configuré.
>
> Humm, c'est toujours activé par défaut dans php à priori (de même que
> fopen('http://...')). Le problème est la non vérification de la variable
> injectée.


apres vérif ça donne :

allow_url_fopen = On
allow_url_include = Off

dans mon php.ini-dist (ports FreeBSD).

C'est donc partiellement problématique, mais le gros du pire est quand
même évité.
Corrigez moi si je me trompe, mais le fopen n'est pas dangereux en terme
d'injection de code PHP, sauf si on fait bêtement un exec sur le contenu
du fichier ouvert.

Le soucis, c'est qu'avec les applications web 2.0 (hahaha), les sites se
pinguent dans tous les sens, font tout et n'importe quoi, et interdir
fopen des URL peut sans doute facilement casser quelque chose.


> Toujours, _toujours_ vérifier les données venant de l'exterieur (ici,
> une variable postée)

(c'est du GET, pas du POST )

> de manière paranoïaque. Toujours.

Oui, toujours.
Éventuellement, installer mod_security.

Pour ma part, j'ai aussi configuré mon firewall pour que le user du
serveur web ne puisse pas sortir sur d'autres ports sur le 80 et 443. En
soi, cela n'interdit pas les injections, mais ça rend la chose moins
intéressante (exit les relay irc, ...).


patpro

--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133

In article <gbghjt$en3$2***news.httrack.net>,
Xavier Roche <xroche***free.fr.NOSPAM.invalid> wrote:

> patpro ~ Patrick Proniewski a écrit :
> > allow_url_include = Off
>
> Ah, c'est mieux déja
>
> > Corrigez moi si je me trompe, mais le fopen n'est pas dangereux en terme
> > d'injection de code PHP, sauf si on fait bêtement un exec sur le contenu
> > du fichier ouvert.
>
> Oui, pour le fopen c'est à priori peu problématique.
>
> > Pour ma part, j'ai aussi configuré mon firewall pour que le user du
> > serveur web ne puisse pas sortir sur d'autres ports sur le 80 et 443. En
> > soi, cela n'interdit pas les injections, mais ça rend la chose moins
> > intéressante (exit les relay irc, ...).
>
> En sortie aussi ? Un script php qui lance en arière plan une socket vers
> l'exterieur et y pipe un shell, c'est faisable

uniquement en sortie, puisque c'est une regle qui se base sur l'UID du
process local.
Dans mon cas, l'UID 80 (www) n'est autorisée à émettre des packets que
vers les ports 80 et 443 (et vers les connexions ouvertes par des
clients, bien évidement).
Il y a toujours des cas où on pourra tourner autour. Mais mon but était
surtout d'éviter que la compromission du serveur web permette de faire
des connexions sauvages vers l'extérieur.

patpro

--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133

In article <gbj6ng$4mc$1***news.httrack.net>,
Xavier Roche <xroche***free.fr.NOSPAM.invalid> wrote:

> patpro ~ patrick proniewski a écrit :
> > Dans mon cas, l'UID 80 (www) n'est autorisée à émettre des packets que
> > vers les ports 80 et 443 (et vers les connexions ouvertes par des
> > clients, bien évidement).
>
> Donc si le script lance une connexion avec un shell pipé vers une
> machine extérieure sur le port 80, c'est bon

oui, mais pour arriver là, y'a du boulot.

patpro

--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133