Protection contre le xss et l'sql injection
Soyez le premier à donner votre avis sur cette source.
Snippet vu 15 674 fois - Téléchargée 20 fois
Contenu du snippet
Voici un petit code sans grande prétention. Il se charge de traiter les données envoyées par formulaire dans les tableaux $_GET et $_POST pour éviter le XSS et l'SQL Injection.
Source / Exemple :
<?php
function secureArray (&$item)
{
if (is_array($item)) array_walk ($item, 'secureArray');
else
{
$item = htmlspecialchars($item);
$item = mysql_real_escape_string($item);
}
}
secureArray($_POST);
secureArray($_GET);
?>
A voir également
- Protection contre le xss et l'sql injection
- Protection contre faille xss - Conseils pratiques - PHP
- Sql injection insert - Conseils pratiques - PHP
- XSS dans requete sql un peu spéciale ✓ - Forum - PHP
- Contrer SQL Injection ✓ - Forum - PHP
- Sql injection c# ✓ - Forum - C# / .NET
Commentaires
Concernant les injections SQL je vous recommande d'utiliser la classe PHP PDO,
qui avec les méthode prépare / bind_param / execute permet de se prémunir contre tous types d'injections SQL.
Bon dev ;)
@ Pulp... le htmlspecialchars(), htmlentities() ou strip_chars() est inutile pour une requête SQL en effet les base de données ne sont pas sensible au html, javascript, php, etc... au final tu ne fais que surcharger ta base de données en caractères supplémentaires... .. .
Concernant l'injection SQL... tout d'abord le but dépend du pirate et donc de ce qu'il veut faire... .. .
Pour ce qui est du traitement des données magic_quotes n'échappe que des caractères généraliste ça n'est ni suffisant ni portable selon la SGDB utilisée ce qui ne fait que donner une illusion de sécurité... c'est d'ailleurs pour ça qu'elle n'existera plus à partir de PhP6... cependant certain caractères non échappés par magic_quotes doivent l'être avec certaines SGDB... il faut donc au préalable virer l'échappement de magic_quotes pour ne pas échapper les caractères d'échappement (lol) ce qui reviendrait à ne rien échapper du tout... d'où le stripslashes()... .. .
Un autre avantage de cette façon de procéder est que mysql_real_escape_string() n'est pas une fonction généraliste comme addslashes() ou magic_quotes... étant spécialisé dans le traitement de données destinées à MySQL si cette dernière évolue tu est sur que tes données seront toujours traitées comme il se doit... .. . ;o)
@ tchaOo°
D'ailleurs mysql_escape_real_string, ça protege de l'injection avec quotes avec des slash, la methode d'injection est la meme que ce soit INSERT ou SELECT ca change rien vu que le but c'est de faire un UNION, non?
autre chose KANKRE je comprend pas trop ton code avec get_magic_quotes_gpc(), tu verifie si il y a des slash, pour les enlever, et finaler les remettres, enfin les remettres uniquement aux char concerner par la fonction mysql_escape_real_string ok, mais ça sert à quoi ? si ya magic quotes tu fais rien tout simplement..
Ou alors c'est que magic quotes a une faille que mysql_escape_real_string n'a pas ?
index.php?>'><ScRiPt%20%0a%0d>alert(1687822802)%3B</ScRiPt>
une soluce je m arrache les cheveux
Vous n'êtes pas encore membre ?
inscrivez-vous, c'est gratuit et ça prend moins d'une minute !
Les membres obtiennent plus de réponses que les utilisateurs anonymes.
Le fait d'être membre vous permet d'avoir un suivi détaillé de vos demandes et codes sources.
Le fait d'être membre vous permet d'avoir des options supplémentaires.