- Cela suffit-il à empêcher les utilisateurs d'entrer des scripts vérolés
(je cite l'aide : « htmlspecialchars() est pratique pour éviter que des
données fournies par les utilisateurs contiennent des balises HTML, comme
pour un forum ou un chat. ») ? [...]
- De manière tout à fait logique, une fois entré dans la table SQL
correspondante, le contenu du champ « C'est mon très "gros" chien » devient
« C'est mon très "gros" chien » : le problème, c'est que si
mon champ fait 30 caractères, « C'est mon très "gros" chien » passe, mais
la version htmlisée, non.
Toute vérification de la taille des champs côté client est vouée à
'échec de toutes façons. Mettre un SIZE="10" détermine seulement la
taille par défaut du nombre de caractères affichés après
interprétation. Ca n'empêche pas l'utilisateur de saisir
l'Encyclopédia Britannica s'il a du temps à perdre. Enfin on va dire
au moins le premier volume. Ou la lettre A du Petit Larousse Illustré
édition 1929 : les options ne manquent pas.
Oui, mais bon, avec un maxlength="10" l'utilisateur ne peut normalement pas
saisir plus de 10 caractères. Si ?
- Cela suffit-il à empêcher les utilisateurs d'entrer des scripts vérolés
(je cite l'aide : « htmlspecialchars() est pratique pour éviter que des
données fournies par les utilisateurs contiennent des balises HTML, comme
pour un forum ou un chat. ») ? [...]
- De manière tout à fait logique, une fois entré dans la table SQL
correspondante, le contenu du champ « C'est mon très "gros" chien » devient
« C'est mon très "gros" chien » : le problème, c'est que si
mon champ fait 30 caractères, « C'est mon très "gros" chien » passe, mais
la version htmlisée, non.
Toute vérification de la taille des champs côté client est vouée à
'échec de toutes façons. Mettre un SIZE="10" détermine seulement la
taille par défaut du nombre de caractères affichés après
interprétation. Ca n'empêche pas l'utilisateur de saisir
l'Encyclopédia Britannica s'il a du temps à perdre. Enfin on va dire
au moins le premier volume. Ou la lettre A du Petit Larousse Illustré
édition 1929 : les options ne manquent pas.
Oui, mais bon, avec un maxlength="10" l'utilisateur ne peut normalement pas
saisir plus de 10 caractères. Si ?
- Cela suffit-il à empêcher les utilisateurs d'entrer des scripts vérolés
(je cite l'aide : « htmlspecialchars() est pratique pour éviter que des
données fournies par les utilisateurs contiennent des balises HTML, comme
pour un forum ou un chat. ») ? [...]
- De manière tout à fait logique, une fois entré dans la table SQL
correspondante, le contenu du champ « C'est mon très "gros" chien » devient
« C'est mon très "gros" chien » : le problème, c'est que si
mon champ fait 30 caractères, « C'est mon très "gros" chien » passe, mais
la version htmlisée, non.
Toute vérification de la taille des champs côté client est vouée à
'échec de toutes façons. Mettre un SIZE="10" détermine seulement la
taille par défaut du nombre de caractères affichés après
interprétation. Ca n'empêche pas l'utilisateur de saisir
l'Encyclopédia Britannica s'il a du temps à perdre. Enfin on va dire
au moins le premier volume. Ou la lettre A du Petit Larousse Illustré
édition 1929 : les options ne manquent pas.
Oui, mais bon, avec un maxlength="10" l'utilisateur ne peut normalement pas
saisir plus de 10 caractères. Si ?
- Cela suffit-il à empêcher les utilisateurs d'entrer des scripts vérolés
(je cite l'aide : « htmlspecialchars() est pratique pour éviter que des
données fournies par les utilisateurs contiennent des balises HTML, comme
pour un forum ou un chat. ») ? [...]
En fait, dans une valeur d'attribut, les balises HTML on s'en tape un
peu. Les caractères dangereux ne sont pas les mêmes à l'intérieur d'une
balise qu'à l'extérieur.
- De manière tout à fait logique, une fois entré dans la table SQL
correspondante, le contenu du champ « C'est mon très "gros" chien » devient
« C'est mon très "gros" chien » : le problème, c'est que si
mon champ fait 30 caractères, « C'est mon très "gros" chien » passe, mais
la version htmlisée, non.
Tu vas t'en vouloir de ne pas y avoir pensé toi-même, j'en suis sûr :
contrôler la longueur *avant* de transformer les caractères en entités !
- Cela suffit-il à empêcher les utilisateurs d'entrer des scripts vérolés
(je cite l'aide : « htmlspecialchars() est pratique pour éviter que des
données fournies par les utilisateurs contiennent des balises HTML, comme
pour un forum ou un chat. ») ? [...]
En fait, dans une valeur d'attribut, les balises HTML on s'en tape un
peu. Les caractères dangereux ne sont pas les mêmes à l'intérieur d'une
balise qu'à l'extérieur.
- De manière tout à fait logique, une fois entré dans la table SQL
correspondante, le contenu du champ « C'est mon très "gros" chien » devient
« C'est mon très "gros" chien » : le problème, c'est que si
mon champ fait 30 caractères, « C'est mon très "gros" chien » passe, mais
la version htmlisée, non.
Tu vas t'en vouloir de ne pas y avoir pensé toi-même, j'en suis sûr :
contrôler la longueur *avant* de transformer les caractères en entités !
- Cela suffit-il à empêcher les utilisateurs d'entrer des scripts vérolés
(je cite l'aide : « htmlspecialchars() est pratique pour éviter que des
données fournies par les utilisateurs contiennent des balises HTML, comme
pour un forum ou un chat. ») ? [...]
En fait, dans une valeur d'attribut, les balises HTML on s'en tape un
peu. Les caractères dangereux ne sont pas les mêmes à l'intérieur d'une
balise qu'à l'extérieur.
- De manière tout à fait logique, une fois entré dans la table SQL
correspondante, le contenu du champ « C'est mon très "gros" chien » devient
« C'est mon très "gros" chien » : le problème, c'est que si
mon champ fait 30 caractères, « C'est mon très "gros" chien » passe, mais
la version htmlisée, non.
Tu vas t'en vouloir de ne pas y avoir pensé toi-même, j'en suis sûr :
contrôler la longueur *avant* de transformer les caractères en entités !
Le problème est surtout d'estimer à l'avance quelle taille on veut en
sgbd.
Mettons qu'on estime que le luser ne rentrera pas plus de 50
chars. Oui, mais 50 chars passés à htmlentities, ça fait combien ? 100
? 200 ? On se retrouve vite à mettre des BLOB à la place d'un char(20)
:-)
Le problème est surtout d'estimer à l'avance quelle taille on veut en
sgbd.
Mettons qu'on estime que le luser ne rentrera pas plus de 50
chars. Oui, mais 50 chars passés à htmlentities, ça fait combien ? 100
? 200 ? On se retrouve vite à mettre des BLOB à la place d'un char(20)
:-)
Le problème est surtout d'estimer à l'avance quelle taille on veut en
sgbd.
Mettons qu'on estime que le luser ne rentrera pas plus de 50
chars. Oui, mais 50 chars passés à htmlentities, ça fait combien ? 100
? 200 ? On se retrouve vite à mettre des BLOB à la place d'un char(20)
:-)
Ca dépend où on l'appelle et ça dépend de quel type d'attaque. Petite
galerie des horreurs possibles et quelques remèdes sur
http://www.saphirtech.com/securite.html
En effet, si on fait la modification avant le stockage, comme je
l'indiquais déjà dans ce thread, il faut prévoir des tailles
supérieures. Cela a aussi d'aures effets de bord, en particulier sur
le ORDER BY.
problème, mais j'en connais qui risquent quand même de couiner parce
que le
Rôôh, meuuuh non, les utilisateurs ? Couiner pour ça ? Pourquoi
*seulement* pour ça ?
Oui, mais bon, avec un maxlength="10" l'utilisateur ne peut
normalement pas saisir plus de 10 caractères. Si ?
Tout dépend de ce qu'il utilise comme clickodrome. Je t'assure que mon
lynx s'en foutra éperdument, et quand à wget ou curl, je te dis même
pas. Donc il faut voir à quoi/qui sert cette restriction si elle est
faite côté cient. Si c'est pour lui indiquer visuellement qu'au delà
de telle taille il risque de se faire zapper, c'est suffisant.
Bon, reprenons la logique et les contraintes.
On veut saisir un texte dans un clickodrome, le stocker en sgbdr, et
le restituer. Ca devrait pas être si difficile que ça sur le papier.
En pratique, pour pas se faire tarter au passage, c'est moins facile.
Concernant le filtrage des données en entrée, depuis des années,
c'était demerden zie sich elein. Depuis peu, l'extension filter est
disponible : http://fr2.php.net/manual/en/ref.filter.php
A éplucher pour voir si le comportement te convient.
Ensuite, faut-il désamorcer en entrée ou en sortie ? Perso je
désamorce en entrée, quitte à refaire l'opération inverse en sortie si
finalement mon canal n'est pas du html. D'aucuns font l'inverse.
Faut-il désamorcer les xss en convertissant les < et les > ou en
utilisant strip_tags ? Bonne question. La seconde bouffe tout ce qui
se trouve entre < et > sans autre forme de procès, même si ce n'est
pas du html : a<b et b>c => ac
Ca m'empêche pas de l'utiliser, tout dépend du besoin potentiel des
utilisateurs d'entrer ce genre de choses. Dans une application de
commerce électronique, le besoin est totalement nul, pas plus en
frontal qu'en backoffice.
Et enfin les problèmes d'affichage, comme les " perdues dans des
attributs. La seule solution est de les transformer au moment où on
les renvoie vers le navigateur, ou de les avoir transformées avant
stockage dans le sgbd.
Ca dépend où on l'appelle et ça dépend de quel type d'attaque. Petite
galerie des horreurs possibles et quelques remèdes sur
http://www.saphirtech.com/securite.html
En effet, si on fait la modification avant le stockage, comme je
l'indiquais déjà dans ce thread, il faut prévoir des tailles
supérieures. Cela a aussi d'aures effets de bord, en particulier sur
le ORDER BY.
problème, mais j'en connais qui risquent quand même de couiner parce
que le
Rôôh, meuuuh non, les utilisateurs ? Couiner pour ça ? Pourquoi
*seulement* pour ça ?
Oui, mais bon, avec un maxlength="10" l'utilisateur ne peut
normalement pas saisir plus de 10 caractères. Si ?
Tout dépend de ce qu'il utilise comme clickodrome. Je t'assure que mon
lynx s'en foutra éperdument, et quand à wget ou curl, je te dis même
pas. Donc il faut voir à quoi/qui sert cette restriction si elle est
faite côté cient. Si c'est pour lui indiquer visuellement qu'au delà
de telle taille il risque de se faire zapper, c'est suffisant.
Bon, reprenons la logique et les contraintes.
On veut saisir un texte dans un clickodrome, le stocker en sgbdr, et
le restituer. Ca devrait pas être si difficile que ça sur le papier.
En pratique, pour pas se faire tarter au passage, c'est moins facile.
Concernant le filtrage des données en entrée, depuis des années,
c'était demerden zie sich elein. Depuis peu, l'extension filter est
disponible : http://fr2.php.net/manual/en/ref.filter.php
A éplucher pour voir si le comportement te convient.
Ensuite, faut-il désamorcer en entrée ou en sortie ? Perso je
désamorce en entrée, quitte à refaire l'opération inverse en sortie si
finalement mon canal n'est pas du html. D'aucuns font l'inverse.
Faut-il désamorcer les xss en convertissant les < et les > ou en
utilisant strip_tags ? Bonne question. La seconde bouffe tout ce qui
se trouve entre < et > sans autre forme de procès, même si ce n'est
pas du html : a<b et b>c => ac
Ca m'empêche pas de l'utiliser, tout dépend du besoin potentiel des
utilisateurs d'entrer ce genre de choses. Dans une application de
commerce électronique, le besoin est totalement nul, pas plus en
frontal qu'en backoffice.
Et enfin les problèmes d'affichage, comme les " perdues dans des
attributs. La seule solution est de les transformer au moment où on
les renvoie vers le navigateur, ou de les avoir transformées avant
stockage dans le sgbd.
Ca dépend où on l'appelle et ça dépend de quel type d'attaque. Petite
galerie des horreurs possibles et quelques remèdes sur
http://www.saphirtech.com/securite.html
En effet, si on fait la modification avant le stockage, comme je
l'indiquais déjà dans ce thread, il faut prévoir des tailles
supérieures. Cela a aussi d'aures effets de bord, en particulier sur
le ORDER BY.
problème, mais j'en connais qui risquent quand même de couiner parce
que le
Rôôh, meuuuh non, les utilisateurs ? Couiner pour ça ? Pourquoi
*seulement* pour ça ?
Oui, mais bon, avec un maxlength="10" l'utilisateur ne peut
normalement pas saisir plus de 10 caractères. Si ?
Tout dépend de ce qu'il utilise comme clickodrome. Je t'assure que mon
lynx s'en foutra éperdument, et quand à wget ou curl, je te dis même
pas. Donc il faut voir à quoi/qui sert cette restriction si elle est
faite côté cient. Si c'est pour lui indiquer visuellement qu'au delà
de telle taille il risque de se faire zapper, c'est suffisant.
Bon, reprenons la logique et les contraintes.
On veut saisir un texte dans un clickodrome, le stocker en sgbdr, et
le restituer. Ca devrait pas être si difficile que ça sur le papier.
En pratique, pour pas se faire tarter au passage, c'est moins facile.
Concernant le filtrage des données en entrée, depuis des années,
c'était demerden zie sich elein. Depuis peu, l'extension filter est
disponible : http://fr2.php.net/manual/en/ref.filter.php
A éplucher pour voir si le comportement te convient.
Ensuite, faut-il désamorcer en entrée ou en sortie ? Perso je
désamorce en entrée, quitte à refaire l'opération inverse en sortie si
finalement mon canal n'est pas du html. D'aucuns font l'inverse.
Faut-il désamorcer les xss en convertissant les < et les > ou en
utilisant strip_tags ? Bonne question. La seconde bouffe tout ce qui
se trouve entre < et > sans autre forme de procès, même si ce n'est
pas du html : a<b et b>c => ac
Ca m'empêche pas de l'utiliser, tout dépend du besoin potentiel des
utilisateurs d'entrer ce genre de choses. Dans une application de
commerce électronique, le besoin est totalement nul, pas plus en
frontal qu'en backoffice.
Et enfin les problèmes d'affichage, comme les " perdues dans des
attributs. La seule solution est de les transformer au moment où on
les renvoie vers le navigateur, ou de les avoir transformées avant
stockage dans le sgbd.
- De manière tout à fait logique, une fois entré dans la table SQL
correspondante, le contenu du champ « C'est mon très "gros" chien »
devient
« C'est mon très "gros" chien »
- De manière tout à fait logique, une fois entré dans la table SQL
correspondante, le contenu du champ « C'est mon très "gros" chien »
devient
« C'est mon très "gros" chien »
- De manière tout à fait logique, une fois entré dans la table SQL
correspondante, le contenu du champ « C'est mon très "gros" chien »
devient
« C'est mon très "gros" chien »
La base de donnée devrait contenir l'information (C'est mon très
"gros" chien) plutot que sa représentation sous forme HTML. Ca évitera
bien des soucis quand on voudra utiliser l'information pour autre
chose que du HTML (et du même coup ca résoud tes autres problemes).
Donc stoquer les données telles quelles dans la base et utiliser
htmlentities sur les données qu'on affiche sur la page (qu'elles
viennent de l'utilisateur ou pas).
La base de donnée devrait contenir l'information (C'est mon très
"gros" chien) plutot que sa représentation sous forme HTML. Ca évitera
bien des soucis quand on voudra utiliser l'information pour autre
chose que du HTML (et du même coup ca résoud tes autres problemes).
Donc stoquer les données telles quelles dans la base et utiliser
htmlentities sur les données qu'on affiche sur la page (qu'elles
viennent de l'utilisateur ou pas).
La base de donnée devrait contenir l'information (C'est mon très
"gros" chien) plutot que sa représentation sous forme HTML. Ca évitera
bien des soucis quand on voudra utiliser l'information pour autre
chose que du HTML (et du même coup ca résoud tes autres problemes).
Donc stoquer les données telles quelles dans la base et utiliser
htmlentities sur les données qu'on affiche sur la page (qu'elles
viennent de l'utilisateur ou pas).
La base de donnée devrait contenir l'information (C'est mon très
"gros" chien) plutot que sa représentation sous forme HTML.
Vieux débat.
Ca évitera bien des soucis
Ca évitera un appel de fonction qu'on ferait sinon systématiquement dans
quand on voudra utiliser l'information pour
autre chose que du HTML
Encore faut(il en avoir le besoin.
(et du même coup ca résoud tes autres problemes).
Non.
Donc stoquer les données telles quelles dans la base et utiliser
htmlentities sur les données qu'on affiche sur la page (qu'elles
viennent de l'utilisateur ou pas).
J'avoue que je ne comprends pas trop : si je fais cela, est-ce que mes
données seront protégées contre l'injection de scripts malveillants et
autres méchancetés ?
La base de donnée devrait contenir l'information (C'est mon très
"gros" chien) plutot que sa représentation sous forme HTML.
Vieux débat.
Ca évitera bien des soucis
Ca évitera un appel de fonction qu'on ferait sinon systématiquement dans
quand on voudra utiliser l'information pour
autre chose que du HTML
Encore faut(il en avoir le besoin.
(et du même coup ca résoud tes autres problemes).
Non.
Donc stoquer les données telles quelles dans la base et utiliser
htmlentities sur les données qu'on affiche sur la page (qu'elles
viennent de l'utilisateur ou pas).
J'avoue que je ne comprends pas trop : si je fais cela, est-ce que mes
données seront protégées contre l'injection de scripts malveillants et
autres méchancetés ?
La base de donnée devrait contenir l'information (C'est mon très
"gros" chien) plutot que sa représentation sous forme HTML.
Vieux débat.
Ca évitera bien des soucis
Ca évitera un appel de fonction qu'on ferait sinon systématiquement dans
quand on voudra utiliser l'information pour
autre chose que du HTML
Encore faut(il en avoir le besoin.
(et du même coup ca résoud tes autres problemes).
Non.
Donc stoquer les données telles quelles dans la base et utiliser
htmlentities sur les données qu'on affiche sur la page (qu'elles
viennent de l'utilisateur ou pas).
J'avoue que je ne comprends pas trop : si je fais cela, est-ce que mes
données seront protégées contre l'injection de scripts malveillants et
autres méchancetés ?
Deux méthodes avec leurs caractéristiques.
Tronc commun aux deux méthodes, but éviter les injections SQL.
Les données brutes sont dans $_GET/POST/REQUEST. On échappe les ' (et
" selon la syntaxe SQL) et on vérifie que les entiers sont bien des
entiers. Ceci permet de faire sereinement des requêtes SQL, par
exemple pour stocker du texte qu'on renverra plus tard à un
navigateur.
Maintenant le besoin est de protéger le navigateur en sortie contre
les XSS.
Méthode 1: on n'a pas envie d'oublier un htmlentities/sp dans un coin
en sortie. Donc on désamorce avant stockage au même endroit que ce qui
fait le traitement précédent. [couic]
Les deux méthodes ont leurs avantages/inconvénients. Je suis venu à la
première par factorisation du code et simplification. La seconde est
plus logique, plus "normale". Mais trop besogneuse à mon goût, si
faille il y a on ne la verra que quand il sera trop tard. L'essentiel
est de faire un choix conscient des forces et faiblesses de ses
méthodes.
Attention à ce propos : dans les choses qu'on renvoie au navigateur,
il y a trois catégories.
- le texte pur. Là on interdit les < et > pour désamorcer, ça suffit.
- le texte acceptant le html. Là les ennuis sérieux commencent.
- les données binaires. N'oubliez pas que les images et les vidéos et
flash SONT DES VECTEURS DE XSS (et d'injections de code php) et
doivent être désamorcés COMME LES AUTRES. Et là je serai catégorique,
on désamorce AVANT stockage, *AUCUNE* raison n'existe de le faire à
l'envoi.
Deux méthodes avec leurs caractéristiques.
Tronc commun aux deux méthodes, but éviter les injections SQL.
Les données brutes sont dans $_GET/POST/REQUEST. On échappe les ' (et
" selon la syntaxe SQL) et on vérifie que les entiers sont bien des
entiers. Ceci permet de faire sereinement des requêtes SQL, par
exemple pour stocker du texte qu'on renverra plus tard à un
navigateur.
Maintenant le besoin est de protéger le navigateur en sortie contre
les XSS.
Méthode 1: on n'a pas envie d'oublier un htmlentities/sp dans un coin
en sortie. Donc on désamorce avant stockage au même endroit que ce qui
fait le traitement précédent. [couic]
Les deux méthodes ont leurs avantages/inconvénients. Je suis venu à la
première par factorisation du code et simplification. La seconde est
plus logique, plus "normale". Mais trop besogneuse à mon goût, si
faille il y a on ne la verra que quand il sera trop tard. L'essentiel
est de faire un choix conscient des forces et faiblesses de ses
méthodes.
Attention à ce propos : dans les choses qu'on renvoie au navigateur,
il y a trois catégories.
- le texte pur. Là on interdit les < et > pour désamorcer, ça suffit.
- le texte acceptant le html. Là les ennuis sérieux commencent.
- les données binaires. N'oubliez pas que les images et les vidéos et
flash SONT DES VECTEURS DE XSS (et d'injections de code php) et
doivent être désamorcés COMME LES AUTRES. Et là je serai catégorique,
on désamorce AVANT stockage, *AUCUNE* raison n'existe de le faire à
l'envoi.
Deux méthodes avec leurs caractéristiques.
Tronc commun aux deux méthodes, but éviter les injections SQL.
Les données brutes sont dans $_GET/POST/REQUEST. On échappe les ' (et
" selon la syntaxe SQL) et on vérifie que les entiers sont bien des
entiers. Ceci permet de faire sereinement des requêtes SQL, par
exemple pour stocker du texte qu'on renverra plus tard à un
navigateur.
Maintenant le besoin est de protéger le navigateur en sortie contre
les XSS.
Méthode 1: on n'a pas envie d'oublier un htmlentities/sp dans un coin
en sortie. Donc on désamorce avant stockage au même endroit que ce qui
fait le traitement précédent. [couic]
Les deux méthodes ont leurs avantages/inconvénients. Je suis venu à la
première par factorisation du code et simplification. La seconde est
plus logique, plus "normale". Mais trop besogneuse à mon goût, si
faille il y a on ne la verra que quand il sera trop tard. L'essentiel
est de faire un choix conscient des forces et faiblesses de ses
méthodes.
Attention à ce propos : dans les choses qu'on renvoie au navigateur,
il y a trois catégories.
- le texte pur. Là on interdit les < et > pour désamorcer, ça suffit.
- le texte acceptant le html. Là les ennuis sérieux commencent.
- les données binaires. N'oubliez pas que les images et les vidéos et
flash SONT DES VECTEURS DE XSS (et d'injections de code php) et
doivent être désamorcés COMME LES AUTRES. Et là je serai catégorique,
on désamorce AVANT stockage, *AUCUNE* raison n'existe de le faire à
l'envoi.
