Je pense que cela pourrait rendre le texte hébreu ou arabe légitime illisible.
L’une des solutions que j’ai rencontrées a été de désactiver les algorithmes Unicode et d’afficher simplement une représentation des caractères non imprimables (je pense que c’était implémenté dans Pootle).
L’idée est donc essentiellement de transformer :
Ce texte
En :
Ce\\u003cLRM\u003e\\u003cRLM\u003e texte
De cette façon, l’utilisateur peut choisir s’il s’agit d’une attaque ou non en comprenant quels sont les caractères réels et éventuellement choisir d’activer les algorithmes Unicode pour pouvoir lire le texte correctement.
Merci.
Merci d’avoir soulevé ce point, nous avions pensé à cette préoccupation. La correction que vous avez liée dans le message initial ne s’applique qu’aux caractères bidirectionnels Unicode dans les blocs pre et code, qu’ils soient écrits manuellement en HTML ou générés à partir de blocs de code délimités par \u003ccode\u003e```\u003c/code\u003e, de sorte que cela ne devrait pas poser de problème avec le texte hébreu ou arabe ordinaire dans un message composé.
#include <cstdio.h>
int main() {
/* Dire bonjour ; nouvelle ligne<U+2067> /*/ return 0 ;
printf("Hello world.\n");
return 0;
}
#include
int main() {
/* Dire bonjour ; nouvelle ligne<U+2067> /*/ return 0 ;
printf("Hello world.\n");
return 0;
}
Test : "שלום חבר" - Bonjour l’ami
Sans BIDI
Test : “שלום חבר” - Bonjour l’ami
Markdown :
Test : ‫"שלום חבר" - Bonjour l'ami
Sans BIDI
Test : "שלום חבר" - Bonjour l'ami
Ce n’est pas le meilleur exemple du monde, mais vous devriez comprendre l’idée ici, cela n’affecte que le code source publié sur le forum. Les caractères Bidi dans le code source ne sont généralement pas utilisés.
Oui, cet exemple est certainement bien meilleur ! Comme vous pouvez le voir, il continue de fonctionner et n’est pas impacté par le correctif de sécurité
Hmmm ce n’est pas un bloc de code
Je voulais dire qu’à l’intérieur d’un bloc de code, il n’apparaîtra pas comme prévu (c’est à cela que sert la correction, n’est-ce pas ?)
Je voudrais que le cas extrême ici ait des solutions de contournement (capture d’écran, téléchargements de pièces jointes, etc.), et il est également assez clair que le caractère spécial est en place.
Le risque de https://trojansource.codes/ est plus élevé que le risque de perturbations mineures dans des cas extrêmes.
Mais ma suggestion casse la phrase avec un indice, donc remplacer le RLM et le LRM par \\u003cRLM\u003e ou \\u003cLRM\u003e montrera à l’utilisateur qu’il y avait des caractères supplémentaires et que le texte est maintenant rendu sans eux, tout en l’informant que cela pourrait nuire à l’expérience et qu’il existe une option pour les rétablir manuellement si nécessaire, en supprimant complètement les caractères sans aucun indicateur, cela ne laisse aucune place à des décisions éclairées.
Et cela empêchera également le code source de cheval de Troie comme vous l’avez mentionné, car l’utilisateur pourra voir le code malveillant avec les indicateurs.
J’essaierai d’obtenir des captures d’écran de Pootle, je ne me souviens pas avoir vu cette option de chaînes brutes au cours des deux dernières années, elle a été très utile lorsque nous avons commencé à corriger la localisation de LibreOffice.
