Interdire le javascript dans les formulaires php ?
11 réponses
Me
'Jour,
Comment interdire Javascritpt dans les formulaires traité par php ?
Histoire qu'un malin ne se serve des formulaires pour mettre des boucles
javascript dans ma bd...(C'est du vécu !)
Pour l'instant je bloque un peu sur tout çà...et vu que je recommence le
php, j'ai trouvé plus simple de demander l'info içi ;-)
Si vous avez une adresse sur la question...ou un conseil...
N.B: J'ai eu un mal de chien à publier mon article sur ce news car refusé
trois fois par un bot apparement...c'est toujours comme çà ?
Je suis évidemment d'accord sur l'usage de htmlspecialchars(), mais absolument pas sur le fait de l'utiliser avant de stocker les données en base de données.
Comme d'habitude, tout dépend du besoin. Si tu as plusieurs canaux de sortie, tu peux aussi le faire en sortie de la base, à chaque fois que tu fais un SELECT, aller nettoyer les caractères potientiellement dangereux.
Perso, **sur des application de type web-app**, où le vecteur principal de présentation reste le navigateur, je préfère le faire *avant* le stockage, quitte à repasser, sur les autres canaux de sortie (style PDF) la transformation inverse.
De la même manière que si tu interdis certains caractères/actions dangereuses et que tu autorises toutes celles qui ne sont pas interdites, tu ne t'apercevras jamais qu'il y a un problème avant l'attaque réussie (et détectée), alors que si tu interdit tout puis tu ouvres les vannes au compte goutte, tu t'aperçois nécessairement de ce que tu as oublié vu que "ça marche pas", je préfère désamorcer le code dangereux de manière systématique et "bourrin", et si je m'aperçois plus tard que ça f... la m... ailleurs, je me pose la question de le gérer plus tard.
Alors que s'il y a un SELECT dans lequel j'ai oublié de faire mon htmlspecialchars/entities, et bien je ne détecterai (peut-être) l'oubli que le jour où la XSS aura déjà eut lieu... En plus, en le faisant *avant* le stockage, on purge tout à UN SEUL endroit dans le code.
Mais sur le fond, qu'on le fasse avant ou après, l'essentiel est de l'intégrer en standard dans les procédures de développement.
a++; JG
Bonjour,
Je suis évidemment d'accord sur l'usage de htmlspecialchars(), mais
absolument pas sur le fait de l'utiliser avant de stocker les données
en base de données.
Comme d'habitude, tout dépend du besoin. Si tu as plusieurs canaux de
sortie, tu peux aussi le faire en sortie de la base, à chaque fois que tu
fais un SELECT, aller nettoyer les caractères potientiellement dangereux.
Perso, **sur des application de type web-app**, où le vecteur principal de
présentation reste le navigateur, je préfère le faire *avant* le stockage,
quitte à repasser, sur les autres canaux de sortie (style PDF) la
transformation inverse.
De la même manière que si tu interdis certains caractères/actions
dangereuses et que tu autorises toutes celles qui ne sont pas interdites,
tu ne t'apercevras jamais qu'il y a un problème avant l'attaque réussie
(et détectée), alors que si tu interdit tout puis tu ouvres les vannes au
compte goutte, tu t'aperçois nécessairement de ce que tu as oublié vu que
"ça marche pas", je préfère désamorcer le code dangereux de manière
systématique et "bourrin", et si je m'aperçois plus tard que ça f... la
m... ailleurs, je me pose la question de le gérer plus tard.
Alors que s'il y a un SELECT dans lequel j'ai oublié de faire mon
htmlspecialchars/entities, et bien je ne détecterai (peut-être) l'oubli
que le jour où la XSS aura déjà eut lieu... En plus, en le faisant
*avant* le stockage, on purge tout à UN SEUL endroit dans le code.
Mais sur le fond, qu'on le fasse avant ou après, l'essentiel est de
l'intégrer en standard dans les procédures de développement.
Je suis évidemment d'accord sur l'usage de htmlspecialchars(), mais absolument pas sur le fait de l'utiliser avant de stocker les données en base de données.
Comme d'habitude, tout dépend du besoin. Si tu as plusieurs canaux de sortie, tu peux aussi le faire en sortie de la base, à chaque fois que tu fais un SELECT, aller nettoyer les caractères potientiellement dangereux.
Perso, **sur des application de type web-app**, où le vecteur principal de présentation reste le navigateur, je préfère le faire *avant* le stockage, quitte à repasser, sur les autres canaux de sortie (style PDF) la transformation inverse.
De la même manière que si tu interdis certains caractères/actions dangereuses et que tu autorises toutes celles qui ne sont pas interdites, tu ne t'apercevras jamais qu'il y a un problème avant l'attaque réussie (et détectée), alors que si tu interdit tout puis tu ouvres les vannes au compte goutte, tu t'aperçois nécessairement de ce que tu as oublié vu que "ça marche pas", je préfère désamorcer le code dangereux de manière systématique et "bourrin", et si je m'aperçois plus tard que ça f... la m... ailleurs, je me pose la question de le gérer plus tard.
Alors que s'il y a un SELECT dans lequel j'ai oublié de faire mon htmlspecialchars/entities, et bien je ne détecterai (peut-être) l'oubli que le jour où la XSS aura déjà eut lieu... En plus, en le faisant *avant* le stockage, on purge tout à UN SEUL endroit dans le code.
Mais sur le fond, qu'on le fasse avant ou après, l'essentiel est de l'intégrer en standard dans les procédures de développement.
