5
J'ai besoin de vérifier tout mon code ASP pour empêcher l'injection SQL.Une session peut-elle être falsifiée?
Dois-je également vérifier l'objet de session?
Comment une session peut-elle être piratée?
Merci!
A
Répondre
3
La session peut être piratée. Si je me souviens bien, Classic ASP ne prend en charge que l'identificateur de session basé sur les cookies. Si quelqu'un était capable de voler ce cookie (fil-tap) alors ils peuvent gagner la même session en tant qu'utilisateur légitime.
Si vous vérifiez aussi l'objet de session? ça dépend. Si vous pouvez vous assurer que tout l'objet stocké dans les sessions est "sûr" (l'entrée a été nettoyée), vous pouvez ignorer l'objet de session. Si quelque part dans votre application vous obtenez des données provenant d'une source non sûre et les placez dans l'objet Session, vous devez également les vérifier.
3
Pour éviter l'injection SQL, utilisez des requêtes paramétrées au lieu de créer les requêtes SQL en concaténant des chaînes. Le détournement de session est un sujet complètement différent. Cela peut être rendu plus difficile en changeant le cookie de session avec chaque demande, et évité complètement en utilisant HTTPS. Un problème connexe (et plus important) est la falsification de requêtes inter-site (recherchez-le).
1
Eh bien, vous n'avez vraiment besoin de sécuriser les entrées utilisateur. Donc, la question que vous devez vous poser est: "Est-ce que ces données provenaient de l'entrée de l'utilisateur?" Si c'est le cas, vous devez utiliser les paramètres sql. Sur une plus grande échelle, et étant donné que vous disposez de classes individuelles pour exécuter l'accès aux données, vous devez définir des paramètres sql pour chaque paramètre de texte que vous fournissez à votre SQL. Dans ce scénario, les paramètres sql ne sont pas vraiment nécessaires car si vous recevez un nombre comme paramètre de méthode, il n'y a aucun moyen d'avoir une injection sql. Toutefois, en cas de doute, utilisez les paramètres sql.
1
Les variables de session sont stockées en mémoire sur le serveur. Seul un identifiant de cookie est stocké sur le client. Il n'y a pas besoin de s'inquiéter des variables dans la session, à MOINS qu'elles proviennent du client. Plusieurs fois, il peut être plus facile de vérifier toutes les variables passées à la base de données pour l'injection SQL.
Pourquoi cette réponse? À part l'erreur de grammaire, je pense que c'est une question légitime. – Salamander2007
Vous avez probablement été abaissé parce que le texte de la question manque de focus. Le sujet indique que vous voulez parler de piratage, mais le texte commence à parler de l'injection SQL. – AnthonyWJones