parce que je ne suis pas persuadé que cela serve à grand chose
ah... alors un conseil... change de métier... En tout cas, ne postule pas, ça servira à rien :-)
- tu as un addslashes (ou un magic_quotes_runtime = on dans php.ini) ou un (php_flag magic_quotes_runtime 1 dans le virtualhost apache.)
Sauf que les magic_quotes, c'est le mal absolu.
1) C'est déjà vraiment emmerdant si les données que tu reçoit sont déstinées à autre chose que d'être incluse en base de donnée. Faut que tu "désescape". Super les perfs ! (et dieu sait si sur les applis du site en question, les perfs sont indispensables).
2) Si tu as le malheur de migrer ton appli sur un autre serveur qui n'a pas les magic_quotes, pouf, ton appli n'est plus sécure.
3) Si tu utilises d'autres bases, l'échappement n'est pas forcément le même.
4) Bien évidement, une appli bien foutue, professionnelle est découpée en couche. en particulier, ton code métier est dans des fonctions ou classes metiers, qui devraient ignorer la provenance des données et donc les données que tu leur passes ne doivent pas être déjà échappées. (les données peuvent venir des requêtes http, mais pourrait venir d'un script d'import, d'un service web etc...). Donc du coup, les magic_quotes ne permettent pas de faire un code propre.
tu encadres tes variables par des ' dans ton sql par ex ' .......AND mavar=\''.$mavariable.'\'.................');
Euh, tu es sûr de savoir ce que c'est que le sql injection ?
Bref, pour une appli pro un minimum robuste :
1) on désactive les magic-quotes, ou au pire, on test si les magic_quotes sont activées et dans de cas on réalise l'opération inverse.
2) dans les classes métiers (qui sont censées récupérer des données non échappées), on utilise la fonction d'échappement dédiée à la base utilisée. (ce sera pg_escape_string pour postgresql par exemple, ou mysql_escape_string pour mysql etc..)
[^] # Re: Curiosité...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Offre d'emploi Développeur Web (Paris). Évalué à 5.
ah... alors un conseil... change de métier... En tout cas, ne postule pas, ça servira à rien :-)
Sauf que les magic_quotes, c'est le mal absolu.
1) C'est déjà vraiment emmerdant si les données que tu reçoit sont déstinées à autre chose que d'être incluse en base de donnée. Faut que tu "désescape". Super les perfs ! (et dieu sait si sur les applis du site en question, les perfs sont indispensables).
2) Si tu as le malheur de migrer ton appli sur un autre serveur qui n'a pas les magic_quotes, pouf, ton appli n'est plus sécure.
3) Si tu utilises d'autres bases, l'échappement n'est pas forcément le même.
4) Bien évidement, une appli bien foutue, professionnelle est découpée en couche. en particulier, ton code métier est dans des fonctions ou classes metiers, qui devraient ignorer la provenance des données et donc les données que tu leur passes ne doivent pas être déjà échappées. (les données peuvent venir des requêtes http, mais pourrait venir d'un script d'import, d'un service web etc...). Donc du coup, les magic_quotes ne permettent pas de faire un code propre.
Euh, tu es sûr de savoir ce que c'est que le sql injection ?
Bref, pour une appli pro un minimum robuste :
1) on désactive les magic-quotes, ou au pire, on test si les magic_quotes sont activées et dans de cas on réalise l'opération inverse.
2) dans les classes métiers (qui sont censées récupérer des données non échappées), on utilise la fonction d'échappement dédiée à la base utilisée. (ce sera pg_escape_string pour postgresql par exemple, ou mysql_escape_string pour mysql etc..)