Bonjour
Je suis en plein trouble, donc je viens voir les pros.
J'ai lu pas mal de choses sur la sécurtité et faille mais j'avoue, qu'une
fois sur mon code je ne vois plus rien.
On va rester au plus simple. Oublions pour le moment le code.
J'ai un formulaire en $_post ou l'user doit selectionner dans une liste.
post n'est pas plus sécuritaire que get, ok C juste pour moi plus simple à
traiter
la selection dans la liste n'est pas non plus au top, ok.
Je devrai donc contrôler avant de mettre en base mais controler quoi?
c'est à partir de là que je vois plus.
Vérifier qu'il n'y ai pas de caractères d'attanque style / : < > % & " '
tout passer dans htmlspecialchars() ou strip_tags() ou addslash()?
Sur certains sites on déconseille les expressions régulières, soit disant
que cela tete.
En plus là je suis sur quelque chose de simple, mais j'ai un autre formulare
ou je suis sence stoker une adresse phyique en en seul champ car je ne
connais pas le format de toutes les adresses du monde donc un seul champ.
Comment faire pour le contrôler être sur qu'il soit sûr?
Un peu comme un sujet posté dans un forum......... Comment faire pour être
sur que ce sujet et tout ce qu'il peut contenir peut être sur.
Tout cela parce que je n'ai pas l'esprit d'aller pirater.
Merci pour vos lumières
Si cela peut vous aider c'est fait sous Xoops, Formulaire générés par les
class de Xoops, la seule sécurité est la class sanitizer.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Patrick Mevzek
Je devrai donc contrôler avant de mettre en base mais controler quoi? c'est à partir de là que je vois plus.
Vérifier qu'il n'y ai pas de caractères d'attanque style / : < > % & " ' tout passer dans htmlspecialchars() ou strip_tags() ou addslash()?
Non, rien de tout cela, sauf à vouloir être bourré de failles.
Vérifier que ce que vous obtenez réellement est ce que vous vous attiendez à obtenir. Ainsi, si dans votre liste, les options ont des valeurs 1,2,3,4 ou 5 eh bien vous vérifiez que dans le $_POST qui va bien vous avez 1,2,3,4 ou 5 et sinon vous retournez une erreur à l'utilisateur ou prenez une valeur par défaut saine selon le cas de figure.
Bref, vous vérifiez le *format* de *tout* ce que vous recevez.
La vérification est plus ou moins simple selon ce dont il s'agit, et peut nécessiter les expressions régulières (mais pas dans le cas simpliste que j'ai pris récemment).
Une fois cette vérification faite, vous pouvez envoyer vos données aux SGBDRs, via une bibliothèque suffisamment intelligente pour protéger les caractères qui doivent être protégés, ce qui dépend du SGBDR, et se pose beaucoup moins quand on utilise des «prepared statements».
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
Je devrai donc contrôler avant de mettre en base mais controler quoi?
c'est à partir de là que je vois plus.
Vérifier qu'il n'y ai pas de caractères d'attanque style / : < > % & " '
tout passer dans htmlspecialchars() ou strip_tags() ou addslash()?
Non, rien de tout cela, sauf à vouloir être bourré de failles.
Vérifier que ce que vous obtenez réellement est ce que vous vous
attiendez à obtenir.
Ainsi, si dans votre liste, les options ont des valeurs 1,2,3,4 ou 5 eh
bien vous vérifiez que dans le $_POST qui va bien vous avez 1,2,3,4 ou 5
et sinon vous retournez une erreur à l'utilisateur ou prenez une valeur
par défaut saine selon le cas de figure.
Bref, vous vérifiez le *format* de *tout* ce que vous recevez.
La vérification est plus ou moins simple selon ce dont il s'agit, et peut
nécessiter les expressions régulières (mais pas dans le cas simpliste
que j'ai pris récemment).
Une fois cette vérification faite, vous pouvez envoyer vos données aux
SGBDRs, via une bibliothèque suffisamment intelligente pour protéger les
caractères qui doivent être protégés, ce qui dépend du SGBDR, et se
pose beaucoup moins quand on utilise des «prepared statements».
--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Je devrai donc contrôler avant de mettre en base mais controler quoi? c'est à partir de là que je vois plus.
Vérifier qu'il n'y ai pas de caractères d'attanque style / : < > % & " ' tout passer dans htmlspecialchars() ou strip_tags() ou addslash()?
Non, rien de tout cela, sauf à vouloir être bourré de failles.
Vérifier que ce que vous obtenez réellement est ce que vous vous attiendez à obtenir. Ainsi, si dans votre liste, les options ont des valeurs 1,2,3,4 ou 5 eh bien vous vérifiez que dans le $_POST qui va bien vous avez 1,2,3,4 ou 5 et sinon vous retournez une erreur à l'utilisateur ou prenez une valeur par défaut saine selon le cas de figure.
Bref, vous vérifiez le *format* de *tout* ce que vous recevez.
La vérification est plus ou moins simple selon ce dont il s'agit, et peut nécessiter les expressions régulières (mais pas dans le cas simpliste que j'ai pris récemment).
Une fois cette vérification faite, vous pouvez envoyer vos données aux SGBDRs, via une bibliothèque suffisamment intelligente pour protéger les caractères qui doivent être protégés, ce qui dépend du SGBDR, et se pose beaucoup moins quand on utilise des «prepared statements».
-- Patrick Mevzek . . . . . . Dot and Co (Paris, France) <http://www.dotandco.net/> <http://www.dotandco.com/>
Soon
Je devrai donc contrôler avant de mettre en base mais controler quoi? c'est à partir de là que je vois plus.
Et lä: http://www.saphirtech.com/securite_web_dynamique.pdf (Document de John Gallet) C'est justement ce document qui m'a jeté dans le trouble. la faute n'est pas
au document mais à moi off course
Christophe
William
Bonjour
"Christophe Meresse" <christophe.meresse@gadz.org> a écrit dans le message
de news: 1157716027.654161.61730@d34g2000cwd.googlegroups.com...
Et lä: http://www.saphirtech.com/securite_web_dynamique.pdf (Document
de John Gallet)
C'est justement ce document qui m'a jeté dans le trouble. la faute n'est pas
Et lä: http://www.saphirtech.com/securite_web_dynamique.pdf (Document de John Gallet) C'est justement ce document qui m'a jeté dans le trouble. la faute n'est pas
au document mais à moi off course
Christophe
William
John GALLET
Et lä: http://www.saphirtech.com/securite_web_dynamique.pdf (Document de John Gallet)
C'est justement ce document qui m'a jeté dans le trouble.
:-( C'est pas le but.
la faute n'est pas au document mais à moi off course
Pas nécessairement. Moi je sais où je vais en l'écrivant, mais les lecteurs ne le savent pas nécessairement, eux.
Donc s'il y a des questions, comme indiqué dans ledit document, mon mail (et ce thread) est(sont) ouvert(s).
JG
Et lä: http://www.saphirtech.com/securite_web_dynamique.pdf (Document
de John Gallet)
C'est justement ce document qui m'a jeté dans le trouble.
:-( C'est pas le but.
la faute n'est pas au document mais à moi off course
Pas nécessairement. Moi je sais où je vais en l'écrivant, mais les
lecteurs ne le savent pas nécessairement, eux.
Donc s'il y a des questions, comme indiqué dans ledit document, mon mail
(et ce thread) est(sont) ouvert(s).
Et lä: http://www.saphirtech.com/securite_web_dynamique.pdf (Document de John Gallet)
C'est justement ce document qui m'a jeté dans le trouble.
:-( C'est pas le but.
la faute n'est pas au document mais à moi off course
Pas nécessairement. Moi je sais où je vais en l'écrivant, mais les lecteurs ne le savent pas nécessairement, eux.
Donc s'il y a des questions, comme indiqué dans ledit document, mon mail (et ce thread) est(sont) ouvert(s).
JG
William
Bonjour "John GALLET" a écrit dans le message de news: 45051cb3$0$27559$
Donc s'il y a des questions, comme indiqué dans ledit document, mon mail (et ce thread) est(sont) ouvert(s).
J'accepte la proposition et ici car je trouve que C mieux de partager, la plus part du temps.
à la page 17/26 Titre =>Filtrer, faire le ménage...
on déconseille de jouer avec les regex ou des filtres de remplacement. première question alors oui ou non? d'après Patrick Mevzek cela n'est pas suffisant.
d'après vous, toujours les attaques ont tout un point commun sur qq caractères comme / : < > % & " ' et que nous pouvons arriver à les desarmorcer avec htmlentities et ou htmlspecialchars. Ce qui semble également constesté.
certainement des écoles qui s'affrontent, mais moi je ne suis d'aucun école et je souhaite juste un code pas trop "ouvert".
La plus part du temps je ne fais que form alimenté par des bases de données en post. Il est facile de valider car si c pas en base c qu'on essaye d'injecter.
Par contre pour toutes les autres données comme le choix utilisateur. les dates, proposer un texte, de très court à très long avec des données là je souhaiterais avoir l'espris tranquille.
voilà pour les toutes premières questions. Cdl William
JG
Bonjour
"John GALLET" <john.gallet@wanadoo.fr> a écrit dans le message de news:
45051cb3$0$27559$626a54ce@news.free.fr...
Donc s'il y a des questions, comme indiqué dans ledit document, mon mail
(et ce thread) est(sont) ouvert(s).
J'accepte la proposition et ici car je trouve que C mieux de partager, la
plus part du temps.
à la page 17/26
Titre =>Filtrer, faire le ménage...
on déconseille de jouer avec les regex ou des filtres de remplacement.
première question alors oui ou non? d'après Patrick Mevzek cela n'est
pas suffisant.
d'après vous, toujours les attaques ont tout un point commun sur qq
caractères comme / : < > % & " '
et que nous pouvons arriver à les desarmorcer avec htmlentities et ou
htmlspecialchars. Ce qui semble également constesté.
certainement des écoles qui s'affrontent, mais moi je ne suis d'aucun école
et je souhaite juste un code pas trop "ouvert".
La plus part du temps je ne fais que form alimenté par des bases de données
en post.
Il est facile de valider car si c pas en base c qu'on essaye d'injecter.
Par contre pour toutes les autres données comme le choix utilisateur.
les dates, proposer un texte, de très court à très long avec des données là
je souhaiterais avoir l'espris tranquille.
voilà pour les toutes premières questions.
Cdl
William
Bonjour "John GALLET" a écrit dans le message de news: 45051cb3$0$27559$
Donc s'il y a des questions, comme indiqué dans ledit document, mon mail (et ce thread) est(sont) ouvert(s).
J'accepte la proposition et ici car je trouve que C mieux de partager, la plus part du temps.
à la page 17/26 Titre =>Filtrer, faire le ménage...
on déconseille de jouer avec les regex ou des filtres de remplacement. première question alors oui ou non? d'après Patrick Mevzek cela n'est pas suffisant.
d'après vous, toujours les attaques ont tout un point commun sur qq caractères comme / : < > % & " ' et que nous pouvons arriver à les desarmorcer avec htmlentities et ou htmlspecialchars. Ce qui semble également constesté.
certainement des écoles qui s'affrontent, mais moi je ne suis d'aucun école et je souhaite juste un code pas trop "ouvert".
La plus part du temps je ne fais que form alimenté par des bases de données en post. Il est facile de valider car si c pas en base c qu'on essaye d'injecter.
Par contre pour toutes les autres données comme le choix utilisateur. les dates, proposer un texte, de très court à très long avec des données là je souhaiterais avoir l'espris tranquille.
voilà pour les toutes premières questions. Cdl William
JG
John GALLET
Bonjour,
J'accepte la proposition et ici car je trouve que C mieux de partager, la plus part du temps. Et "C" mieux de causer la France aussi.
à la page 17/26 Titre =>Filtrer, faire le ménage... on déconseille de jouer avec les regex ou des filtres de remplacement. première question alors oui ou non? d'après Patrick Mevzek cela n'est pas suffisant.
Donc nous sommes d'accord. Les regexp ne sont pas suffisantes.
d'après vous, toujours les attaques ont tout un point commun sur qq caractères comme / : < > % & " ' et que nous pouvons arriver à les desarmorcer avec htmlentities et ou htmlspecialchars. Ce qui semble également constesté.
(Je ne suis pas bien réveillé, les caractères : et " je ne vois pas pourquoi, mais il manque . et potentiellement pour de l'upload de fichiers)
Ca dépend des attaques. Je vais avoir du mal à ne pas me répéter par rapport au doc mais pour synthétiser :
1) injections SQL.
1.1) injections sur les strings : seule ' est concernée si on écrit du SQL correct. Donc un échappement des ' est suffisant (par ou par une autre ' selon le SGBDR, ça dépend, on n'échappe pas de la même manière). Si on écrit du SQL n'importe comment et qu'on met des " pour délimiter les strings SQL, ce que malheureusement certains SGBD acceptent, ' et " sont équivalents.
1.2) injection sur les entiers (ou plus généralement les numériques) : le seul moyen de s'en protéger est de s'assurer que ce qu'on espère être un entier en est bien un, ou d'utiliser les prepared statements.
2) XSS : leur principe simplifié est que du code malicieux qui n'est que *stocké* côté serveur (PHP/SGBD) est ensuite (immédiatement après envoi ou des mois plus tard) exécuté côté client (navigateur). Or, en l'état actuel dela science, côté client/navigateur, pour activer du code malicieux, il faut toujours au moins un tag ouvrant < sous cette forme, ou déguisé par l'emploi de son équivalent encodé différement. D'où le "désamorçage" des attaques XSS en traduisant < tout caractère permettant de l'encoder. Même si on fait par exemple un <BODY Onload="code javascript"> qui ne nécessite jamais l'emploi du mot clef SCRIPT (d'où l'inutilité de le filtrer) il faut quand même le < devant BODY.
Il y a d'autres types d'attaques, mais concernant les caractères dangereux, en gros on a tout (modulo les uploads de fichiers).
certainement des écoles qui s'affrontent, mais moi je ne suis d'aucun école et je souhaite juste un code pas trop "ouvert".
Là en l'occurence non, les deux seules écolesauxquelles je pense qui soient présentes dans mon doc (et toutes les solutions sont toujours indiquées) concernent :
1) les prepared-statements sont-ils la meilleure solution ou pas ? L'une de leurs restrictions est qu'il faut parfois dépendre d'une couche non native au SGBDR pour en bénéficier. Et qui dit couche extérieure dit aussi failles de sécurité autres etc. Donc autant avec Oracle on peut sans hésiter conseiller les prepared-statements, on y gagnera même un peu parfois en performances sur des requêtes très fréquentes avec un SGA bien configuré, autant sur un mysql, à mon sens, ça reste à prouver.
2) faut-il désamorcer les XSS stockées avant ou après stockage. Si on fait uniquement un canal de sortie web, on peut le faire avant pour être tranquille, mais ça aura quelques effets de bord potentiels (par exemple sur un ORDER BY). Si on fait plusieurs canaux de sortie (HTML, PDF, etc...) personnellement je préfère désamorcer d'abord pour la sortie HTML, stocker, puis faire l'opération nécessaire pour le canal spécifique, mais c'est très discutable comme approche, on peut parfaitement stocker avec la XSS, puis désamorcer après le SELECT et avant le echo.
Il est facile de valider car si c pas en base c qu'on essaye d'injecter. Oui et non : on a pu injecter en base du code inoffensif pour le serveur
mais qui s'exécutera sur le client, c'est le principe de la XSS stockée. Ton serveur ne risque rien directement, mais le gars qui se prendra la XSS dans la truffe est en danger immédiat, et peut aussi se faire piquer ses identifiants de session donc indirectement mettre en danger les données côté serveur quand l'attaquant usurpera son identité.
En gros tu peux faire confiance à ce qui est dans la base si tu n'en sélectionne que des numériques, mais dès que tu as une seule zone de texte, elle peut être vecteur d'attaque XSS.
Par contre pour toutes les autres données comme le choix utilisateur. les dates, proposer un texte, de très court à très long avec des données là je souhaiterais avoir l'espris tranquille. La seule solution logique consiste à avoir des types fonctionnels. Si tu
t'attends à avoir une valeur composée exclusivement des caractères 0 à 9 et d'une taille maximale de 5 caractères, tu vérifies que c'est le cas, à partir de listes de caractères autorisés (JAMAIS de listes d'interdits quand on peut faire autrement. Parfois on ne peut pas, cf justement les XSS par exemple). Donc une date c'est 3 ENTIERS et qui répond TRUE sur checkdate(). Et à partir du moment où tu veux autoriser la saisie de mise en forme en général ou de HTML en particulier, c'est le bordel.
a++; JG
Bonjour,
J'accepte la proposition et ici car je trouve que C mieux de partager, la
plus part du temps.
Et "C" mieux de causer la France aussi.
à la page 17/26
Titre =>Filtrer, faire le ménage...
on déconseille de jouer avec les regex ou des filtres de remplacement.
première question alors oui ou non? d'après Patrick Mevzek cela n'est
pas suffisant.
Donc nous sommes d'accord. Les regexp ne sont pas suffisantes.
d'après vous, toujours les attaques ont tout un point commun sur qq
caractères comme / : < > % & " '
et que nous pouvons arriver à les desarmorcer avec htmlentities et ou
htmlspecialchars. Ce qui semble également constesté.
(Je ne suis pas bien réveillé, les caractères : et " je ne vois pas
pourquoi, mais il manque . et potentiellement pour de l'upload de
fichiers)
Ca dépend des attaques. Je vais avoir du mal à ne pas me répéter par
rapport au doc mais pour synthétiser :
1) injections SQL.
1.1) injections sur les strings : seule ' est concernée si on écrit du
SQL correct. Donc un échappement des ' est suffisant (par ou par une
autre ' selon le SGBDR, ça dépend, on n'échappe pas de la même manière).
Si on écrit du SQL n'importe comment et qu'on met des " pour délimiter
les strings SQL, ce que malheureusement certains SGBD acceptent, ' et "
sont équivalents.
1.2) injection sur les entiers (ou plus généralement les numériques) :
le seul moyen de s'en protéger est de s'assurer que ce qu'on espère être
un entier en est bien un, ou d'utiliser les prepared statements.
2) XSS : leur principe simplifié est que du code malicieux qui n'est que
*stocké* côté serveur (PHP/SGBD) est ensuite (immédiatement après envoi
ou des mois plus tard) exécuté côté client (navigateur). Or, en l'état
actuel dela science, côté client/navigateur, pour activer du code
malicieux, il faut toujours au moins un tag ouvrant < sous cette forme,
ou déguisé par l'emploi de son équivalent encodé différement. D'où le
"désamorçage" des attaques XSS en traduisant < tout caractère permettant
de l'encoder. Même si on fait par exemple un <BODY Onload="code
javascript"> qui ne nécessite jamais l'emploi du mot clef SCRIPT (d'où
l'inutilité de le filtrer) il faut quand même le < devant BODY.
Il y a d'autres types d'attaques, mais concernant les caractères
dangereux, en gros on a tout (modulo les uploads de fichiers).
certainement des écoles qui s'affrontent, mais moi je ne suis d'aucun école
et je souhaite juste un code pas trop "ouvert".
Là en l'occurence non, les deux seules écolesauxquelles je pense qui
soient présentes dans mon doc (et toutes les solutions sont toujours
indiquées) concernent :
1) les prepared-statements sont-ils la meilleure solution ou pas ? L'une
de leurs restrictions est qu'il faut parfois dépendre d'une couche non
native au SGBDR pour en bénéficier. Et qui dit couche extérieure dit
aussi failles de sécurité autres etc. Donc autant avec Oracle on peut
sans hésiter conseiller les prepared-statements, on y gagnera même un
peu parfois en performances sur des requêtes très fréquentes avec un SGA
bien configuré, autant sur un mysql, à mon sens, ça reste à prouver.
2) faut-il désamorcer les XSS stockées avant ou après stockage. Si on
fait uniquement un canal de sortie web, on peut le faire avant pour être
tranquille, mais ça aura quelques effets de bord potentiels (par exemple
sur un ORDER BY). Si on fait plusieurs canaux de sortie (HTML, PDF,
etc...) personnellement je préfère désamorcer d'abord pour la sortie
HTML, stocker, puis faire l'opération nécessaire pour le canal
spécifique, mais c'est très discutable comme approche, on peut
parfaitement stocker avec la XSS, puis désamorcer après le SELECT et
avant le echo.
Il est facile de valider car si c pas en base c qu'on essaye d'injecter.
Oui et non : on a pu injecter en base du code inoffensif pour le serveur
mais qui s'exécutera sur le client, c'est le principe de la XSS stockée.
Ton serveur ne risque rien directement, mais le gars qui se prendra la
XSS dans la truffe est en danger immédiat, et peut aussi se faire piquer
ses identifiants de session donc indirectement mettre en danger les
données côté serveur quand l'attaquant usurpera son identité.
En gros tu peux faire confiance à ce qui est dans la base si tu n'en
sélectionne que des numériques, mais dès que tu as une seule zone de
texte, elle peut être vecteur d'attaque XSS.
Par contre pour toutes les autres données comme le choix utilisateur.
les dates, proposer un texte, de très court à très long avec des données là
je souhaiterais avoir l'espris tranquille.
La seule solution logique consiste à avoir des types fonctionnels. Si tu
t'attends à avoir une valeur composée exclusivement des caractères 0 à 9
et d'une taille maximale de 5 caractères, tu vérifies que c'est le cas,
à partir de listes de caractères autorisés (JAMAIS de listes d'interdits
quand on peut faire autrement. Parfois on ne peut pas, cf justement les
XSS par exemple). Donc une date c'est 3 ENTIERS et qui répond TRUE sur
checkdate(). Et à partir du moment où tu veux autoriser la saisie de
mise en forme en général ou de HTML en particulier, c'est le bordel.
J'accepte la proposition et ici car je trouve que C mieux de partager, la plus part du temps. Et "C" mieux de causer la France aussi.
à la page 17/26 Titre =>Filtrer, faire le ménage... on déconseille de jouer avec les regex ou des filtres de remplacement. première question alors oui ou non? d'après Patrick Mevzek cela n'est pas suffisant.
Donc nous sommes d'accord. Les regexp ne sont pas suffisantes.
d'après vous, toujours les attaques ont tout un point commun sur qq caractères comme / : < > % & " ' et que nous pouvons arriver à les desarmorcer avec htmlentities et ou htmlspecialchars. Ce qui semble également constesté.
(Je ne suis pas bien réveillé, les caractères : et " je ne vois pas pourquoi, mais il manque . et potentiellement pour de l'upload de fichiers)
Ca dépend des attaques. Je vais avoir du mal à ne pas me répéter par rapport au doc mais pour synthétiser :
1) injections SQL.
1.1) injections sur les strings : seule ' est concernée si on écrit du SQL correct. Donc un échappement des ' est suffisant (par ou par une autre ' selon le SGBDR, ça dépend, on n'échappe pas de la même manière). Si on écrit du SQL n'importe comment et qu'on met des " pour délimiter les strings SQL, ce que malheureusement certains SGBD acceptent, ' et " sont équivalents.
1.2) injection sur les entiers (ou plus généralement les numériques) : le seul moyen de s'en protéger est de s'assurer que ce qu'on espère être un entier en est bien un, ou d'utiliser les prepared statements.
2) XSS : leur principe simplifié est que du code malicieux qui n'est que *stocké* côté serveur (PHP/SGBD) est ensuite (immédiatement après envoi ou des mois plus tard) exécuté côté client (navigateur). Or, en l'état actuel dela science, côté client/navigateur, pour activer du code malicieux, il faut toujours au moins un tag ouvrant < sous cette forme, ou déguisé par l'emploi de son équivalent encodé différement. D'où le "désamorçage" des attaques XSS en traduisant < tout caractère permettant de l'encoder. Même si on fait par exemple un <BODY Onload="code javascript"> qui ne nécessite jamais l'emploi du mot clef SCRIPT (d'où l'inutilité de le filtrer) il faut quand même le < devant BODY.
Il y a d'autres types d'attaques, mais concernant les caractères dangereux, en gros on a tout (modulo les uploads de fichiers).
certainement des écoles qui s'affrontent, mais moi je ne suis d'aucun école et je souhaite juste un code pas trop "ouvert".
Là en l'occurence non, les deux seules écolesauxquelles je pense qui soient présentes dans mon doc (et toutes les solutions sont toujours indiquées) concernent :
1) les prepared-statements sont-ils la meilleure solution ou pas ? L'une de leurs restrictions est qu'il faut parfois dépendre d'une couche non native au SGBDR pour en bénéficier. Et qui dit couche extérieure dit aussi failles de sécurité autres etc. Donc autant avec Oracle on peut sans hésiter conseiller les prepared-statements, on y gagnera même un peu parfois en performances sur des requêtes très fréquentes avec un SGA bien configuré, autant sur un mysql, à mon sens, ça reste à prouver.
2) faut-il désamorcer les XSS stockées avant ou après stockage. Si on fait uniquement un canal de sortie web, on peut le faire avant pour être tranquille, mais ça aura quelques effets de bord potentiels (par exemple sur un ORDER BY). Si on fait plusieurs canaux de sortie (HTML, PDF, etc...) personnellement je préfère désamorcer d'abord pour la sortie HTML, stocker, puis faire l'opération nécessaire pour le canal spécifique, mais c'est très discutable comme approche, on peut parfaitement stocker avec la XSS, puis désamorcer après le SELECT et avant le echo.
Il est facile de valider car si c pas en base c qu'on essaye d'injecter. Oui et non : on a pu injecter en base du code inoffensif pour le serveur
mais qui s'exécutera sur le client, c'est le principe de la XSS stockée. Ton serveur ne risque rien directement, mais le gars qui se prendra la XSS dans la truffe est en danger immédiat, et peut aussi se faire piquer ses identifiants de session donc indirectement mettre en danger les données côté serveur quand l'attaquant usurpera son identité.
En gros tu peux faire confiance à ce qui est dans la base si tu n'en sélectionne que des numériques, mais dès que tu as une seule zone de texte, elle peut être vecteur d'attaque XSS.
Par contre pour toutes les autres données comme le choix utilisateur. les dates, proposer un texte, de très court à très long avec des données là je souhaiterais avoir l'espris tranquille. La seule solution logique consiste à avoir des types fonctionnels. Si tu
t'attends à avoir une valeur composée exclusivement des caractères 0 à 9 et d'une taille maximale de 5 caractères, tu vérifies que c'est le cas, à partir de listes de caractères autorisés (JAMAIS de listes d'interdits quand on peut faire autrement. Parfois on ne peut pas, cf justement les XSS par exemple). Donc une date c'est 3 ENTIERS et qui répond TRUE sur checkdate(). Et à partir du moment où tu veux autoriser la saisie de mise en forme en général ou de HTML en particulier, c'est le bordel.
a++; JG
ftc
[SNIP]
1.1) injections sur les strings : seule ' est concernée si on écrit du SQL correct. Donc un échappement des ' est suffisant (par ou par une autre ' selon le SGBDR, ça dépend, on n'échappe pas de la même manière). Si on écrit du SQL n'importe comment et qu'on met des " pour délimiter les strings SQL, ce que malheureusement certains SGBD acceptent, ' et " sont équivalents.
Le plus simple étant d'utiliser la fonction spécifique du SGBD comme mysql_real_escape_string qui permet en plus de s'affranchir du jeu de caractère utilisé ( dans les dernières versions, mysql va faire une conversion explicite dans le bon jeu de caractère avant d'échapper les caractères potentiellement dangeureux )
[SNIP]
2) XSS : leur principe simplifié est que du code malicieux qui n'est que *stocké* côté serveur (PHP/SGBD) est ensuite (immédiatement après envoi ou des mois plus tard) exécuté côté client (navigateur). Or, en l'état actuel dela science, côté client/navigateur, pour activer du code malicieux, il faut toujours au moins un tag ouvrant < sous cette forme, ou déguisé par l'emploi de son équivalent encodé différement. D'où le "désamorçage" des attaques XSS en traduisant < tout caractère permettant de l'encoder. Même si on fait par exemple un <BODY Onload="code javascript"> qui ne nécessite jamais l'emploi du mot clef SCRIPT (d'où l'inutilité de le filtrer) il faut quand même le < devant BODY.
Afin de tenter de se prémunir des XSS et qu'on ne veut pas quelque chose d'aussi radical que html_special_chars ou strip_tags ( tout est fonction des besoins ), il existe une bibliothèque nommée SafeHTML ( http://pixel-apes.com/safehtml/ ) qui permet de filtrer les parties potentiellement dangeureuses et laisser la liberté à l'utilisateur d'uiliser quand même des tag html dans ses saisies.
[SNIP]
1.1) injections sur les strings : seule ' est concernée si on écrit du
SQL correct. Donc un échappement des ' est suffisant (par ou par une
autre ' selon le SGBDR, ça dépend, on n'échappe pas de la même manière).
Si on écrit du SQL n'importe comment et qu'on met des " pour délimiter
les strings SQL, ce que malheureusement certains SGBD acceptent, ' et "
sont équivalents.
Le plus simple étant d'utiliser la fonction spécifique du SGBD comme
mysql_real_escape_string qui permet en plus de s'affranchir du jeu de
caractère utilisé ( dans les dernières versions, mysql va faire une
conversion explicite dans le bon jeu de caractère avant d'échapper les
caractères potentiellement dangeureux )
[SNIP]
2) XSS : leur principe simplifié est que du code malicieux qui n'est que
*stocké* côté serveur (PHP/SGBD) est ensuite (immédiatement après envoi
ou des mois plus tard) exécuté côté client (navigateur). Or, en l'état
actuel dela science, côté client/navigateur, pour activer du code
malicieux, il faut toujours au moins un tag ouvrant < sous cette forme,
ou déguisé par l'emploi de son équivalent encodé différement. D'où le
"désamorçage" des attaques XSS en traduisant < tout caractère permettant
de l'encoder. Même si on fait par exemple un <BODY Onload="code
javascript"> qui ne nécessite jamais l'emploi du mot clef SCRIPT (d'où
l'inutilité de le filtrer) il faut quand même le < devant BODY.
Afin de tenter de se prémunir des XSS et qu'on ne veut pas quelque chose
d'aussi radical que html_special_chars ou strip_tags ( tout est fonction
des besoins ), il existe une bibliothèque nommée SafeHTML (
http://pixel-apes.com/safehtml/ ) qui permet de filtrer les parties
potentiellement dangeureuses et laisser la liberté à l'utilisateur
d'uiliser quand même des tag html dans ses saisies.
1.1) injections sur les strings : seule ' est concernée si on écrit du SQL correct. Donc un échappement des ' est suffisant (par ou par une autre ' selon le SGBDR, ça dépend, on n'échappe pas de la même manière). Si on écrit du SQL n'importe comment et qu'on met des " pour délimiter les strings SQL, ce que malheureusement certains SGBD acceptent, ' et " sont équivalents.
Le plus simple étant d'utiliser la fonction spécifique du SGBD comme mysql_real_escape_string qui permet en plus de s'affranchir du jeu de caractère utilisé ( dans les dernières versions, mysql va faire une conversion explicite dans le bon jeu de caractère avant d'échapper les caractères potentiellement dangeureux )
[SNIP]
2) XSS : leur principe simplifié est que du code malicieux qui n'est que *stocké* côté serveur (PHP/SGBD) est ensuite (immédiatement après envoi ou des mois plus tard) exécuté côté client (navigateur). Or, en l'état actuel dela science, côté client/navigateur, pour activer du code malicieux, il faut toujours au moins un tag ouvrant < sous cette forme, ou déguisé par l'emploi de son équivalent encodé différement. D'où le "désamorçage" des attaques XSS en traduisant < tout caractère permettant de l'encoder. Même si on fait par exemple un <BODY Onload="code javascript"> qui ne nécessite jamais l'emploi du mot clef SCRIPT (d'où l'inutilité de le filtrer) il faut quand même le < devant BODY.
Afin de tenter de se prémunir des XSS et qu'on ne veut pas quelque chose d'aussi radical que html_special_chars ou strip_tags ( tout est fonction des besoins ), il existe une bibliothèque nommée SafeHTML ( http://pixel-apes.com/safehtml/ ) qui permet de filtrer les parties potentiellement dangeureuses et laisser la liberté à l'utilisateur d'uiliser quand même des tag html dans ses saisies.
William
Bonsoir "John GALLET" a écrit dans le message de news: 45068714$0$29915$
Bonjour,
Je vous remercie pour tout et vous tient au courant de mes efforts sous Php.
Cordialement William
Bonsoir
"John GALLET" <john.gallet@wanadoo.fr> a écrit dans le message de news:
45068714$0$29915$636a55ce@news.free.fr...
Bonjour,
Je vous remercie pour tout et vous tient au courant de mes efforts sous Php.
