Prevención de problemas de seguridad en Rails

La seguridad es una preocupación importante para cualquier desarrollador que aspire a un desarrollo exitoso y sostenible de aplicaciones web. Todo desarrollador quiere codificar de tal manera que sus aplicaciones estén lo más seguras posible contra cualquier ataque; sin embargo, ningún código puede estar libre de errores o ser seguro. Por lo tanto, los desarrolladores son conscientes de que deben hacer todo lo posible para que sus aplicaciones tengan una vulnerabilidad mínima a los ataques. Detectar vulnerabilidades es fácil, pero las infracciones de seguridad y los ataques pueden provocar pérdidas. Esta es la razón por la que siempre es mejor comprobar si hay problemas de seguridad desde el inicio del proceso de desarrollo de la aplicación, además de realizar controles de calidad periódicos para mantener el rumbo.

1]Sesiones

Un buen lugar para empezar a evaluar la seguridad es con las sesiones, que pueden ser vulnerables a ciertos ataques.

sesión[:user_id] = @current_user.id Usuario.find(sesión[:user_id])

– De forma predeterminada, Ruby on Rails utiliza un almacén de sesiones basado en cookies. Esto implica que, a menos que se cambie algo, la sesión no caducará en el servidor. Por lo tanto, significa que nunca debemos guardar datos confidenciales, como contraseñas e identificaciones, etc., en las sesiones.
– Por lo tanto, la mejor práctica es trabajar con una sesión basada en base de datos, lo cual es muy fácil con Rails –

Proyecto::Application.config.session_store:active_record_store
El ID de sesión es una cadena hexadecimal aleatoria de 32 caracteres.

El ID de sesión se genera utilizando SecureRandom.hex, que genera una cadena hexadecimal aleatoria utilizando cualquiera de los métodos específicos de la plataforma, como OpenSSL, /dev/urandom o Win32, para generar números aleatorios criptográficamente seguros. Actualmente, no es posible realizar ataques de fuerza bruta, es decir, de prueba y error, en las credenciales de inicio de sesión en los ID de sesión de Rails.

Estos son algunos de los ataques comunes basados en sesiones:
Secuestro de sesión: esto permite a los atacantes robar el ID de sesión de un usuario y utilizar la aplicación web en nombre de la víctima.
Fijación de sesión: además de robar la ID de sesión de un usuario, el atacante también es capaz de arreglar una ID de sesión que conoce. Esto se llama fijación de sesión.
Caducidad de la sesión: los atacantes también intentan aumentar el período de tiempo del ataque con sesiones que nunca caducan. Los ataques como la falsificación de solicitudes entre sitios (CSRF), el secuestro de sesiones y la fijación de sesiones son ejemplos.

2] Inyección de comandos

Una aplicación se vuelve vulnerable a la inyección de comandos, en caso de que el atacante pueda influir en los parámetros de la línea de comandos o en los comandos de Unix en su conjunto. Sin embargo, dado que ejecutar comandos UNIX en Rails no es común, es menos probable que se produzcan estos ataques.
Por otro lado, pueden surgir vulnerabilidades en un proceso en segundo plano que haga uso directo de los comandos de Unix para los datos del cliente.

Estos son algunos de los métodos comunes de línea de comandos de Rails:
%x[…]
sistema()
ejecutivo()
`…`
También cabe señalar que hay más de una forma de encadenar comandos, pero eso también depende del sistema operativo del alojamiento. Ejemplos: “&”, “&&”, “|”, “||” etc.
Variables de entorno seguras al ejecutar comandos
Los procesos que ejecutan sus aplicaciones Rails obtienen las variables de entorno de los procesos principales que pueden formar parte de las claves API, etc.

3] Inyección SQL

La inyección SQL ocurre cuando un usuario puede manipular un valor que se usa de manera insegura dentro de una consulta SQL. Esto puede provocar pérdida de datos, fugas de datos y privilegios elevados, entre otros resultados no deseados.

La inyección SQL es un ataque muy fácil y común que suele ocurrir y su impacto puede ser muy severo dependiendo del sitio web y de la situación en la que ocurre.

Como desarrolladores, debemos ocuparnos de todas aquellas posibilidades en las que puede ocurrir la inyección de SQL y debemos manejarlas en consecuencia.

Así es como se ve la inyección SQL:

Empleado.all(:condiciones => "designación = #{params[:designación]}")

El código anterior es vulnerable a la inyección de SQL, el siguiente código evitará la inyección de SQL.

Empleado.all(:condiciones => ['designación =?', parámetros[:designación]])

O

Empleado.all(:condiciones => {:designación => parámetros[:designación]})

Contramedidas contra la inyección SQL en Rails

Probar cada declaración para inyección SQL puede ser un trabajo tedioso, pero debemos tomar algunas contramedidas, como un escáner de código estático como un guardafrenos, y usted puede escribir algunos casos de prueba unitaria.
a)Regla general:– Nunca uses parámetros en la inflexión de cuerdas (#{}) así
P.ej

Usuario.donde("nombre = '#{params[:nombre]}'")

b)Cuidado que los parámetros también pueden ser una matriz, por ejemplo:

params[:user] si agrega ?user[]=1 a la URL. ¿El usuario existe? params[:usuario] luego ejecutará la consulta SELECCIONAR 1 COMO uno DE “usuarios” DONDE (1) LIMITAR 1.

4]Secuencias de comandos entre sitios (XSS)

Con la ayuda de XSS, un atacante puede ejecutar scripts en el contexto de seguridad de su aplicación web.

Considere este fragmento de vista de Rails: <%= @flat.title %>. Si el título del piso se edita junto con la adición del HTML, esta vista de Rails representa ese HTML en el contexto de seguridad de la aplicación. Por lo tanto, el navegador ejecutará HTML, que es XSS.

De hecho, esto no funciona en Rails hoy en día todavía, en Rails versión 2 se le pediría escapar de cada entrada del usuario: <%= h(@flat.title) %>
Hoy en día, Rails viene con una bandera en cada cadena que la marca como HTML, ya sea segura o no: @flat.title.html_safe?. En caso de que no sea seguro (por ejemplo, de un parámetro, de la base de datos,…), se escapará automáticamente al usarlo de esta manera: <%= @flat.title %>
En Rails 3.0, la protección contra XSS es un comportamiento predeterminado.

Contramedidas

a) Una estrategia de Política de seguridad de contenidos (CSP)

Una seguridad de contenido Política tiene básicamente la forma de un encabezado HTTP y esto hace una declaración de las reglas sobre qué fuentes están permitidas para todo tipo de activos. Como consecuencia de seguir estas reglas, todo lo demás está prohibido. Una vez implementado correctamente, es capaz de eliminar todas las vulnerabilidades de Cross-Site-Scripting (XSS) en su aplicación.

b) HTML seguro, ActiveSupport::SafeBuffer

Rails 3 introdujo el módulo ActiveSupport::SafeBuffer para agregar un indicador HTML seguro a las cadenas. De forma predeterminada, es falso, especialmente cuando la cadena tiene una fuente externa como la base de datos o los parámetros. La bandera se devuelve con "string".html_safe?.

El método de escape HTML h() escapa de la cadena que marca una cadena como segura para HTML.

h("html>").html_safe? #=> verdadero ("html>").html_safe? #=>falso

c) Prevención XSS OWASP (Proyecto de seguridad de aplicaciones web abiertas)

Para prevenir XSS, todos los datos que no sean de confianza deben negarse y restringirse para que no se coloquen directamente en HTML o en cualquier otro contexto (como JavaScript, CSS, contextos de atributos).

d) Protección XSS en plantillas HAML

Al utilizar las plantillas Haml, en lugar de ERB, las cadenas se escapan automáticamente de la misma manera que en las plantillas ERB. Y de la misma manera que ocurre con las plantillas ERB, las cadenas HTML seguras (string.html_safe? devuelve verdadero) no se omiten automáticamente. La notación != en Haml funciona de la misma manera que <%= raw(…) %> funciona en ERB, por lo que representa la versión sin escape.
Por defecto,

=" enfatizado " != " enfatizado "

compila a:

enfatizado enfatizado

Por lo tanto, se debe tener cuidado al usar != en Haml y se debe asegurar que ningún dato del usuario quede sin escape.
A continuación se presentan algunas medidas preventivas que se pueden tomar al desarrollar la aplicación de rieles.

1]Autenticación

Utilice dispositivo o gema Authlogic.
– Para habilitar la autenticación, no olvide agregar ->

clase Controlador de proyecto < Controlador de aplicación
filtro_antes: autenticar_usuario
– De forma predeterminada, Devise requiere solo 6 caracteres para una contraseña. El mínimo se puede cambiar en: /config/initializers/devise.rb
config.contraseña_longitud = 8..128
– Puede cambiar la complejidad de la contraseña agregando el siguiente código en el modelo de usuario.

validar: contraseña_complejidad def contraseña_complejidad si contraseña.presente? y no contraseña.match(/\A(?=.*[az])(?=.*[AZ])(?=.*\d).+\z/) errores.add :contraseña, "debe incluir al menos una letra minúscula, una letra mayúscula y un dígito" final

2]Referencia directa insegura a objetos o navegación forzada

– Las aplicaciones Ruby on Rails utilizan una estructura de URL tranquila, lo que hace que las rutas utilizadas sean en su mayoría adivinables e intuitivas. Por lo tanto, para protegerse contra un usuario que intenta acceder o modificar datos que pertenecen a otro usuario, las acciones deben controlarse específicamente. No existe tal tipo de protección incorporada desde el principio en una aplicación Vanilla Rails. Además, se puede realizar manualmente a nivel del controlador.
– Utilice cancancan o pandit para control de acceso

3] Asignación masiva y parámetros sólidos

- clase Proyecto < ActiveRecord::Base attr_accessible :nombre, :admin fin

Según el ejemplo anterior, con el atributo admin accesible, lo siguiente podría funcionar:
– curl -d “proyecto[nombre]=triage&proyecto[admin]=1” host:puerto/proyectos
– config.active_record.whitelist_attributes = verdadero

4]Redirecciones y reenvíos

– Es recomendable evitar el uso de redirecciones que utilizan parámetros
Por ejemplo:- //www.example.com/redirect?url=//www.example_commerce_site.com/checkout
– la protección restrictiva es utilizar :only_path

comenzar si ruta = URI.parse(params[:url]).ruta redirigir_a ruta finalizar URI de rescate::InvalidURIError redirección_to '/' fin

– Tener un hash de sitios aprobados y permitir que solo ellos sean redirigidos.

5]Rutas de renderizado dinámico

– Se debe tener cuidado al renderizar dinámicamente cualquier vista en función de alguna condición. Podría provocar que se cargue la vista de administrador.

6] Intercambio de recursos entre orígenes

– Me gusta la carga de archivos.
– El sitio receptor debe restringir y permitir únicamente los dominios incluidos en la lista blanca y asegurarse de que las solicitudes también provengan únicamente de esos dominios.
– Configure también el encabezado Access-Control-Allow-Origin tanto en la respuesta a la solicitud de OPCIONES como en la solicitud POST. Esto se debe a que la solicitud de OPCIONES se envía primero para determinar si el sitio remoto o receptor permite el dominio solicitante.
– Se envía una solicitud POST. Una vez más, se debe configurar el encabezado para que la transacción se muestre como exitosa.

7]Errores de lógica empresarial

– Las aplicaciones, independientemente de la tecnología en la que se basen, pueden contener errores de lógica empresarial que tienden a provocar errores de seguridad. Puede resultar realmente complicado detectar estos errores de seguridad utilizando herramientas automatizadas. Prácticas como revisiones periódicas de los códigos, programación de pares y redacción de pruebas unitarias pueden ayudarle a evitar que surjan estos errores de seguridad.

8]Archivos confidenciales

A continuación se muestran algunos archivos que debemos cuidar al desarrollar una aplicación web.
/config/database.yml: puede contener credenciales de producción.
/config/initializers/secret_token.rb: contiene un secreto utilizado para codificar las cookies de sesión.
/db/seeds.rb: puede contener datos semilla, incluido el usuario administrador de arranque.
/db/development.sqlite3: puede contener datos reales.

9]Cifrado

Ruby on Rails utiliza cifrado del sistema operativo. Casi nunca deberías escribir tus propias soluciones de cifrado.
Actualizar Rails y tener un proceso para actualizar dependencias.

Herramientas para detectar problemas de seguridad en aplicaciones Rails

• Guardafrenos
• auditoría de paquetes
• Código homónimo::Amanecer
• Bastidor::Ataque
• Tarántula
• Cinturón de herramientas Hakiri