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])

– By default, Ruby on Rails uses a Cookie-based session store. This implies that unless something is changed, the session will not expire on the server. So, it means that we should never keep sensitive data such as passwords and IDs etc in sessions.
– The best practice therefore, is to work with a database based session, which is very easy with Rails –

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

The session ID is generated using SecureRandom.hex which generates a random hexadecimal string using any of the platform-specific methods such as OpenSSL, /dev/urandom or Win32, for generating cryptographically secure random numbers. Currently, it is not possible to brute-force i.e trial and error attack on login credentials in Rails’ session Ids.

Estos son algunos de los ataques comunes basados en sesiones:
Session Hijacking:- This allows the attackers to steal a user’s session ID and use the web application in the victim’s name.
Session Fixation:- Apart from stealing a user’s session ID, the attacker is also capable of fixing a session ID known to them. This is called as session fixation.
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()
`…`
It should also be noted that there are more than one ways how to chain commands together, but that also depends on the hosting operating system. Examples: “&”, “&&”, “|”, “||” 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:– Never use params in string inflection (#{}) like so
P.ej

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

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

params[:user] if you add ?user[]=1 to the URL. User.exists? params[:user] will then run the query SELECT 1 AS one FROM “users” WHERE (1) LIMIT 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.
– To enable auth please dont forget to add ->

clase Controlador de proyecto < Controlador de aplicación
filtro_antes: autenticar_usuario
– By default Devise requires only  6 characters for a password. The minimum can be changed in: /config/initializers/devise.rb
config.contraseña_longitud = 8..128
– You can change the password complexity by adding the following code in user model.

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

– Ruby on Rails apps make use of a restful URL structure making the paths used mostly guessable and intuitive. So, in order to protect against a user trying to access or modify data that belongs to another user, the actions need to be specifically controlled. There is no such built-in kind of a protection out of t he gate on a vanilla Rails application. Further, it can be performed manually at the controller level.
– Use cancancan or pandit for access control

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 “project[name]=triage&project[admin]=1” host:port/projects
– config.active_record.whitelist_attributes = true

4]Redirecciones y reenvíos

– It is advisable to avoid using the redirects that use parameters
Por ejemplo:- //www.example.com/redirect?url=//www.example_commerce_site.com/checkout
– restrictive protection is to use the :only_path

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

– Have hash of approved sites and allow only them to get redirected.

5]Rutas de renderizado dinámico

– Care should be taken when you are dynamically rendering any view based on some condition. It might result in loading admin view.

6] Intercambio de recursos entre orígenes

– Like file upload.
– The receiving site should restrict and allow only whitelisted domains and make sure that requests are also coming from those domains only.
– Also set the Access-Control-Allow-Origin header in both the response to the OPTIONS request and POST request. This is because the OPTIONS request is sent first, in order to determine if the remote or receiving site allows the requesting domain.
– A POST request, is sent. Once again, the header must be set in order for the transaction to be shown as successful.

7]Errores de lógica empresarial

– The applications regardless of the technology they are based on, can comprise of business logic errors that are prone to lead to security bugs. It can be really tricky to detect such security bugs using the automated tools. The practices such as regular reviews of the codes, pair programming and writing unit tests can help you best avoid such security bugs to arise.

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 – Contains a secret used to hash session cookie.
/db/seeds.rb – May contain seed data including bootstrap admin user.
/db/development.sqlite3 – May contain real data.

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