html - how - xss prevention owasp

Impedir que las entidades de caracteres HTML en los archivos de configuración regional se vean afectadas por la protección de Rails3 xss (5)

¿Conoce el método html_safe que se puede usar en los ayudantes? No estoy seguro si entiendo el problema por completo, ya que nunca he trabajado con I18n, pero sería posible usar un ayudante personalizado que determine si los caracteres no deberían escaparse y devolver "string" .html_safe, y si debería se escapó, devuelve "cadena".

O posiblemente anule la ayuda "t" y agregue las condiciones de la lógica de escape + .html_safe

Estamos construyendo una aplicación, nuestra primera vez que usamos Rails 3, y tenemos que construir I18n desde el principio. Al ser perfeccionistas, queremos que se utilice una tipografía real en nuestras vistas: guiones, comillas en forma de rizo, puntos suspensivos, etc.

Esto significa que en nuestros archivos locales / xx.yml tenemos dos opciones:

Utilice caracteres UTF-8 reales en línea. Debería funcionar, pero es difícil de escribir, y me asusta debido a la cantidad de software que aún hace cosas malas a Unicode.
Use entidades de caracteres HTML (& # 8217; & # 8212; etc). Es más fácil de escribir y, probablemente, más compatible con el software que se comporta mal.

Prefiero tomar la segunda opción, sin embargo, el auto-escape en Rails 3 hace que esto sea problemático, ya que los símbolos en el YAML se convierten automáticamente en entidades de caracteres, dando como resultado "visibles" y 8217; s en el navegador.

Obviamente, esto puede solucionarse utilizando raw en cadenas, es decir:

raw t(''views.signup.organisation_details'')

Pero no estamos contentos de ir por el camino de raw crianza global cada vez que hacemos algo, ya que nos deja abiertos a cometer un error y producir un agujero XSS.

Podríamos seleccionar de forma selectiva cadenas raw formato que sabemos que contienen entidades de caracteres, pero esto sería difícil de escalar, y simplemente se siente mal; además, una cadena que contiene una entidad en un idioma puede no en otra.

¿Alguna sugerencia sobre una manera inteligente de arreglar los rieles? ¿O estamos condenados a la tipografía de mierda, agujeros xss, horas de esfuerzo perdido o todo?

Bien. Marcé esta pregunta ayer debido al ángulo i18n, pero no la respondí ya que soy una persona de Python que nunca ha usado Rails. Todavía no voy a responder, pero dado que no estás siendo invadido por los útiles Railsianos que podrían señalarte una buena manera de sortear las entrañas de Rails, esta es mi perspectiva, sin embargo.

En primer lugar, creo que es genial que estés pensando en el problema desde el principio. Eso es bastante raro. En segundo lugar, estoy completamente de acuerdo en que usar cadenas en bruto o seleccionar cadenas con entidades para dar un tratamiento especial a los sonidos como un truco frágil, feo y propenso a errores.

Ahora, si entiendo Rails correctamente (leí esta guía i18n ), los archivos YAML contienen la cadena localizada para cada idioma. En este caso, recomiendo encarecidamente utilizar caracteres regulares en ellos (en UTF-8). De lo contrario, mantener localizaciones, o incluso leer un archivo de traducción, ¡piense en idiomas en scripts no latinos! - va a ser el infierno.

Sí, significaría que tienes que descubrir los métodos de entrada, pero la solución es clara y directa.

Creo que no es una buena idea usar use "raw", podrías probar con una cadena yml como esta

en: hello: This generates a text paragraph for HTML. " " à @ '' All this text, which you can find in these lines, is being concatenated together to one single text node, and then put into the body of the <p> ... </p> tag. ↂↀऊᎣᏍᏮ⁜℺℻⊛⍟⎬⎨⏏♞♝⚫⚬✱✰✭❺❻➣➱➲⬡⬕

HTML

This generates a text paragraph for HTML. " " à @ '' All this text, which you can find in these lines, is being concatenated together to one single text node, and then put into the body of the <p> ... </p> tag. ↂↀऊᎣᏍᏮ⁜℺℻⊛⍟⎬⎨⏏♞♝⚫⚬✱✰✭❺❻➣➱➲⬡⬕

vista del navegador

Hay un ticket en faro para este problema, y la resolución es agregar _html a la clave i18n en el archivo locales/xx.yml y usar el alias t ¹ para denotar una cadena html_safe. Por ejemplo:

en: hello: "This is a string with an accent: ó"

se convierte en:

en: hello_html: "This is a string with an accent: ó"

Y crearía la siguiente salida:

Esta es una cuerda con un acento:

Esto evitaría tener que escribir raw t(''views.signup.organisation_details'') y daría como resultado una salida más limpia de: t(''views.signup.organisation_details_html'') . Y aunque el intercambio de raw en raw por _html no parece ser el mejor de los intercambios, deja en claro que se está emitiendo lo que se supone que es una cadena html_safe.

¹ He probado el código sugerido en el ticket del faro. Lo que encontré fue que tenías que usar específicamente el alias t . Si usó I18n.t o I18n.translate la traducción no trató a _html como html_safe:

I18n.t(''hello_html'') I18n.translate(''hello_html'') # Produces => "This is a string with an accent: ó" t(''hello_html'') # Produces => "This is a string with an accent: ó"

No creo que este sea el comportamiento previsto según la documentación de RoR TranslationHelper .

Si no desea exponerse a la posibilidad de un error simplemente agregando .html_safe (a través de alias_method_chain o w / e) a todo, la mejor solución es simplemente usarlo siempre que sea necesario.

En nuestro sitio, utilizamos un lenguaje de marcado para obtener resultados HTML de los archivos de configuración regional i18n, ya que quienes traducen esos archivos no son desarrolladores, solo traductores.

Si solo en algunos lugares necesita que su HTML sea realmente HTML, use .html_safe

t(''views.signup.organisation_details'').html_safe

El lenguaje de marcado simple que tenemos funciona bastante bien para nosotros, pero eso es realmente específico para cada caso :)