J'ai un projet dans lequel j'essaie de permettre à d'autres codeurs, éventuellement hostiles, d'étiqueter, en minuscules, diverses propriétés qui seront affichées dans différents contextes, y compris l'intégration en HTML, sauvegardées et manipulées dans Postgres, utilisées comme étiquettes d'attribut en JavaScript, et manipulé dans le shell (par exemple, enregistrer un fichier de données sous le nom продажи.zip) ainsi que divers outils d'analyse de données comme l'outil graphique, etc.

J'ai déjà travaillé sur des projets multilingues, mais il s'agissait soit de petits clients qui n'avaient pas besoin de s'inquiéter particulièrement des attaques sophistiquées, soit de projets auxquels je suis arrivé après que l'aspect multilingue était en place, donc Je n'étais pas responsable de la vérification de la sécurité.

Je suis presque sûr que ceux-ci devraient être sûrs, mais je ne sais pas s'il y a des pièges que je dois rechercher, comme, par exemple, un caractère spécial [TAB] ou [QUOTE] dans le jeu de caractères chinois qui pourrait échapper à mon s'échapper.

Suis-je d'accord avec cela dans mon filtre regex?

dash       = '-'
english    = 'a-z'
italian    = ''
russain    = 'а-я'
ukrainian  = 'ґї'
german     = 'äöüß'
spanish    = 'ñ'
french     = 'çéâêîôûàèùëï'
portuguese = 'ãõ'
polish     = 'ąćęłńóśźż'
turkish    = 'ğışç'
dutch      = 'áíúýÿìò'
swedish    = 'å'
danish     = 'æø'
norwegian  = ''
estonian   = ''
romainian  = 'șî'
greek      = 'α-ωίϊΐόάέύϋΰήώ'
chinese    = '([\p{Han}]+)'
japanese   = '([\p{Hiragana}\p{Katakana}]+)'
korean     = '([\p{Hangul}]+)'
0
zachaysan 2 avril 2017 à 18:51

2 réponses

Meilleure réponse

Si vous vous limitez aux encodages de texte avec un sous-ensemble compatible ASCII 7 bits, vous êtes raisonnablement sûr de traiter tout ce qui précède 0x7f (U+007f) comme "sûr" lorsque vous interagissez avec la plupart des langages et outils de programmation sains. Si vous utilisez perl6, vous n'avez pas de chance;)

Vous devez éviter de prendre en charge ou faire particulièrement attention à la saisie ou à la sortie de texte en utilisant le codage de texte Shift-JIS , où le symbole ¥ est à 0x5c\ résiderait habituellement. Cela offre des opportunités de supercherie infâme en exploitant les conversions d'encodage.

Évitez ou faites très attention aux autres encodages non compatibles ascii. EBDIC en est un, mais il est peu probable que vous le rencontriez dans la nature. UTF-16 et UTF-32 évidemment, mais si vous les traitez mal, les résultats sont manifestement évidents.

En train de lire:

Personnellement, je pense que votre approche est à l'envers. Vous devez définir des fonctions d'entrée et de sortie pour les chaînes d'échappement et unescape selon les syntaxes lexicales de chaque outil ou langage cible, plutôt que d'essayer d'interdire tout métacaractère possible. Mais ensuite, je ne connais pas votre situation, et peut-être que ce n'est pas pratique pour ce que vous faites.

2
Craig Ringer 3 avril 2017 à 13:52

Je ne sais pas exactement quel est votre problème réel. Si vous convertissez correctement votre texte au format cible, vous ne vous souciez pas de ce que le texte pourrait éventuellement être. Cela garantira à la fois une conversion et une sécurité appropriées.

Par exemple:

  • Si votre texte doit être inclus dans HTML, il doit être échappé à l'aide des fonctions de citation HTML appropriées.

    Exemple:

    Mauvais

    // XXX DON'T DO THIS XXX
    echo "<span>".$variable."</span>"
    

    Droite:

    // Actual encoding function varies based your environment
    echo "<span>".htmlspecialchars($variable)."</span>"
    

    Oui, cela gérera également correctement le cas du texte contenant & ou <.

  • Si votre texte doit être utilisé dans une requête SQL, vous devez utiliser des requêtes paramétrées.

    Exemple:

    Mauvais

    // XXX DON'T DO THIS XXX
    perform_sql_query("SELECT this FROM that WHERE thing=".$variable")
    

    Droite

    // Actual syntax and function will vary
    perform_sql_query("SELECT this FROM that WHERE thing=?", [$variable]);
    
  • Si votre texte doit être inclus dans JSON, utilisez simplement les fonctions de codage JSON appropriées.

    Exemple:

    Mauvais

    // XXX DON'T DO THIS XXX
    echo '{"this":"'.$variable.'"}'
    

    Droite

    // actual syntax and function may vary
    echo json_encode({this: $variable});
    

Le shell est un peu plus délicat, et il est souvent difficile de gérer des caractères non ASCII dans de nombreux environnements (par exemple, FTP ou faire un scp entre différents environnements). N'utilisez donc pas de noms explicites pour les fichiers, utilisez des identifiants (identifiant numérique, uuid, hash ...) et stockez le mappage vers le nom réel ailleurs (dans une base de données).

1
jcaron 3 avril 2017 à 14:34