Caracteres bidirecionais em idiomas LTR recebem correção de segurança

Suporte
1

Acabei de me deparar com o seguinte PR:

Acho que pode tornar texto legítimo em hebraico ou árabe ilegível.

Uma das soluções que encontrei foi desativar os algoritmos Unicode e apenas exibir alguma representação de caracteres não imprimíveis (acho que foi implementado no Pootle).
Então, basicamente, a ideia é transformar:
Este‎‏ texto

Em:
Este\\u003cLRM\\u003e\\u003cRLM\u003e texto

Dessa forma, o usuário pode escolher se isso é malicioso ou não, entendendo quais são os caracteres reais e possivelmente escolhendo ativar os algoritmos Unicode para poder ler o texto corretamente.
Obrigado.

3 curtidas
3

Obrigado por levantar esta questão, pensamos nessa preocupação. A correção que você vinculou na OP aplica-se apenas a caracteres bidirecionais Unicode em blocos pre e code, escritos manualmente como HTML ou gerados a partir de blocos de código cercados por markdown \u003ccode\u003e```\u003c/code\u003e, portanto, não deve ser um problema com texto hebraico ou árabe regular em uma postagem composta.

2 curtidas
7

Demo:

#include <cstdio.h>

int main() {
    /* Say hello; newline<U+2067> /*/ return 0 ;
    printf("Hello world.\n");
    return 0;
}

#include 

int main() {
    /* Say hello; newline<U+2067> /*/ return 0 ;
    printf("Hello world.\n");
    return 0;
}

Test: “שלום חבר” - Hello Friend

Without BIDI

Test: “שלום חבר” - Hello Friend

Markdown:

Test: "שלום חבר" - Hello Friend

Without BIDI

Test: "שלום חבר" - Hello Friend

Não é o melhor exemplo do mundo, mas você deve entender a ideia aqui, isso só afeta o código-fonte postado no fórum. Caracteres Bidi em código-fonte não é algo que geralmente é feito.

5 curtidas
8

Vou dar outro exemplo onde nenhum RLM quebra a frase.

שלום לכולם ובמיוחד ל־Sam, Martin בחר לעזוב אותנו.

שלום לכולם ובמיוחד ל־Sam,‏ Martin בחר לעזוב אותנו.

Você vê a diferença?
A única mudança é o RLM, eu queria parabenizar Sam e informar que Martin está saindo (sem ofensa).

3 curtidas
9

Sim, esse exemplo é certamente muito melhor! Como você pode ver, ele continua funcionando e não é impactado pela correção de segurança :tada:

4 curtidas
10

Hmmm, não é um bloco de código :slight_smile:
Quero dizer que dentro de um bloco de código não aparecerá como esperado (É sobre isso que se trata a correção, certo?)

1 curtida
11

Sim, mas por que você incluiria isso em um bloco de código?

2 curtidas
12

Trecho do gettext, strings nativas hebraicas/árabes, existem tais casos.

2 curtidas
13

Eu gostaria que o caso atípico aqui tivesse soluções alternativas (captura de tela, uploads de anexos e assim por diante), também é bem claro que o caractere especial está no lugar.

O risco de https://trojansource.codes/ é maior do que o risco de interrupção leve em casos atípicos extremos.

3 curtidas
14

Mas minha sugestão quebra a frase com alguma indicação, então substituir o RLM e LRM por \\u003cRLM\u003e ou \\u003cLRM\u003e mostrará ao usuário que havia caracteres adicionais e agora o texto está sendo renderizado sem eles, ainda informando que isso pode quebrar a experiência e que há uma opção para substituí-los manualmente, se necessário, remover os caracteres completamente sem alguns indicadores não dá margem para decisões informadas.

E isso também evitará código malicioso como você mencionou, porque o usuário poderá ver o código malicioso com os indicadores.

Tentarei obter algumas capturas de tela do Pootle, não me lembro de ter visto essa opção de strings brutas nos últimos anos, foi muito útil quando começamos a corrigir a localização do LibreOffice.

2 curtidas
15

Não entendi, nós não removemos, nós substituímos, veja meu exemplo acima

3 curtidas
16

Entendo, não seria melhor usar os nomes deles em vez de entidades Unicode?

1 curtida
17

Se houver confusão repetida relatada em uso real, podemos certamente refinar.

3 curtidas
18

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.