J'ai une forme avec de nombreux domaines ...Dois-je désinfecter toutes les variables de formulaire transmises?
L'action est réglé sur une page php qui interroge mysql ...
Dois-je désinfectez avec mysql_real_escape_string chaque variable? Ou est-ce que je peux ignorer les drop-lists et radios désinfectantes par exemple?
En plus de mysql_real_escape_string, que dois-je faire d'autre pour empêcher les attaques?
Merci
Vous devez également cocher les cases à cocher et les cases d'option. N'importe qui peut créer son propre formulaire HTML et le poster dans votre script. L'extension Firefox Web Developer Toolbar a même une option pour convertir les sélections en entrées de texte.
Vous pouvez également vérifier que les données publiées ne contiennent que des valeurs correctes. Par exemple, si vous avez un bouton radio, assurez-vous que le formulaire publié contient uniquement l'une des valeurs valides.
Vous ne devriez bien sûr exécuter mysql_real_escape_string que sur les variables que vous allez mettre dans MySQL. Si vous sauvegardez dans un fichier, utilisez la ligne de commande ou autre chose, il y a plus de fonctions et de solutions appropriées.
Vous ne devez utiliser mysql_real_escape_string pour échapper à des chaînes avant de les utiliser dans des instructions SQL, pour prévenir les attaques par injection SQL.
En outre, lorsque vous extrayez des données de votre base de données et que vous les écrivez au format HTML, vous devez envisager d'utiliser htmlspecialchars ou strip_tags pour empêcher les attaques par script intersite.
Mieux vaut utiliser htmlspecialchars() je pense. strip_tags ne fonctionne pas toujours comme prévu. –
ni htmlspecialchars ni mysql_real_escape_string fonctionnent comme une pilule magique dans toutes les conditions, s'il vous plaît voir http://stackoverflow.com/questions/110575/do-htmlspecialchars-and-mysql-real-escape-string-keep-my-php-code- safe-from-injec – Cheekysoft
Toute variable envoyée par le client ne peut pas être considérée comme sûre et valide. Si vous les utilisez dans une requête, vous devez toujours les désinfecter.
qu'en est-il des variables qui n'ont pas été envoyées par le client? –
En général, il est trivial de former une requête POST en dehors du navigateur et de contourner ainsi les restrictions que la liste déroulante (par exemple) peut avoir imposées aux valeurs possibles. Pour cette raison, vous devez toujours traiter les données utilisateur de manière hostile et sujette aux erreurs et mettre autant de validation et de protection côté serveur que possible.
Vous devez seulement nettoyer les champs que vous ne voulez pas qu'un attaquant détourne. Les données peuvent être n'importe quelle source, pas seulement votre page. mysql_real_escape_string est bon pour toute valeur qui sera concaténée dans une requête, mais je "désinfecte" tout. Pour moi, "assainir" signifie plus que manipuler des attaques par injection, il inclut également toute validation de champ (longueur d'insertion, valeur numérique, date valide, vide, etc.).
Encore un tas de réponses ignorantes. Camran, tu l'attires comme un aimant.
Vous devez comprendre que mysql_real_escape_string n'a rien à voir avec des formes et des radios, avec vérification et assainissement.
Et cela n'empêche pas les attaques.
Il s'agit simplement d'une fonction d'échappement de chaîne. Il échappe une donnée qui va être insérée dans la chaîne de requête SQL en tant que donnée de chaîne.
La requête SQL est un petit programme. Avec sa propre syntaxe.Vous devez suivre cette syntaxe, non pas à cause des "attaques" mais à cause de c'est juste une syntaxe. Et, bien sûr, ces règles ne dépendent pas de la source des données! Bouton radio, formulaire html ou navigateur - tout n'est pas grave!
Et cela fonctionne uniquement avec des chaînes. Pas avec des chiffres ni des identifiants.
Voici ma réponse sur la façon de traiter une requête SQL: In PHP when submitting strings to the database should I take care of illegal characters using htmlspecialchars() or use a regular expression?
rappelez-vous que mysql_real_escape_string est seulement sûr à utiliser lorsque la valeur échappée est délimitée par des guillemets simples dans l'instruction sql résultante. Mieux encore: oubliez les chaînes qui s'échappent et utilisez simplement les paramètres sql liés. – Cheekysoft