Stockage de parties de données utilisateur dans des fichiers pour empêcher l'injection SQL

Question

Je suis novice dans le domaine de la programmation Web et j'étudie les problèmes liés à la sécurité Web.

J'ai un formulaire où l'utilisateur peut publier deux types de données - appelons-les "sûrs" et "dangereux" (du point de vue de sql).

La plupart des emplacements recommandent de stocker les deux parties des données dans la base de données après avoir désinfecté la partie "dangereuse" (pour la rendre "sûre"). Je m'interroge sur une approche différente - pour stocker les données «sûres» dans la base de données et les données «non sécurisées» dans les fichiers (en dehors de la base de données). Bien entendu, cette approche crée son propre ensemble de problèmes liés au maintien de l'association entre les fichiers et les entrées de la base de données. Mais y a-t-il d'autres problèmes majeurs avec cette approche, en particulier en ce qui concerne la sécurité?

MISE À JOUR: Merci pour les réponses! Toutes mes excuses pour ne pas être clair sur ce que je suis en train de considérer comme "sûr", donc quelques éclaircissements sont nécessaires. J'utilise Django, et le formulaire données que je considère "sûr" est accessible par le biais du dictionnaire "nettoyé" du formulaire dictionnaire qui fait tout le nécessaire échapper.

Pour les besoins de cette question, considérons une page wiki. Le titre de la page wiki n'a pas besoin d'avoir de style attaché avec. Donc, cela peut être consulté à travers le formulaire "nettoyé_data" dictionnaire qui va convertir l'entrée de l'utilisateur au format "sûr". Mais puisque je souhaite donner aux utilisateurs la possibilité de style arbitrairement leur contenu, je ne peux peut-être pas accéder à la partie de contenu en utilisant le dictionnaire "washed_data". L'approche de fichier résout-elle les aspects de sécurité de ce problème?

Ou y at-il d'autres problèmes de sécurité que je néglige?

Answer 1

Que considérez-vous comme "sûr" et "dangereux"? Considérez-vous que les données avec les barres obliques s'échappent pour être "sûres"? Si oui, s'il vous plaît ne le faites pas.

Utilisez des variables liées avec des espaces réservés SQL. C'est le seul moyen raisonnable de se protéger contre l'injection SQL.

Answer 2

Diviser vos données ne vous protégera pas de l'injection SQL, cela limitera simplement les données qui peuvent y être exposées, mais ce n'est pas le seul risque de l'attaque. Ils peuvent également supprimer des données, ajouter des données bidon et ainsi de suite.

Je ne vois aucune justification à l'utilisation de votre approche, en particulier compte tenu de l'utilisation d'instructions préparées (prises en charge dans de nombreuses plates-formes de développement et bases de données, sinon toutes).

Sans même entrer dans le cauchemar que votre approche finira par être.

À la fin, pourquoi utiliserez-vous une base de données si vous ne lui faites pas confiance? Utilisez simplement des fichiers simples si vous le souhaitez, un mix est un non-non.

Answer 3

L'injection SQL peut cibler toute la base de données non seulement utilisateur, et c'est la question de requête (empoisonnement), donc pour moi le meilleur moyen (sinon le seul) d'éviter l'injection SQL est de contrôler votre requête de possibilité injecté avec des caractères malveillants plutôt que de fractionner le stockage.

Answer 4

Vous connaissez les données "sûres" dont vous parlez? Ce n'est pas.C'est tous dangereux et vous devriez le traiter comme tel. Pas en le stockant dans des fichiers, mais en construisant correctement vos instructions SQL.

Comme d'autres l'ont mentionné, l'utilisation d'instructions préparées, ou d'une bibliothèque qui les simule, est la voie à suivre, par ex.

$db->Execute("insert into foo(x,y,z) values (?,?,?)", array($one, $two, $three));