[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 :
<pre class="ipsCode prettyprint">
mysql_escape_string();
</pre>
Ce qui donnerais au final (avec la variable et la méthode) :
<pre class="ipsCode prettyprint">
$user = mysql_escape_string($_POST['user']);
</pre>
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:- <a href="http://www.php.net/manual/fr/function.htmlspecialchars.php" rel="external nofollow">htmlspecialchars()</a>: affiche les caractères html en caractères littérale ex: "<" devient "<"- <a href="http://www.php.net/manual/fr/function.strip-tags.php" rel="external nofollow">strip_tags()</a>: supprime les balises présentent dans le codeet pour modifier tout les gets et posts:<pre class="ipsCode prettyprint lang-auto">

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

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

</pre>

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);

Soulalex

Merci pour ces précisions

AlexMog

<blockquote class="ipsQuote" data-cite="sugatasei" data-ipsquote="" data-ipsquote-contentclass="forums_Topic" data-ipsquote-contentcommentid="15952" data-ipsquote-contentid="33" data-ipsquote-contenttype="forums" data-ipsquote-timestamp="1425590154" data-ipsquote-username="sugatasei"><div>
<div>
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);
</div>
</div></blockquote>
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 <strike>passible de peine de mort</strike> 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.

FaKe77

Function obsolete.

NodeBB

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