Methode de filtrage a revoir avec utf-8

Le
Demosthene
Bonjour,

Jusqu'alors, pour sécuriser mes formulaires, je faisais jouer un liste
blanche : "a-zçéèêëàâäùüûïîöôÿ-' " par exemple pour un patronyme.

Je bascule en UTF-8 et là rien ne va plus, ma liste ferais des kilomètres :)

Quelqu'un a t-il une liste de caractères à proscrire pour que je fasse
une liste noire efficace ?

,&#;<>!§.$%?@|_=+

Ce n'est pas une injure, c'est juste les caractères qui me semble
dangeureux. Y-en a t-il d'autres ?

Cordialement

Démosthène
Vos réponses
Trier par : date / pertinence
Olivier Miakinen
Le #119497

Jusqu'alors, pour sécuriser mes formulaires, je faisais jouer un liste
blanche : "a-zçéèêëàâäùüûïîöôÿ-' " par exemple pour un patronyme.

Je bascule en UTF-8 et là rien ne va plus, ma liste ferais des kilomètres :)

Quelqu'un a t-il une liste de caractères à proscrire pour que je fasse
une liste noire efficace ?


Il vaut toujours mieux indiquer les caractères autorisés que les
caractères interdits.

,&#;<>!§.$%?@|_=+


Là, par exemple, tu as oublié le retour chariot r, le saut de ligne n,
et le caractère nul .

Si tu peux vérifier que seuls les caractères ascii sont potentiellement
dangereux, alors tu peux envisager d'autoriser tous les caractères à
partir de U+00A0. Je ne sais pas comment exprimer cela avec des regexp
UTF-8 (pour peu que cela existe déjà), mais avec des regexp fonctionnant
sur les octets il te suffit de remplacer çéèêëàâäùüûïîöôÿ par x80-xFF.

--
Olivier Miakinen
Troll du plus sage chez les conviviaux : le nouveau venu, avec
son clan, s'infiltre dans les groupes de nouvelles. (3 c.)

Demosthene
Le #119491
,&#;<>!§.$%?@|_=+



Là, par exemple, tu as oublié le retour chariot r, le saut de ligne n,
et le caractère nul .

Si tu peux vérifier que seuls les caractères ascii sont potentiellement
dangereux, alors tu peux envisager d'autoriser tous les caractères à
partir de U+00A0. Je ne sais pas comment exprimer cela avec des regexp
UTF-8 (pour peu que cela existe déjà), mais avec des regexp fonctionnant
sur les octets il te suffit de remplacer çéèêëàâäùüûïîöôÿ par x80-xFF.


Que veux tu dire "Si tu peux vérifier que seuls les caractères ascii
sont potentiellement dangereux".

J'ai ma page web en utf-8, les données arrivent sur une page php qui
gère en ascii et non pas en utf-8 les chaines de caractères.

Je ne peux pas modifier ma base mysql (elle n'est pas en utf-8).

N'y-a t-il pas risque d'injection SQL si la premier ou le second octet
du caractère utf-8 est dangeureux (' par exemple) ?

--------------------------
Prenons le cas du é "traduit é": je ne comprends pas vraiement comment
cette "traduction" à lieu.
é valeur 233 codé E9 en hexa
à valeur 195 codé C3
© valeur 169 codé A9

Je n'arrive pas à trouver la corrélation entre ces valeurs

Auriez-vous des pistes ?

Démosthène


Olivier Miakinen
Le #119490

Si tu peux vérifier que seuls les caractères ascii sont potentiellement
dangereux, alors tu peux envisager d'autoriser tous les caractères à
partir de U+00A0. Je ne sais pas comment exprimer cela avec des regexp
UTF-8 (pour peu que cela existe déjà), mais avec des regexp fonctionnant
sur les octets il te suffit de remplacer çéèêëàâäùüûïîöôÿ par x80-xFF.


Que veux tu dire "Si tu peux vérifier que seuls les caractères ascii
sont potentiellement dangereux".


Je veux dire que cela dépend de ce que tu fais dans ton application. Si
seuls des caractères ASCII peuvent avoir une signification qui risque de
déclencher des comportements risqués (par exemple le saut de ligne, les
chevrons octet dont le bit de poids fort est à 1, donc n'importe quel octet de
n'importe quel caractère non-ASCII converti en UTF-8.

J'ai ma page web en utf-8, les données arrivent sur une page php qui
gère en ascii et non pas en utf-8 les chaines de caractères.


Attention aux contresens. Quand tu écris « en ascii » je suppose que
tu veux dire « octet par octet, sans tenir compte d'un éventuel codage
UTF-8 », c'est ça ? Tu peux écrire « en binaire » si tu veux, mais pas
« en ascii », ou alors cela signifie que tu tronques le 8e bit de chaque
octet, et alors tu perds tout caractère accentué ou non latin.

[...]

N'y-a t-il pas risque d'injection SQL si la premier ou le second octet
du caractère utf-8 est dangeureux (' par exemple) ?


Aucun des deux à quatre octets d'un caractère encodé en UTF-8 ne peut
être confondu avec un caractère ASCII. Si tu ne le sais pas (de même que
si tu ne sais pas qu'un encodage UTF-8 peut se faire sur plus de deux
octets), alors tu dois de toute urgence te renseigner avant d'espérer
faire un code propre, exempt de tout risque d'attaque (et même tout
simplement de faire un code qui fonctionne).

Voici quelques pointeurs :

--------------------------
Prenons le cas du é "traduit é": je ne comprends pas vraiement comment
cette "traduction" à lieu.
é valeur 233 codé E9 en hexa
à valeur 195 codé C3
© valeur 169 codé A9


Je n'arrive pas à trouver la corrélation entre ces valeurs

Auriez-vous des pistes ?


Voir les documents cités plus haut. Tu peux aussi avoir besoin de
comparaison est Latin1 plutôt qu'Unicode (mais les numéros de
caractères sont identiques pour les deux).


Publicité
Poster une réponse
Anonyme