Caracteres bidireccionales en idiomas LTR publican corrección de seguridad

Soporte
1

Me acabo de encontrar con la siguiente PR:

Creo que puede hacer que texto legítimo en hebreo o árabe sea ilegible.

Una de las soluciones que encontré fue deshabilitar los algoritmos de Unicode y simplemente mostrar una representación de caracteres no imprimibles (creo que se implementó en Pootle).
Así que, básicamente, la idea es convertir:
Este‎‏ texto

En:
Este\\u003cLRM\u003e\\u003cRLM\u003e texto

De esta manera, el usuario puede elegir si esto es malicioso o no, entendiendo cuáles son los caracteres reales y posiblemente eligiendo habilitar los algoritmos de Unicode para poder leer el texto correctamente.
Gracias.

3 Me gusta
3

Gracias por plantear esto, tuvimos en cuenta esta preocupación. La corrección que enlazaste en el OP solo se aplica a los caracteres bidireccionales unicode en bloques pre y code, ya sea escritos manualmente como HTML o generados a partir de bloques de código delimitados por \u003ccode\u003e```\u003c/code\u003e, por lo que no debería ser un problema con texto hebreo o árabe normal en una publicación compuesta.

2 Me gusta
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

No es el mejor ejemplo del mundo, pero deberías entender la idea aquí, solo afecta al código fuente que se publica en el foro. Los caracteres Bidi en el código fuente no son algo que se suela hacer.

5 Me gusta
8

Te daré otro ejemplo en el que RLM no rompe la oración.

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

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

¿Ves la diferencia?
El único cambio es RLM, quería felicitar a Sam e informar que Martin se va (sin ofender).

3 Me gusta
9

¡Sí, ese ejemplo es ciertamente mucho mejor! Como puedes ver, sigue funcionando y no se ve afectado por la corrección de seguridad :tada:

4 Me gusta
10

Hmmm, no es un bloque de código :slight_smile:
Quiero decir que dentro de un bloque de código no aparecerá como se espera (¿De eso se trata la corrección, verdad?)

1 me gusta
11

Sí, pero ¿por qué lo incluirías en un bloque de código?

2 Me gusta
12

Extracto de gettext, cadenas nativas hebreo/árabe, hay tales casos.

2 Me gusta
13

Me gustaría que el caso atípico aquí tuviera soluciones alternativas (captura de pantalla, cargas de archivos adjuntos, etc.), además de que está bastante claro que el carácter especial está en su lugar.

El riesgo de https://trojansource.codes/ es mayor que el riesgo de una leve interrupción en casos atípicos extremos.

3 Me gusta
14

Pero mi sugerencia rompe la oración con alguna señal, por lo que reemplazar RLM y LRM con \\u003cRLM\u003e o \\u003cLRM\u003e mostrará al usuario que había caracteres adicionales y ahora el texto se muestra sin ellos, informando que podría afectar la experiencia y que existe la opción de reemplazarlos manualmente si es necesario, eliminar los caracteres por completo sin ningún indicador no deja lugar a decisiones informadas.

Y también evitará el código fuente troyano como mencionaste porque el usuario podrá ver el código malicioso con los indicadores.

Intentaré obtener algunas capturas de pantalla de Pootle, no recuerdo haber visto esa opción de cadenas de texto sin procesar en los últimos años, fue muy útil cuando comenzamos a corregir la localización de LibreOffice.

2 Me gusta
15

No sigo, reemplazamos, no quitamos, mira mi ejemplo anterior

3 Me gusta
16

Entiendo, ¿no sería mejor usar sus nombres en lugar de la entidad Unicode?

1 me gusta
17

Si se informa de confusión repetida en la práctica, ciertamente podemos ajustar.

3 Me gusta
18

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