Protéger formulaires
jemsss
Messages postés
188
Date d'inscription
Statut
Membre
Dernière intervention
-
jemsss Messages postés 188 Date d'inscription Statut Membre Dernière intervention -
jemsss Messages postés 188 Date d'inscription Statut Membre Dernière intervention -
Bonjour,
Je réfléchis à la sécurité des données transmises via un formulaire et envoyées vers la base de donnée SQL. Voici ce que je pensais faire en PHP :
Interdire l'utilisation des 4 caractères suivants : "&<>
Convertir les guillemets simples en apostrophe de type ’
Insérer un antislash juste après le premier caractères des chaines suivantes (majuscules ou minuscules) : ABORT, ALTER, ANALYZE, BEGIN, CHECKPOINT, CLOSE, CLUSTER, COMMENT, COMMIT, COPY, CREATE, DEALLOCATE, DECLARE, DELETE, DISCARD, DROP, END, EXECUTE, EXPLAIN, FETCH, GRANT, INSERT, LISTEN, LOAD, LOCK, MOVE, NOTIFY, PREPARE, REASSIGN, REINDEX, RESET, REVOKE, ROLLBACK, SAVEPOINT, SELECT, SET, SHOW, TRANSACTION, TRUNCATE, UNLISTEN, UPDATE, VACUUM, VALUES
(liste récupérer sur http://docs.postgresqlfr.org/8.1/sql-commands.html)
J'aimerais votre avis. Est-ce suffisant pour être protégé solidement des attaques via mes formulaires ? Je ne suis pas un pro du SQL. Est-ce possible de se limiter juste à quelques mots clés sans lesquels les injections ne sont pas possibles ?
Merci d'avance
Je réfléchis à la sécurité des données transmises via un formulaire et envoyées vers la base de donnée SQL. Voici ce que je pensais faire en PHP :
Interdire l'utilisation des 4 caractères suivants : "&<>
Convertir les guillemets simples en apostrophe de type ’
Insérer un antislash juste après le premier caractères des chaines suivantes (majuscules ou minuscules) : ABORT, ALTER, ANALYZE, BEGIN, CHECKPOINT, CLOSE, CLUSTER, COMMENT, COMMIT, COPY, CREATE, DEALLOCATE, DECLARE, DELETE, DISCARD, DROP, END, EXECUTE, EXPLAIN, FETCH, GRANT, INSERT, LISTEN, LOAD, LOCK, MOVE, NOTIFY, PREPARE, REASSIGN, REINDEX, RESET, REVOKE, ROLLBACK, SAVEPOINT, SELECT, SET, SHOW, TRANSACTION, TRUNCATE, UNLISTEN, UPDATE, VACUUM, VALUES
(liste récupérer sur http://docs.postgresqlfr.org/8.1/sql-commands.html)
J'aimerais votre avis. Est-ce suffisant pour être protégé solidement des attaques via mes formulaires ? Je ne suis pas un pro du SQL. Est-ce possible de se limiter juste à quelques mots clés sans lesquels les injections ne sont pas possibles ?
Merci d'avance
A voir également:
- Protéger formulaires
- Proteger cellule excel - Guide
- Protéger un dossier par mot de passe - Guide
- Protéger un pdf par mot de passe - Guide
- Comment protéger sa photo de profil whatsapp - Guide
- Protéger un document word - Guide
2 réponses
Bonjour
Je suppose d'après le lien que tu mets que tu travailles avec postgre.
Si c'est le cas, et si les données saisies sont bien utilisées comme données, c'est à dire que tu vas les enregistrer et non pas les exécuter comme requêtes, ces précautions sont à la fois insuffisantes et inutilement compliquées.
En PHP, il y a deux fonctions pour protéger les données insérées dans une base postgre : pg_escape_bytea et pg_escape_string. Elles sont faites pour ça, inutile de (mal) les réinventer.
Ceci ne concerne que la base de données. Les 4 caractères spéciaux "&<> posent des problèmes à l'affichage uniquement, il suffit (lors de leur affichage seulement) de les échapper avec htmlspecialchars. On voit très souvent sur ce site des scripts où htmlspecialchars est appliqué avant l'enregistrement des données ; c'est une erreur, cela dénature l'information enregistrée et fausse donc les ORDER BY et autres LIKE du SQL.
Je suppose d'après le lien que tu mets que tu travailles avec postgre.
Si c'est le cas, et si les données saisies sont bien utilisées comme données, c'est à dire que tu vas les enregistrer et non pas les exécuter comme requêtes, ces précautions sont à la fois insuffisantes et inutilement compliquées.
En PHP, il y a deux fonctions pour protéger les données insérées dans une base postgre : pg_escape_bytea et pg_escape_string. Elles sont faites pour ça, inutile de (mal) les réinventer.
Ceci ne concerne que la base de données. Les 4 caractères spéciaux "&<> posent des problèmes à l'affichage uniquement, il suffit (lors de leur affichage seulement) de les échapper avec htmlspecialchars. On voit très souvent sur ce site des scripts où htmlspecialchars est appliqué avant l'enregistrement des données ; c'est une erreur, cela dénature l'information enregistrée et fausse donc les ORDER BY et autres LIKE du SQL.