Tentatives possible réussies attaque serveur

andre_debian@numericable.fr a écrit :

Bonjour,

Bonjour,

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... ?

André

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

Salut,

andre_debian@numericable.fr a écrit le 02/10/2015 11:10 :

Bonjour,

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... ?

As tu essayé toi même et regardé les réponses http vues par le
navigateur, par exemple avec l'extension httpheader sur firefox?


--
Stéphane

Le 2 oct. 2015 à 12:33, BERTRAND Joël <joel.bertrand@systella.fr> a écrit :

andre_debian@numericable.fr a écrit :

Bonjour,

Bonjour,

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... ?

André

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

J'en ai tous les jours, ce n'est pas grave, en fait.

Pour vous rendre compte de ce que ça donne, vous devriez tester une de ces URL.

Normalement, ce qui passe dans la query string n'est pas pris en compte.

On Friday 02 October 2015 12:34:49 yamo' wrote:

andre_debian@numericable.fr a écrit le 02/10/2015 11:10 :
> 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=../../../../../../../../../../../../../../../../../../et c/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... ?

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"

As tu essayé toi même et regardé les réponses http vues par le
navigateur, par exemple avec l'extension httpheader sur firefox?

Comment fait-on avec " l'extension httpheader" ?

André

andre_debian@numericable.fr a écrit :

On Friday 02 October 2015 12:34:49 yamo' wrote:

andre_debian@numericable.fr a écrit le 02/10/2015 11:10 :

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... ?

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"

J'ai bien compris. 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) ?

Cordialement,

JKB

On Friday 02 October 2015 13:38:21 BERTRAND Joc3abl wrote:

andre_debian@numericable.fr a écrit :
> On Friday 02 October 2015 12:34:49 yamo' wrote:
>> andre_debian@numericable.fr a écrit le 02/10/2015 11:10 :
>>> 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=../../../../../../../../../../../../../../../../../../e tc/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... ?
>
>> 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.

Comment faire autrement ?

André

Le 02/10/2015 13:38, BERTRAND Joël a écrit :

J'ai bien compris. Ce qui m'inquiète, c'est la réponse '200' qui au rait
tendance à indiquer qu'un utilisateur distant peut récupérer le c ontenu
de /etc/passwd.

Non. La réponse 200 indique qu'il y a bien un fichier /index.php et que
celui-ci a répondu sans se planter, c'est tout. Si le fichier index.php
ne s'occupe pas de la "query string", il n'y a absolument pas à s'inqui éter.

--
Bernard.
20 ans d'utilisation de Debian. Comme le temps passe...

Le vendredi 02 octobre 2015 à 12:33, BERTRAND Joël a écrit :

andre_debian@numericable.fr a écrit :
>Y a t-il un danger que les mots de passe soient connus... ?

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

Les mots de passe chiffrés ne sont plus dans le fichier « /etc/passwd » depuis
un petit paquet d'années.

Ce fichier est devenu accessible à tous les utilisateurs car il ne contient plus
grand chose de vraiment sensible. Il peut cependant renseigner sur l'existence
ou non d'un compte utilisateur pour orienter des attaques type force brute, mais
rien de plus.

Sébastien

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

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

On Friday 02 October 2015 13:38:21 BERTRAND Joc3abl wrote:

andre_debian@numericable.fr a écrit :

On Friday 02 October 2015 12:34:49 yamo' wrote:

andre_debian@numericable.fr a écrit le 02/10/2015 11:10 :

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.

André

Bonne chance

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

iQIcBAEBCAAGBQJWFAHwAAoJEBGYNnE0a7qPXqoQAJw6dcA2YDVbQeu1e7aY0et6
hOcycVGobJ7h0Uj8u8/B/j3/TkQbWxMnY6FjCkgbIJrvwlVU381pbWjNI/OCmF8X
DvCqqXViTxvkoPhInV8MWDVR/Q+S7qIKsrY60Gx4kTuEtYjSFBX20RTNlgAWRNZe
D+eEiuN+q+Kbwf3gfNhLB4vuvfrx8z49VCYDbhAqVf0HihK69o98La+QDFeD2iVI
kcE0hxsu7N6IS1SXeWpi0fv91RSZSUM1i4By9wO8O/XVfutKRhKSxNs4RIhSULGJ
VXbW3JGs4MsQic0W3BveGeq5AQ8BBJksQNZ2gAuP/OpjRB43PQKICfKh2LfQZJAv
oyhLVkhf1ANWciznxT5fF22WaQVeFdqyOcr185M+pURWcPKBoWkbFxdCI9xxnP/j
1fXg0wevTeU2oZuzDlBM65dugoWL5PZrp6BYi/70AltbLzvWj2quvMAUyFbCbfmK
LyzEKy/BikV8uj9Qf6x+HVBZQBZ3839OC44Sr6fm5QT6Ve5zYG2w13uKbCkFjPWR
Da5TPYEwceASEJqg76Uf7OS0o8tscH/EK6ihkCE/uyzqvY0vt2Kbhoc5JHtWL1/K
S07omnpJVfpFzm03XbYt0ayD8sdH65P4m1Ov59BB46pQWlV+5s8RIhkY+73jAdMi
iZLT+9rxEH2ZEtlTnUoV
=5oR5
-----END PGP SIGNATURE-----

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".

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 ?

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

André

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 followi ng
>>>>> 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 Inclu sion".
Cette technique permet à un utilisateur mal attentionnée d'inclure da ns
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 sig nifie
pas distinctement la réussite de l'attaque visant à accéder au fich ier
'/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écessair es 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'inclus ion
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 con tenu
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 vot re
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 lo rs
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émentat ion
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 vo tre
infrastructure dépends du fait qu'ils soient filtrés le plus strictem ent
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 autr es,
il faut que tout les tentatives d'inclusions de fichiers soit vers des
fichiers que vous avez expressément vérifié comme étant légitim es.