Protéger formulaires
jemsss
Messages postés
198
Statut
Membre
-
jemsss Messages postés 198 Statut Membre -
jemsss Messages postés 198 Statut Membre -
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
- Protéger un document word - Guide
- Logiciel pour protéger un dossier par mot de passe gratuit - Télécharger - Chiffrement
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.
