[Sécurité] Les failles les plus courantes [Tutoriel]

**vg33** · 21/10/2006, 09h25

Il peut sniffer le numéro de session pour se faire passer pour le membre.
Tu dois prendre des précautions élémentaires : enregistrer l'ip, l'host, le navigateur... bref tout ce qui peut individualiser un accès. Ainsi, tu vérifies à chaque page que non seulement la session est valide, mais aussi que les paramètres de connexion sont identiques, sinon tu vires. Ca ne résoud pas les problèmes sur des réseaux d'entreprises derrière un routeur ou proxi, mais c'est mieux que rien.
Il est aussi fortement conseillé de programmer un time out, dont la durée est fonction de la confidentialité des données que tu veux protéger. Ainsi, un membre qui oublie de se déconnecter et qui ne ferme pas son navigateur sera automatiquement déconnecté rapidement, ce qui enpêche celui qui le suit sur son ordi de profiter de sa session.

**vg33** · 21/10/2006, 09h28

Envoyé par Guardian_7

C'est principalement pour cette raison qu'il est recommandé de se déconnecter dans le site, avant de fermer son navigateur.

Une précision : la fermeture de toutes les fenêtres et onglets du navigateur détruit automatiquement la session, même si le membre ne s'est pas déconnecté.

Invité · 21/10/2006, 09h33

Envoyé par vg33

Une précision : la fermeture de toutes les fenêtres et onglets du navigateur détruit automatiquement la session, même si le membre ne s'est pas déconnecté.

La fermeture du navigateur entraine la suppression du cookie contenant l'identifiant de session (si celui-ci est bien stocké dans un cookie). Rien d'autre...

Le fichier de sesssion existe toujours sur le serveur.

Le serveur ne peut pas déterminer si le client a fermé son navigateur.

D'où le fameux lien "Se déconnecter".

**vg33** · 21/10/2006, 09h38

Envoyé par Guardian_7

La fermeture du navigateur entraine la suppression du cookie contenant l'identifiant de session (si celui-ci est bien stocké dans un cookie). Rien d'autre...

Tu as raison, je me suis mal exprimé.

**AzertyH** · 21/10/2006, 12h13

ok, je vous remercie beaucoup. Bon week-end

**csbilouze** · 24/10/2006, 23h41

bonsoir a tous,

une petite suggestion, serait il utilise de rajouter un chapitre sur le piratage par brute force aussi, je trouve ce point assez important sur la sécurité.

$ip = $_SERVER["REMOTE_ADDR"];

//recupere($temps);

sleep($temps);

$temps = $temps * 2;

//stocke($temps);

Par m@

source developpez.com

++

**Yogui** · 24/10/2006, 23h47

Salut

Ce sera fait, mais avec une méthode bien plus adaptée que celle proposée ici

Pour rappel, l'article sur la sécurité PHP est un très gros morceau. Tout volontaire pour nous aider dans notre tâche est le bienvenu.

**berceker united** · 25/10/2006, 18h40

- Contrôlez les valeurs attendu.
Si vous attendez un int alors c'est un int qui doit être là et pas un mergez frite.
Si vous attendez un plage de valeurs alors contrôlez cette plage.
Si vous attendre x parametres alors il doit pas y en avoir en moin ni en plus mais attention car certain hebergeur ajoute des parametres automatiquement. Je sais pas pourquoi mais je l'ai déjà vu.

- Dissimulez les informations.
Ne placez pas le nom des champs pour gérer les order by lorsqu'il y a une liste. Utilisez une tableau de correspondance avec des nom non explicite et comme pour le premier cas contrôlez l'existance. Evitez de placer ceci ?admin=false
Utilisez la fiabilité et la justesse de vos information interne pour faire passer le moin possible de parametre en get ou en post.
Contrôlé les risques d'incohérence entre les valeurs de parametre. Exemple ?admin=true&connect=true que ce passe t'il si je passe admin=false&connect=true. Essayez toute les combinaisons.
ne mettez pas des informations sensible des champs caché, au pire utilisez les sessions.
- Contrôlez les formulaires coté serveur plutôt que javascript.
- Ne laissez pas la base de données gérer les erreurs mais intercepté le avant. Je veux dire par là, un exemple. Une requête attend une valeur numéric et qu'un utilisateur envoy un chaine. Selon les db elle lui retourne une erreur disant que c'est pas une valeur attendu c'est pas bon. Ce qui arrive a la base de données doit être le plus propre possible.

**berceker united** · 26/10/2006, 10h09

Je suis fort étonné que personne me soit tombé dessus avec mes suggestion.

- Je reviens sur un point. Je viens de lire une actu sur developpez.com concernant le référencement que je vous invite à lire. Lorsque je disais qu'il fallait que les paramètres ne soit pas trop explicite et bien finalement cela peut poser problèmzeme de référencement. En effet, le faite de rendre non explicite un parametre le sera aussi pour un moteur de recherche est c'est donc un point en moin. Néanmoins, si l'attribut "title" est renseigné cela pourra éventuellement compensé.
C'est un choix.

Soyez plus réactif!.... J'en suis sur que si je raconte une connerie vous allez me tomber dessus

**Yogui** · 26/10/2006, 13h32

Tu peux être explicite sans pour autant donner les noms de tables. Cela dit, je ne vois pas trop le souci à les donner : si le pirate a accès à la BDD, alors tu es mort dans tous les cas (qu'il ait ces noms ou pas)...

**berceker united** · 26/10/2006, 14h10

Envoyé par Yogui

Tu peux être explicite sans pour autant donner les noms de tables. Cela dit, je ne vois pas trop le souci à les donner : si le pirate a accès à la BDD, alors tu es mort dans tous les cas (qu'il ait ces noms ou pas)...

Le but parfois c'est de destabiliser la base de données même s'il y accede pas directement en jouant dans les paramètres. exemple il y a comme parametre iduser=xxx bien souvent nous pouvons penser que c'est le nom du champs "iduser" de la table "users".

Autre chose. Actuellement, j'ai réussi a 'vendre' un truc qui parait farfelut mais ils savère que ça marche assez bien. Les tentatives d'attaques pour acceder au zone admin. Le but c'est de laisser rentrer un pirate dans la zone admin en faite c'est une fausse zone admin qui est complétement isolé. Le but c'est que le temps qu'il va passer fait que ça laisse le temps à l'admin d'être prévenu et d'intervenir. En temps reelle, nous voyons ce qu'il tente de faire afin pouvoir combler le trou de sécurité en temps réelle. C'est ainsi que nous avons eux plusieurs personne pris dans le filet. Il est arrivé un jour que la boite en question (une grosse) a pu porter plainte à une université et l'enquete a fait qu'ils ont pu trouver l'étudiant en le piegant qui faisait une attaque. Un enqueteur était dans la même piece que lui. Les logs du serveur etait consulté en temps réelle et en même temps ils ont vu qu'il était rentré.

Bon j'avous que c'est pas forcément utile.

**kankrelune** · 26/10/2006, 16h48

Ce tuto est récurant sur le net... c'est au moins la 4 ou 5eme fois que je le vois (quasiment à chaque fois avec des auteurs différent

)

Cependant il a le mérite de détailler certain exploit assez fréquent chez les débutant et les moins débutant... cependant comme le dit Guardian_7 il me semble il serait plus interessant de détailler les bonnes pratique pour éviter ce genre de failles que les failles elle même... .. .

Envoyé par AzertyH

Pareil pour moi, je ne comprend pas la faille 7 avec require_once. Si on interdit l’ouverture de fichiers distants avec la variable alloow_url_fopen=off dans php.ini , est-ce-que la configuration de cette option règle le problème (ou je n'ai pas compris cette faille) ?

Merci pour votre aide

Oui et non... ce que tu dis est effectivement valable pour des inclusions distantes mais si le script à été uploadé sur le serveur ou que le pirate veux visualiser un fichier de configuration via une attaque par directory transversal (monfichier.php?mavar=../../config.ext) allow_url_fopen ne sert plus à rien dans ce cas... quand un pirate s'attaque à un site il ne fait pas qu'une attaque, ce dernier teste les différentes attaques possible et c'est généralement la combinaison de plusieurs attaques qui font qu'il arrive au résultat voulu... .. .

En fait l'attaque 7 n'est pas expliquée comme il faut car elle ne concerne pas que require... il sagit d'attaque dit null byte qui consiste comme son nom l'indique à inserer un byte null dans la requete ce qui aura des concéquences désatreuse sur toute fonction, principalement celle non protégées des données binaire, utilisant la donnée corrompue... cette attaque est généralement très efficate sur des require mais encore plus sur les upload...

Le byte null passé dans une chaine sera interprété comme la fin de cette dernière... donc si je réussis à uploader un fichier test.php en envoyant dans la requete http test.php\0.gif ou \0 correspond au byte null... en récupérant l'extension vous obtiendrez gif et vous vous direz ok alors que le fichier est un fichier php... autre exemple si vous avez dans votre code...

require($mapage.'.html');

si lors de ma requete http $mapage devient file.php\0 cela reviendra à faire...

require('file.php');

le .html sera shunté... .. .

Voila en gros... .. .

Il serait bien de parler de failles à l'upload et notament du fait que toutes les infos contenues dans $_FILES['monFichier'] sont très facilement falsifiable vu qu'elles proviennent du navigateur de l'internaute... voici une requete http vérolée comme on peut trouver dans des attaques à l'upload...

POST /vuln/upload.php HTTP/1.1
Host: 127.0.0.1
Content-Length: 314[1]
Content-Type: multipart/form-data; boundary=----------hS7LOLpAKgp2vmwz0gmmrP

------------hS7LOLpAKgp2vmwz0gmmrP
Content-Disposition: form-data; name="fichier"; filename="test.php\0.gif[2]"
Content-Type: image/gif[3]

GIF89a<?php system($_GET['cmd']); ?>[4]

------------hS7LOLpAKgp2vmwz0gmmrP
Content-Disposition: form-data; name="upload"

Uploader
------------hS7LOLpAKgp2vmwz0gmmrP--

[1] facilement falsifiable pour uploader un fichier plus gros que la limite autorisée
[2] pareil on met le nom que l'on veut... c'est de là que proviendra l'attaque null byte
[3] mime-type...
[4] le contenu du fichier

dans cet exemple le fichier uploadé sera soit test.php et à ce moment là le (site du) webmaster passera un très mauvais quart d'heure... au pire si l'attaque null byte échoue mais que l'upload réussis le pirate aura un fichier test.php.gif... GIF89a (ou GIF87a) étant l'entete des fichier gif ce qui fera échouer une vérification via getimagesize()... le pirate n'aura donc plus qu'a trouver une faille include pour pouvoir éxécuter son fichier... .. .

@ tchaOo°

Invité · 26/10/2006, 20h48

Envoyé par kankrelune

Il serait bien de parler de failles à l'upload et notament du fait que toutes les infos contenues dans $_FILES['monFichier'] sont très facilement falsifiable vu qu'elles proviennent du navigateur de l'internaute... voici une requete http vérolée comme on peut trouver dans des attaques à l'upload...

[1] facilement falsifiable pour uploader un fichier plus gros que la limite autorisée
[2] pareil on met le nom que l'on veut... c'est de là que proviendra l'attaque null byte
[3] mime-type...
[4] le contenu du fichier

dans cet exemple le fichier uploadé sera soit test.php et à ce moment là le (site du) webmaster passera un très mauvais quart d'heure... au pire si l'attaque null byte échoue mais que l'upload réussis le pirate aura un fichier test.php.gif... GIF89a (ou GIF87a) étant l'entete des fichier gif ce qui fera échouer une vérification via getimagesize()... le pirate n'aura donc plus qu'a trouver une faille include pour pouvoir éxécuter son fichier... .. .

@ tchaOo°

Qu'on puisse contourner la limite de MAX_FILE_SIZE du formulaire c'est concevable, parcontre la directive PHP upload_max_filesize , j'en doute.

D'une autre manière, les fichiers uploadés sont d'abord symbolisés par un nom temporaire sur le serveur (via $_FILES['tmp_name']), donc si les tests interviennent sur ce fichier tmp, le nom de fichier ne peut pas être contourné.

Enfin, c'est ce que je pense...

**Yogui** · 26/10/2006, 20h59

Guardian_7 : La directive du php.ini n'est là qu'à titre indicatif. J'entends par là que le développeur peut tout à fait opter pour passer outre les informations données par PHP et faire comme si la taille n'était pas dépassée. PHP ne l'en empêchera pas.

**kankrelune** · 27/10/2006, 14h40

Envoyé par Guardian_7

Qu'on puisse contourner la limite de MAX_FILE_SIZE du formulaire c'est concevable, parcontre la directive PHP upload_max_filesize , j'en doute.

Je ne parle pas de MAX_FILE_SIZE (qui est quasiment inutile) ni de upload_max_filesize mais des vérifications faitent par le script... bien souvent la limitation à l'upload n'a rien à voir avec upload_max_filesize... exemple... l'upload d'avatar sur developpez... dans ce cas la limitation est facilement contournable... .. .

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
$limit = 1024;
if($_FILES['mon_fichier']['size'] > $limit)
{
   // le fichier est trop gros... .. .
}

Envoyé par Guardian_7

D'une autre manière, les fichiers uploadés sont d'abord symbolisés par un nom temporaire sur le serveur (via $_FILES['tmp_name']), donc si les tests interviennent sur ce fichier tmp, le nom de fichier ne peut pas être contourné.

En effet cependant beaucoups de developpeurs débutant ne se soucient pas de temp_name et font leurs tests le nom original du fichier

@ tchaOo°

ps : j'allais oublier... il n'y a pas que require qui est sensible aux attaques null byte... c'est valable aussi pour require_once et include(_once)... le seul moyen de s'en prémunir est de tester la présence de byte null dans la chaine avant l'inclusion... .. .

**vg33** · 27/10/2006, 15h17

Envoyé par kankrelune

ps : j'allais oublier... il n'y a pas que require qui est sensible aux attaques null byte... c'est valable aussi pour require_once et include(_once)... le seul moyen de s'en prémunir est de tester la présence de byte null dans la chaine avant l'inclusion... .. .

Ou, quand c'est possible, d'utiliser une liste blanche, ce qui supprime la quasi totalité des problèmes.

**berceker united** · 27/10/2006, 15h30

Envoyé par vg33

Ou, quand c'est possible, d'utiliser une liste blanche, ce qui supprime la quasi totalité des problèmes.

Qu'appelles-tu liste blanche?
ce problème concerne l'utilisation d'inclusion dynamique ?

**vg33** · 27/10/2006, 15h41

Envoyé par berceker united

Qu'appelles-tu liste blanche?
ce problème concerne l'utilisation d'inclusion dynamique ?

Une liste blanche, c'est une liste finie de valeurs admises. Ainsi, on peut faire une liste blanche des inclusions admises. Toute autre tentative d'inclusion sera rejetée. Typiquement, on utilise un switch en cas de liste un peu longue ou un in_array().
Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
$listeBlanche=array('index', 'test', 'admin');
 
if (in_array($_REQUEST['include'], $listeBlanche)) {
    include ($_REQUEST['include'].'php');
}
else {
    exit();
}

**berceker united** · 27/10/2006, 15h58

Envoyé par vg33

Une liste blanche, c'est une liste finie de valeurs admises. Ainsi, on peut faire une liste blanche des inclusions admises. Toute autre tentative d'inclusion sera rejetée. Typiquement, on utilise un switch en cas de liste un peu longue ou un in_array().
Exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
$listeBlanche=array('index', 'test', 'admin');
 
if (in_array($_REQUEST['include'], $listeBlanche)) {
    include ($_REQUEST['include'].'php');
}
else {
    exit();
}

oui c'est ce qu'il y a de plus sur. En faite, revient un peut a ce que je disait qui est de contrôler ce qui arrive et surtout si c'est élément sont cencé exister déjà.

**kankrelune** · 27/10/2006, 16h14

Les liste blanche sont bien entendu ce qu'il y a de plus sûr mais ce n'est pas possible/ou difficile à mettre place dans certains cas... .. .

@ tchaOo°

[Sécurité] Les failles les plus courantes [Tutoriel]

Contribuez / Téléchargez Sources et Outils PHP

Discussions similaires

Partager

Partager