Tentatives possible réussies attaque serveur

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On 09/10/2015 13:27, andre_debian@numericable.fr wrote:

Merci de cette réponse aussi détaillée que longue :-)

Le error.log d'apache2 n'indique pas d'erreur particulière.

si je tape dans la barre d'URL :
"www.monsite.com/index?rev==../../../../... /etc/passwd", je reçois
: Erreur ! J'y ai mis une protection sur l'accès aux répertoires
sensibles.

Le plus sure est d'utiliser des pages statique (100% HTML) avec
des liens fixe pointant vers les pages que vous souhaitez rendre
accessible depuis votre page :

C'est ce qui est fait, mais les pages 100% html sont nommées
"<fichier>.php".

Je voulais dire par pages 100% HTML des pages contenant aucun code
dynamique (pas de PHP).

pour la sécurité d'une page Internet dynamique tout les arguments
passés a une page Internet, qu'ils soit par l'URL ou par des
formulaires, sont à considérer comme potentiellement dangereux :

Le PHP est un langage de sites dynamiques, comment faire autrement
?

"php.ini" traite les variables de formulaires, selon le mode
"register_global = off", avec transmission de la variable à la page
de traitement par : ...$_POST["name"]... Que peut-on faire de plus
?

Filtrer en supprimant tout motif suspicieux du contenu des variables
dites super-globales telle que $_GET, $_POST, $_FILE, etc...
(http://php.net/manual/fr/language.variables.superglobals.php). Ces
variables peuvent contenir des informations venant des visiteurs de
votre sites Internet et donc potentiellement contenir des vecteurs de
compromissions.

Dans le cas spécifique à votre question la méthode de ma réponse
prétendante est un moyen possible. Je cite :

"Dans le cas de la sécurité lors d'inclusion de fichier, qui n'est qu'un
concept de sécurité des sites internet dynamique parmi plusieurs
autres, il faut que tout les tentatives d'inclusions de fichiers soit
vers des fichiers que vous avez expressément vérifié comme étant
légitimes." (Création d'une Whitelist par exemple.)

sinon de ne pas créer de sites Web :-)

Les pages statiques, sans code dynamique telle que PHP, sont une
solution sûre.

André

Florian.

On Tuesday 06 October 2015 19:16:32 BERBAR Florian wrote:

On 02/10/2015 15:13, andre_debian@numericable.fr wrote:

Je reçois ce message d'alerte (logwatch), venant d'un
serveur sous Debian : A total of 3 possible successful
probes were detected (the following URLs contain
strings that match one or more of a listing of strings
that indicate a possible exploit):
/index.php?rev=../ect/passwd HTTP Response 200

/index.php?rev=../../../../../../../../../../../../../../../../../

..

/etc/passwd

HTTP Response 200

/index.php?rev=../../../../../../../../../etc/passwd
HTTP Response 200 ==================== Il est indiqué
"3 possible tentatives avec succès..." Y a t-il un
danger que les mots de passe soient connus... ?

Cette alerte fait référence à une attaque nommé "Local File
Inclusion". Cette technique permet à un utilisateur mal
attentionnée d'inclure dans le contenu d'une page, soufrant de ce
problème de conception, un fichier présent sur le serveur
hébergeant le site internet (Fichier Local au serveur). Dans le
cas de votre extrait de Log, le fichier qui à tenté d'être inclut
est le fichier '/etc/passwd'.

Que ces trois requêtes HTTP répondent toutes les trois le code
de réponse HTTP 200 (Code signifiant réponse HTTP réussi). Cela
ne signifie pas distinctement la réussite de l'attaque visant à
accéder au fichier '/etc/passwd' de votre serveur. En effet toute
requête HTTP valide vers une page mise à disposition par un
serveur HTTP (apache, nginx, etc..) renvoie le code 200 lorsque
la page est accessible. Vulgairement, si le fichier 'index.php'
existe sur votre serveur, votre serveur répondra le code 200
lorsqu'un utilisateur tentera d'accéder à cette page, et ce
quelque soit l'argument passé à cette page.

Dans le cas de votre log, nous voyons que les 3 requêtes relevés
par l'utilitaire 'watchlog' répondent toutes les 3 un code 200.
Et c'est 3 requêtes ont à chaque fois un argument différent :

* ?rev=../ect/passwd *
?rev=../../../../../../../../../../../../../../../../../../etc/passwd

* ?rev=../../../../../../../../../etc/passwd

La réponse d'un code de réponse HTTP 200 n'étant pas un élément
suffisant pour dire que cela est l'efficience d'une intrusion, il
faut aussi savoir que l'inclusion réussi d'un fichier ne génère
aucune erreurs. Dans ce genre de cas, l'audit, communément
appeler "analyse forensic", permettant de savoir si il y eu
réellement une intrusion peut s'avérer vraiment difficile.

Pour vous donner un ordre idée, les éléments techniques
nécessaires pour le diagnostique des 3 paragraphes ci-dessus
nécessite la connaissance des éléments suivants :

La concepts de base du protocole HTTP :
http://abcdrfc.free.fr/rfc-vf/rfc3229.html Les concepts de base
du langage PHP : http://fr.php.net/manual/fr/ Les chemins d'accès
aux fichiers : http://www.cyberciti.biz/faq/relative-pathname/
Les rudiments sur le fichier de mots de passe de Linux :
http://man7.org/linux/man-pages/man5/passwd.5.html

A votre niveau, votre extrait de log fait référence à 3
tentatives d'inclusion de fichier avec un argument différent. Ces
arguments étant des chemin d'accès, cela laisse la chance qu'il
ait un échec d'inclusion et donc une erreur dans vos log.

L'erreur relative à l'inclusion d'un fichier, dans une
configuration conventionnel, n'est pas une réponse du protocole
HTTP mais un message générer par le moteur de script permettant
la génération d'un contenu dynamique : PHP, ASP, Python, etc...

Il est intéressant de regarder les erreurs de ce dernier afin
d'avoir une meilleur idées au sujet de l'éventuelle inclusion
survenu sur votre serveur.

Ce sont les motifs suspicieux "../" et "/etc/passwd" qui ont fait
réagir l'utilitaire 'watchlog'. Ces motifs sont des éléments
rencontrés lors d'intrusion et il est intrigant de les trouver
dans une requête HTTP conventionnelle. Je pense que ces lignes de
log sont à voir comme des éléments initiaux d'une investigation
plus avancées pouvant être décider par le responsable d'un
serveur. Et cela est unique l'intêret d'un outil d'analyse de
fichier Log.

A ce niveau, cette investigation est la vérification des erreurs
PHP via le fichier 'syslog', le systéme de journal de 'systemd'
ou les logs de votre services de serveur WEB. Vous avez fait
référence à "apache" dans les messages précédant et au vu de la
sortie de votre outils d'audit de log votre moteur de script
dynamique est PHP. Il serait intéressant, dans le cas d'un désir
d'investigation de votre part, de regarder les erreurs de PHP
relatives aux fonctions d'inclusion de contenu de PHP dans le
fichier de Log '/var/log/apache/error.log'.

Je précise que la lecture des documentations ci-dessus sont
nécessaires pour cette investigation.

Les mots de passe, non, mais les logins et les mots de
passe chiffrés. Sans indiscrétion, quel est ce index.php
moisi ? Cordialement, JKB

Le fichier d'index du site et pourquoi serait-il "moisi" ?
p. ex : "http://trucmuche.fr/index.php?rev=kata.php"

Ce qui m'inquiète, c'est la réponse '200' qui aurait tendance
à indiquer qu'un utilisateur distant peut récupérer le
contenu de /etc/passwd. Si c'est le cas, le fichier
index.php est moisi et la configuration d'apache est à
revoir. La question était : est-ce que le index.php est fait
maison ou provient d'un logiciel tiers (spip, joomla ou
autre) ? JKB

fait maison, c'est du classique dans les sites Web, la page
"index.php" reçoit les contenus des autres pages.

J'imagine que vous faites référence à l'utilisation des
fonctions "include" ou "require" de PHP. Ces dernières sont connu
pour être sensible pour la sécurité d'un site Internet et du
serveur qui l'héberge .

Comment faire autrement ?

Le plus sure est d'utiliser des pages statique (100% HTML) avec
des liens fixe pointant vers les pages que vous souhaitez rendre
accessible depuis votre pages.

Si vous souhaitez maintenir une technologie dynamique pour votre
page Internet, il est intéressant de connaître les risques
d'implémentation de se type de langage.

Dans le contexte de votre question, il est capitale de savoir que
pour la sécurité d'une page Internet dynamique tout les arguments
passés a une page Internet, qu'ils soit par l'URL ou par des
formulaires, sont à considérer comme potentiellement dangereux.
La sécurité de toute votre infrastructure dépends du fait qu'ils
soient filtrés le plus strictement possible.

Dans le cas de la sécurité lors d'inclusion de fichier, qui n'est
qu'un concept de sécurité des sites internet dynamique parmi
plusieurs autres, il faut que tout les tentatives d'inclusions de
fichiers soit vers des fichiers que vous avez expressément
vérifié comme étant légitimes.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQIcBAEBCAAGBQJWF69RAAoJEBGYNnE0a7qPjLUQALFpvLTCvnq4vhPtpgHXaYlh
Ps5e0A2sUYpitvZWFQMggtwXA5LxIUQ3Ya/jsZ65t4B47KXjPGGVnwKyiYfJvVVj
pkOKVwvbnSYsiXra1XiKxDHtIXgJp2DPHnG6ley7KapJd62GxGFzLjV65ZtfWgKh
eNoG9HSPPQ0s0F5ny7SxQmRtksJunyiVgo0QKdQHV1bK5dcJCDXfuQcceQMwxqwQ
hEYKDLhYUW5ZZ0Yx+/xuGJt7sj3Vrw8aIL/z1kshyJqGwKk4bmF1+BqjEoOSRH1g
hOJRI8wGHm4F9DnWQrq3wqha8swEXnQu439Sqn5g9k3EAq9aJ0ON4DCx7DZeDaJ7
ZQgTj3l7/rEd8Aftodi469rdsgYl2uTYwyidAO/E9HwH/kQVl1W8KZFA3JNA6FM9
X/OPHBLEcxv9kWzQxLeTel43i4BIbN3Y3UQEWKres0iNiDEhBZ4dUuGdItF+XuZw
qnJ9PQIgazIi/YgY41V2HvPOsbXYgjM3To34izHD63pREPeIEhGKt+44H6qv1Bjx
somknjoCw9/BbA5J/RHgZTJsqWOJlJIBQ2zNNdY5wVAcuzUYnvIbr8HvDJ10fRRU
OX/QvJ4L+N80A+nD3hjuT/4ikahAf9+ByHroeBcrswl6b6iW85Pa71Fvg9qLu3Dc
bPF1qiZ7VTcCAkQBbOSh
î8K
-----END PGP SIGNATURE-----

Le vendredi 09 octobre 2015 à 13:27, andre_debian@numericable.fr a écrit :

Je ne sais plus qui, je ne sais plus quand (ça a été tronqué) a écrit :
> pour la sécurité d'une page Internet dynamique tout
> les arguments passés a une page Internet, qu'ils soit
> par l'URL ou par des formulaires, sont à considérer
> comme potentiellement dangereux :

Le PHP est un langage de sites dynamiques,
comment faire autrement ?

PHP a une très mauvaise réputation de nid à failles. Cette réputation n'est pas
forcément très objective mais parmi les arguments qui l'ont faite, on trouve :
- que l'API n'est pas très rigoureuse;
- qu'on peut développer un site en PHP sans trop de connaissances (et donc
sans forcément trop de sécurité non plus).

"php.ini" traite les variables de formulaires,
selon le mode "register_global = off",
avec transmission de la variable à la page de traitement par :
...$_POST["name"]...
Que peut-on faire de plus ?

Ma réponse est indépendante du langage utilisé et vaut autant pour PHP que pour
tout autre langage utilisé pour créer des sites dynamiques (et même d'une
manière large des programmes client/serveur) :

Ne _jamais_ faire confiance à ce qui arrive du client !

Tu considères que tout est douteux et tu vérifies _scrupuleusement_ tout ce qui
arrive :
- est-ce que le nombre que tu attends est bien seulement un nombre;
- est-ce que la chaîne que tu attends ne contient pas de quoi faire de
l'injection SQL;
- est-ce que la chaîne que tu attends ne contient pas de quoi faire du XSS;
- etc.

Pour ça, les expressions rationnelles sont un très bon allié.

Sébastien

Merci de la piqûre de rappel ci-dessous concernant les
langages dynamiques Web.

Les documents sur la sécurité abondent en ce sens,
dont surtout la réinjection de codes dans les pages Web.

La question initiale était :
/index.php?rev=../../../../../../../../../etc/passwd
HTTP Response 200, possible tentatives avec succès..."

Mais rien n'empêche de taper directement ceci :
"www.monsite.com/../../../../... /etc/passwd

Le fait d'avoir une page d'index ou non,
"/index.php?rev=../../../../../../../../../etc/passwd"
ne doit pas changer grand chose...

André

On Friday 09 October 2015 14:30:54 Sébastien NOBILI wrote:

Le vendredi 09 octobre 2015 à 13:27, andre_debian@numericable.fr a éc rit :
> Je ne sais plus qui, je ne sais plus quand (ça a été tronqué) a écrit :
> > pour la sécurité d'une page Internet dynamique tout
> > les arguments passés a une page Internet, qu'ils soit
> > par l'URL ou par des formulaires, sont à considérer
> > comme potentiellement dangereux :
>
> Le PHP est un langage de sites dynamiques,
> comment faire autrement ?

PHP a une très mauvaise réputation de nid à failles. Cette réputa tion n'est

pas

forcément très objective mais parmi les arguments qui l'ont faite, on

trouve :

- que l'API n'est pas très rigoureuse;
- qu'on peut développer un site en PHP sans trop de connaissances ( et

donc

sans forcément trop de sécurité non plus).

> "php.ini" traite les variables de formulaires,
> selon le mode "register_global = off",
> avec transmission de la variable à la page de traitement par :
> ...$_POST["name"]...
> Que peut-on faire de plus ?

Ma réponse est indépendante du langage utilisé et vaut autant pour PHP que

pour

tout autre langage utilisé pour créer des sites dynamiques (et même d'une
manière large des programmes client/serveur) :

Ne _jamais_ faire confiance à ce qui arrive du client !

Tu considères que tout est douteux et tu vérifies _scrupuleusement_ t out ce

qui

arrive :
- est-ce que le nombre que tu attends est bien seulement un nombre;
- est-ce que la chaîne que tu attends ne contient pas de quoi faire de
l'injection SQL;
- est-ce que la chaîne que tu attends ne contient pas de quoi faire du

XSS;

- etc.

Pour ça, les expressions rationnelles sont un très bon allié.

Sébastien

Mais rien n'empêche de taper directement ceci :
"www.monsite.com/../../../../... /etc/passwd
Le fait d'avoir une page d'index ou non,
"/index.php?rev=../../../../../../../../../etc/passwd"
ne doit pas changer grand chose...

bonjour,
En principe, le serveur est conçu pour limiter l’arborescence exposée.
Pour peu que le paramétrage par défaut soit correct et n'ai pas été
altéré imprudemment, il offre une bonne protection. Cependant les
pages PHP peuvent contourner cette protection si elles sont écrites
imprudemment, car le moteur d'exécution PHP a beaucoup plus de
latitude pour accéder à des fichiers que le serveur Web...d'oà ¹
l'apparition de failles qui n'existe pas dans les sites statiques.

cordialement

______________
Éric Dégenètais
Henix


http://www.henix.com
http://www.squashtest.org



Le 9 octobre 2015 14:47, <andre_debian@numericable.fr> a écrit :

Merci de la piqûre de rappel ci-dessous concernant les
langages dynamiques Web.

Les documents sur la sécurité abondent en ce sens,
dont surtout la réinjection de codes dans les pages Web.

La question initiale était :
/index.php?rev=../../../../../../../../../etc/passwd
HTTP Response 200, possible tentatives avec succès..."

Mais rien n'empêche de taper directement ceci :
"www.monsite.com/../../../../... /etc/passwd

Le fait d'avoir une page d'index ou non,
"/index.php?rev=../../../../../../../../../etc/passwd"
ne doit pas changer grand chose...

André

On Friday 09 October 2015 14:30:54 Sébastien NOBILI wrote:

Le vendredi 09 octobre 2015 à 13:27, andre_debian@numericable.fr a écrit :
> Je ne sais plus qui, je ne sais plus quand (ça a été tr onqué) a écrit :
> > pour la sécurité d'une page Internet dynamique tout
> > les arguments passés a une page Internet, qu'ils soit
> > par l'URL ou par des formulaires, sont à considérer
> > comme potentiellement dangereux :
>
> Le PHP est un langage de sites dynamiques,
> comment faire autrement ?

PHP a une très mauvaise réputation de nid à failles. Cett e réputation n'est

pas

forcément très objective mais parmi les arguments qui l'ont fa ite, on

trouve :

- que l'API n'est pas très rigoureuse;
- qu'on peut développer un site en PHP sans trop de connaissanc es (et

donc

sans forcément trop de sécurité non plus).

> "php.ini" traite les variables de formulaires,
> selon le mode "register_global = off",
> avec transmission de la variable à la page de traitement par :
> ...$_POST["name"]...
> Que peut-on faire de plus ?

Ma réponse est indépendante du langage utilisé et vaut au tant pour PHP que

pour

tout autre langage utilisé pour créer des sites dynamiques (et même d'une
manière large des programmes client/serveur) :

Ne _jamais_ faire confiance à ce qui arrive du client !

Tu considères que tout est douteux et tu vérifies _scrupuleuse ment_ tout ce

qui

arrive :
- est-ce que le nombre que tu attends est bien seulement un nombre;
- est-ce que la chaîne que tu attends ne contient pas de quoi f aire de
l'injection SQL;
- est-ce que la chaîne que tu attends ne contient pas de quoi f aire du

XSS;

- etc.

Pour ça, les expressions rationnelles sont un très bon allià ©.

Sébastien

Le vendredi 9 octobre 2015, 14:47:01 andre_debian@numericable.fr
a écrit :

Merci de la piqûre de rappel ci-dessous concernant les
langages dynamiques Web.

Les documents sur la sécurité abondent en ce sens,
dont surtout la réinjection de codes dans les pages Web.

La question initiale était :
/index.php?rev=../../../../../../../../../etc/passwd
HTTP Response 200, possible tentatives avec succès..."

Mais rien n'empêche de taper directement ceci :
"www.monsite.com/../../../../... /etc/passwd

Le fait d'avoir une page d'index ou non,
"/index.php?rev=../../../../../../../../../etc/passwd"
ne doit pas changer grand chose...

Ok, donc, malgré tout ce qui a été dit dans ce fil, tu n’as
pas compris le protocole HTTP : ces requêtes ne sont pas
équivalentes.

Passer par un fichier PHP mal écrit qui va pouvoir lire
n’importe quel fichier sur ta machine si on lui passe un chemin
dans le bon paramètre n’est pas équivalent à fai re une requête
que le serveur va savoir refuser. À moins que celui qui a écr it
le fichier PHP moisi soit aussi celui qui a écrit le serveur
HTTP, ce dernier n’acceptera pas d’aller remonter plus haut que
sa racine (p.ex. /var/www).

La requête '/index.php?rev=../../etc/passwd' signifie
« exécuter le script 'index.php' en lui passant la variable
'rev' à '../../etc/passwd' ». Le script fait ce qu’il veut avec
son paramètre 'rev'. Un script moisi va s’en servir pour a ller
ouvrir le fichier et l’inclure dans la réponse sans
vérification. Un script moins moisi va vérifier la valeur du
paramètre et ne pas s’en servir.
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.

La requête '/../../../etc/passwd', en général, n†™est pas
valide, et va donc générer une réponse 404.
(On peut avoir un serveur web qui renvoie toutes ou certaines
URL comme paramètre à l’exécution d’un s cript, lequel peut être
plus ou moins moisi, mais il faut lui demander.)

Il est beaucoup plus fréquent de trouver un script PHP moisi
que de trouver un serveur web qui va aller chercher n’importe
quel fichier sur la machine, ne serait-ce que parce qu’il y a
beaucoup plus de scripts PHP que serveurs web…

--
Sylvain Sauvage

Sylvain L. Sauvage wrote on Fri, Oct 09, 2015 at 03:39:57PM +0200

Le vendredi 9 octobre 2015, 14:47:01 andre_debian@numericable.fr
a écrit :
> Merci de la piqûre de rappel ci-dessous concernant les
> langages dynamiques Web.
>
> Les documents sur la sécurité abondent en ce sens,
> dont surtout la réinjection de codes dans les pages Web.
>
> La question initiale était :
> /index.php?rev=../../../../../../../../../etc/passwd
> HTTP Response 200, possible tentatives avec succès..."
>
> Mais rien n'empêche de taper directement ceci :
> "www.monsite.com/../../../../... /etc/passwd
>
> Le fait d'avoir une page d'index ou non,
> "/index.php?rev=../../../../../../../../../etc/passwd"
> ne doit pas changer grand chose...

Ok, donc, malgré tout ce qui a été dit dans ce fil, tu n’as
pas compris le protocole HTTP : ces requêtes ne sont pas
équivalentes.

Passer par un fichier PHP mal écrit qui va pouvoir lire
n’importe quel fichier sur ta machine si on lui passe un chemin
dans le bon paramètre n’est pas équivalent à faire une requête
que le serveur va savoir refuser. À moins que celui qui a écrit
le fichier PHP moisi soit aussi celui qui a écrit le serveur
HTTP, ce dernier n’acceptera pas d’aller remonter plus haut que
sa racine (p.ex. /var/www).

La requête '/index.php?rev=../../etc/passwd' signifie
« exécuter le script 'index.php' en lui passant la variable
'rev' à '../../etc/passwd' ». Le script fait ce qu’il veut avec
son paramètre 'rev'. Un script moisi va s’en servir pour aller
ouvrir le fichier et l’inclure dans la réponse sans
vérification. Un script moins moisi va vérifier la valeur du
paramètre et ne pas s’en servir.
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.

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.

dom

La requête '/../../../etc/passwd', en général, n’est pas
valide, et va donc générer une réponse 404.
(On peut avoir un serveur web qui renvoie toutes ou certaines
URL comme paramètre à l’exécution d’un script, lequel peut être
plus ou moins moisi, mais il faut lui demander.)

Il est beaucoup plus fréquent de trouver un script PHP moisi
que de trouver un serveur web qui va aller chercher n’importe
quel fichier sur la machine, ne serait-ce que parce qu’il y a
beaucoup plus de scripts PHP que serveurs web…

--
Sylvain Sauvage

--

Le 9 octobre 2015 16:24, Dominique Asselineau
<asseline@telecom-paristech.fr> a écrit :

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.

Certes...mais il y a des cas où il vaut mieux retourner 200 tout le
temps. Après tout, index.php existe, l'URL est donc correcte, donc 404
n'est pas tout à fait une réponse adaptée. Quand un robot fa it du
sondage en masse, lui retourner un code d'erreur sauf si ça tappe
juste peut l'aider à trouver.
Par exemple, renvoyer un 200 uniquement en cas de succès de login est
de nature à faciliter les attaques en force...

______________
Éric Dégenètais
Henix


http://www.henix.com
http://www.squashtest.org

Le vendredi 9 octobre 2015, 16:24:00 Dominique Asselineau a
écrit :

[…]
> D’un point de vue réponse HTTP, ces deux scripts von t
> 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 e t
moins-moisi.
On pourrait aller plus loin dans les détails et les
possibilités, p.ex. les redirections, les réécritures, c e que
veut dire « exécuter un script », etc. Mais bon, vu la l ongueur
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 shel l, c’était si
facile de se pendre avec ;o)

--
Sylvain Sauvage

Le 9 oct. 2015 à 16:46, Eric Degenetais <edegenetais@henix.fr> a écrit :

Le 9 octobre 2015 16:24, Dominique Asselineau
<asseline@telecom-paristech.fr> a écrit :

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.

Certes...mais il y a des cas où il vaut mieux retourner 200 tout le
temps. Après tout, index.php existe, l'URL est donc correcte, donc 404
n'est pas tout à fait une réponse adaptée. Quand un robot fait du
sondage en masse, lui retourner un code d'erreur sauf si ça tappe
juste peut l'aider à trouver.

… et inversement !

Par exemple, renvoyer un 200 uniquement en cas de succès de login est
de nature à faciliter les attaques en force…

Ce n'est pas garanti. J'ai des milliers de requêtes en 403 sur mes pages de login, et cela

ne les dérange pas plus que ça.

Sur le principe, la page c'est "/index.php" ou "/index.php?login=machin&passwd=bidule" ?

Dans le premier cas, le serveur doit renvoyer un code 200 quels que soient les arguments

passés en variable.

Dans le deuxième cas, non et je suis d'accord avec Sylvain. Mais alors… il n'y aurait qu'un

login et un mot de passe ?

Bon, en fait quel que soit le code de réponse renvoyé, et vu que ça n'affecte pas les chieurs,

je crois que c'est un faux problème.

Les seuls qui vaillent la peine que l'on s'attarde de façon pratique, c'est de bien vérifier que

les variables demandées ne s'affichent pas sur la page et de créer un fichier dans Fail2Ban

pour envoyer les demandeurs aux pelotes.

______________
Éric Dégenètais
Henix


http://www.henix.com
http://www.squashtest.org

Le vendredi 9 octobre 2015, 17:02:52 Philippe Gras a écrit :

[… du “bon” code de retour …]
Dans le deuxième cas, non et je suis d'accord avec Sylvain.

Euh, j’ai rien dit là-dessus, moi. J’ai juste do nné deux
exemples de scripts, moisi et moins-moisi, qui renverraient 200
(cas de la question initiale et pour rester simple).

Mais si vous voulez mon avis, il n’y a pas de réponse
générale. Un script qui renvoie une erreur, ça sert. Un script
qui ne renvoie jamais d’erreur, ça sert aussi.

Bon, le mieux, c’est un script qui renvoie un code tiré au
hasard. Un coup ça marche, un coup ça marche pas. À bas REST !

(Eh, c’est vendredi !)
--
Sylvain Sauvage