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
Olivier Miakinen
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.)
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.)
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
,&#;<>!§.$%?@|_=+
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) ?
Je n'arrive pas à trouver la corrélation entre ces valeurs
Auriez-vous des pistes ?
Démosthène
,&#;<>!§.$%?@|_=+
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) ?
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) ?
Je n'arrive pas à trouver la corrélation entre ces valeurs
Auriez-vous des pistes ?
Démosthène
Olivier Miakinen
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 <...>, etc.) alors tu peux sans risque autoriser n'importe quel 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 : <http://french.joelonsoftware.com/Articles/Unicode.html> [fr] <http://www.cl.cam.ac.uk/~mgk25/unicode.html> [en] <http://people.w3.org/rishida/scripts/uniview.fr/conversion.html> [fr]
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 <http://www.miakinen.net/vrac/charsets/> puisque ton point de comparaison est Latin1 plutôt qu'Unicode (mais les numéros de caractères sont identiques pour les deux).
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 <...>, etc.) alors tu peux sans risque autoriser n'importe quel
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 :
<http://french.joelonsoftware.com/Articles/Unicode.html> [fr]
<http://www.cl.cam.ac.uk/~mgk25/unicode.html> [en]
<http://people.w3.org/rishida/scripts/uniview.fr/conversion.html> [fr]
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
<http://www.miakinen.net/vrac/charsets/> puisque ton point de
comparaison est Latin1 plutôt qu'Unicode (mais les numéros de
caractères sont identiques pour les deux).
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 <...>, etc.) alors tu peux sans risque autoriser n'importe quel 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 : <http://french.joelonsoftware.com/Articles/Unicode.html> [fr] <http://www.cl.cam.ac.uk/~mgk25/unicode.html> [en] <http://people.w3.org/rishida/scripts/uniview.fr/conversion.html> [fr]
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 <http://www.miakinen.net/vrac/charsets/> puisque ton point de comparaison est Latin1 plutôt qu'Unicode (mais les numéros de caractères sont identiques pour les deux).
