[Sécurité] Sécuriser ses $_POST & $_GET

[Brokeos]

Bonsoir, vous n'êtes pas sans savoir que, les hackeurs utilisent une méthode appelée "l'injection sql", qui comme son nom l'indique, permet d'injecté du code sql dans une fonction POST ou GET d'une page php.

Elle est souvent utilisé pour contourner des connexion (par exemple, 'OR "=").

 

Mais comment se protégé ?

 

Tout simplement, rajoutez dans votre méthode POST ou GET :

mysql_escape_string();

Ce qui donnerais au final (avec la variable et la méthode) :

$user = mysql_escape_string($_POST['user']);

Voila, j'espère que ça vous auras aidé ! ^^

[Crisou]

Merci du partage, mais la PDO ne règle aussi ce problème via les requêtes préparé : P

[Azad]

Les requêtes préparées en PDO sont très pratiques à ce niveau là, c'est une vraiment habitude à prendre directement dés le début pour les jeunes développeurs.

Néanmoins, merci du partage.

+1 Rep

[Soon]

Merci du partage !

[Brokeos]

Au plaisir !

[mars073]

toujours un risque de faille xss

solution pour les failles xss:

- htmlspecialchars(): affiche les caractères html en caractères littérale ex: "<" devient "&lt;"

- strip_tags(): supprime les balises présentent dans le code

et pour modifier tout les gets et posts:

 <?php
	foreach ($_GET as $key => $value) {
		$_GET[$key] = addslashes($value);
	}

	foreach ($_POST as $key => $value) {
		$_POST[$key] = addslashes($value);
	}
	?>

Modifié April 8, 2014 par mars073

[sugatasei]

Chouette, un de mes sujets préféré !!!

 

- Pour les failles d'injection SQL, attention car la librairie mysql est déprécié et sera supprimé très probablement dans la futur version majeur de PHP.

PDO et mysqli pour ceux qui ne souhaitent pas sortir l'artillerie lourde, fournit une meilleure protection grâce aux requêtes préparées.

 

- Pour les failles XSS vous pouvez aussi utiliser la fonction filter_var. Cette fonction possède un tas d'options pour filtrer et vérifier vos données. Pour se protéger des failles xss : filter_var($data, FILTER_SANITIZE_STRING)

 

Remarque : Ne pas inclure ce filtre automatiquement sur tous vos paramètres HTTP. La faille XSS est une faille qui agit en sortie, pas en entrée. Ne filtrer donc que les variables que vous utilisez. Sinon on peut s'amuser à envoyer des requètes HTTP avec de très nombreux paramètres POST pour essouffler votre serveur qui va tout filtrer à chaque page :-) Et si vous vous attendez à un int, bool, float. Un simple cast fera l'affaire !!!

 

- Ensuite il y a les failles CSRF (soumission de formulaire non contrôlé) : Vous pouvez créer un système de clé publique, clé privé (identifiant de la session) avec password_verify et password_hash. Vous collez la clé privée en session et la clé publique dans un input hidden de tous vos formulaires. Lors du traitement du formulaire, vous pourrez alors tester si la cohérence des clés pour vérifier que le formulaire est appelé depuis une page de votre site et non pas d'un bot.

 

- Pour les formulaires d'upload : ne pas faire confiance à l'extension du nom de fichier ou du type contenu dans la superglobale $_FILE. Voir : finfo_open(FILEINFO_MIME_TYPE);

Modifié March 5, 2015 par sugatasei

[Soulalex]

Merci pour ces précisions

[AlexMog]

Chouette, un de mes sujets préféré !!!

 

- Pour les failles d'injection SQL, attention car la librairie mysql est déprécié et sera supprimé très probablement dans la futur version majeur de PHP.

PDO et mysqli pour ceux qui ne souhaitent pas sortir l'artillerie lourde, fournit une meilleure protection grâce aux requêtes préparées.

 

- Pour les failles XSS vous pouvez aussi utiliser la fonction filter_var. Cette fonction possède un tas d'options pour filtrer et vérifier vos données. Pour se protéger des failles xss : filter_var($data, FILTER_SANITIZE_STRING)

 

Remarque : Ne pas inclure ce filtre automatiquement sur tous vos paramètres HTTP. La faille XSS est une faille qui agit en sortie, pas en entrée. Ne filtrer donc que les variables que vous utilisez. Sinon on peut s'amuser à envoyer des requètes HTTP avec de très nombreux paramètres POST pour essouffler votre serveur qui va tout filtrer à chaque page :-) Et si vous vous attendez à un int, bool, float. Un simple cast fera l'affaire !!!

 

- Ensuite il y a les failles CSRF (soumission de formulaire non contrôlé) : Vous pouvez créer un système de clé publique, clé privé (identifiant de la session) avec password_verify et password_hash. Vous collez la clé privée en session et la clé publique dans un input hidden de tous vos formulaires. Lors du traitement du formulaire, vous pourrez alors tester si la cohérence des clés pour vérifier que le formulaire est appelé depuis une page de votre site et non pas d'un bot.

 

- Pour les formulaires d'upload : ne pas faire confiance à l'extension du nom de fichier ou du type contenu dans la superglobale $_FILE. Voir : finfo_open(FILEINFO_MIME_TYPE);

Pour l'upload, il faut faire attention, même finfo_open est traitre . Il faut penser à utiliser des solutions plus poussées.

Par exemple, l'intégration de code php exécutable (ou encore de shellcode) est très simple dans une image (je vous laisse chercher par vous mêmes ).

Le contre, c'est de vérifier, dans le header d'une image par exemple, si elle est corrompue. Beaucoup d'images proposent un hash de leur données dans leur header pour savoir si il y a eu corruption, à vous de vous amuser avec ça .

 

Have fun!

[sugatasei]

Rien n'empêche de mettre à jour le hash de l'image après la corrompre.

Le code PHP contenu dans une image n'est pas interprété si on l'affiche dans un contexte statique. A moins que le serveur soit configuré pour exécuter les images comme du PHP mais dans ce cas autant donner les clés root ce sera plus rapide ^^

Pour exécuter le code contenu dans ton image vérolé, il faut l’exécuter dynamiquement avec un "require/include". Inclure un fichier externe comme ceci est passible de peine de mort est en effet très dangereux car on demande explicitement d’exécuter du code externe ... Il y a des librairies tel que gd ou imagick qui permettent de manipuler les images sans les exécuter. On peut également utiliser readfile pour servir l'image comme une image. Ou si on veut afficher le contenu (pas le lien) directement dans une balise img l'utilisation de base64encode est aussi safe.

 

J'édite pour synthétiser (et corriger mes fautes d'aurttaugraf) :

- finfo_open permettra surtout de vérifier que le type de fichier upload est cohérent avec le type de fichier que vous souhaitez utiliser. (pas de docx renommé en pdf si un pdf est attendu).

- Recueillir des données externe est toujours source de faille de sécurité (même avec un antivirus). Il faut l'accepter et faire avec :-) La sécurité se passe à la sortie : ne pas exécuter / intérepreté un fichier externe dans votre environnement d’exécution (PHP). Desservez vos media dans un contexte statique (url/img.jpg). Dynamiquement, envoyez le contenu au navigateur sans l’interpréter.

Modifié March 10, 2015 par sugatasei

[FaKe77]

Function obsolete.