Rieles: protección contra inyección de código y XSS

21

Empecé a usar Ruby on Rails, y me preguntaba si habría algún problema de seguridad que vigilar con Rails, en particular con respecto a la inyección de códigos y XSS.

Sé que Rails intenta prevenir tales ataques al desinfectar las entradas, pero creo que esto no puede ser infalible.

    
pregunta Magnus 11.11.2010 - 22:31
fuente

2 respuestas

11

Rails 3 tiene algunas protecciones bastante buenas activadas de forma predeterminada que detectan muchos problemas de seguridad comunes.

Específicamente, la codificación de salida ayudará a mitigar los ataques XSS, los tokens CSRF están habilitados de forma predeterminada en todos los formularios, lo que debería ayudar aquí, y siempre que lo uses correctamente, ActiveRecord u otros ORM pueden ayudar a mitigar la inyección de SQL.

En el frente de validación de entrada obviamente hay algunas cosas que hay que observar. Rails no realizará la validación de entrada por usted de manera predeterminada, por lo que si los datos ingresados en su aplicación se transfieren a otras aplicaciones web, todavía existe el riesgo de que ocurran ataques de XSS.

Dicho esto, Rails admite validaciones en el modelo y, si es posible, recomendaría la validación en lista blanca de la entrada allí.

En el frente de la inyección de SQL, todavía es posible usar el SQL sin procesar con ActiveRecord, y si lo hace, entonces pueden ocurrir los problemas habituales con la inyección de SQL, por lo que, nuevamente, la validación de todas las entradas es útil.

Más allá de eso hay varias cosas por observar. La instalación básica de Rails no proporciona autorización / autenticación, por lo que debe provenir de un complemento o ser escrita por el desarrollador.

Una desventaja de las URL de estilo RESTful que una aplicación de Rails producirá normalmente es que generalmente es fácil para un atacante intentar romper la autorización modificando la URL. Por ejemplo, una URL de enlace que muestra al primer usuario, podría modificarse fácilmente para tener un 2 o más. No es que sea menos seguro, pero facilita que los atacantes intenten eludir los controles de autorización.

Hay un par de buenas fuentes de información para la seguridad de Rails que vale la pena leer para obtener más información.

La guía de seguridad OWASP rails está aquí y también hay un libro Security on Rails de Pragmatic Programmers que, aunque se enfoca en Rails 2.3, todavía tiene mucha información útil a tener en cuenta (tenga en cuenta que Security on Rails es ahora fuera de impresión).

    
respondido por el Rоry McCune 11.11.2010 - 23:05
fuente
11

La OWASP XSS Cheat Sheet es un gran recurso para comprender todas las maneras en que XSS puede comprender. :

  • REGLA # 0: nunca inserte datos que no sean de confianza, excepto en ubicaciones permitidas
  • REGLA # 1: Escape de HTML antes de insertar datos no confiables en el contenido del elemento HTML
  • REGLA # 2 - Escape de atributos antes de insertar datos no confiables en atributos comunes de HTML
  • REGLA # 3 - Escape de JavaScript antes de insertar datos no confiables en HTML Valores de datos de JavaScript
  • REGLA # 4 - Escape de CSS antes de insertar datos no confiables en valores de propiedad de estilo HTML
  • REGLA # 5 - Escape de URL antes de insertar datos no confiables en valores de parámetros de URL de HTML
  • REGLA # 6: usar un motor de políticas HTML para validar o limpiar el código HTML dirigido por el usuario de forma saliente
  • REGLA # 7 - Impedir XSS basado en DOM

Rails no se ocupa de todas las reglas anteriores de forma automática y depende de la versión:

Rails 3.x="Si una cadena simple se pasa a un <% =% & gt ;, Rails siempre se escapa"
Rails 2.x = Debe usar el método h () (o usar algo como Francotirador de sitios cruzados o Safe Erb )

La lista blanca no rige el día: si espera una abreviatura postal de dos letras de EE. UU., utilice validaciones para aceptar solo eso.

Guía de seguridad general: enlace

    
respondido por el Tate Hansen 11.11.2010 - 23:34
fuente

Lea otras preguntas en las etiquetas