{"id":27233,"date":"2017-10-31T14:05:41","date_gmt":"2017-10-31T14:05:41","guid":{"rendered":"https:\/\/dev.railscarma.com\/preventing-security-issues-rails\/"},"modified":"2022-09-06T09:26:04","modified_gmt":"2022-09-06T09:26:04","slug":"prevencion-de-problemas-de-seguridad-rieles","status":"publish","type":"post","link":"https:\/\/www.railscarma.com\/es\/blog\/articulos-tecnicos\/prevencion-de-problemas-de-seguridad-rieles\/","title":{"rendered":"Prevenci\u00f3n de problemas de seguridad en Rails"},"content":{"rendered":"
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

La seguridad es una preocupaci\u00f3n 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\u00e9n lo m\u00e1s seguras posible contra cualquier ataque; sin embargo, ning\u00fan c\u00f3digo 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\u00ednima a los ataques. Detectar vulnerabilidades es f\u00e1cil, pero las infracciones de seguridad y los ataques pueden provocar p\u00e9rdidas. Esta es la raz\u00f3n por la que siempre es mejor comprobar si hay problemas de seguridad desde el inicio del proceso de desarrollo de la aplicaci\u00f3n, adem\u00e1s de realizar controles de calidad peri\u00f3dicos para mantener el rumbo.<\/p>

1]Sesiones<\/strong><\/h3>

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

sesi\u00f3n[:user_id] = @current_user.id Usuario.find(sesi\u00f3n[:user_id])<\/code><\/pre>
\u2013 De forma predeterminada, Ruby on Rails utiliza un almac\u00e9n de sesiones basado en cookies. Esto implica que, a menos que se cambie algo, la sesi\u00f3n no caducar\u00e1 en el servidor. Por lo tanto, significa que nunca debemos guardar datos confidenciales, como contrase\u00f1as e identificaciones, etc., en las sesiones.
\u2013 Por lo tanto, la mejor pr\u00e1ctica es trabajar con una sesi\u00f3n basada en base de datos, lo cual es muy f\u00e1cil con Rails \u2013<\/p>
Proyecto::Application.config.session_store:active_record_store
El ID de sesi\u00f3n es una cadena hexadecimal aleatoria de 32 caracteres.<\/p>
El ID de sesi\u00f3n se genera utilizando SecureRandom.hex, que genera una cadena hexadecimal aleatoria utilizando cualquiera de los m\u00e9todos espec\u00edficos de la plataforma, como OpenSSL, \/dev\/urandom o Win32, para generar n\u00fameros aleatorios criptogr\u00e1ficamente seguros. Actualmente, no es posible realizar ataques de fuerza bruta, es decir, de prueba y error, en las credenciales de inicio de sesi\u00f3n en los ID de sesi\u00f3n de Rails.<\/p>
Estos son algunos de los ataques comunes basados en sesiones:
Secuestro de sesi\u00f3n: esto permite a los atacantes robar el ID de sesi\u00f3n de un usuario y utilizar la aplicaci\u00f3n web en nombre de la v\u00edctima.
Fijaci\u00f3n de sesi\u00f3n: adem\u00e1s de robar la ID de sesi\u00f3n de un usuario, el atacante tambi\u00e9n es capaz de arreglar una ID de sesi\u00f3n que conoce. Esto se llama fijaci\u00f3n de sesi\u00f3n.
Caducidad de la sesi\u00f3n: los atacantes tambi\u00e9n intentan aumentar el per\u00edodo de tiempo del ataque con sesiones que nunca caducan. Los ataques como la falsificaci\u00f3n de solicitudes entre sitios (CSRF), el secuestro de sesiones y la fijaci\u00f3n de sesiones son ejemplos.<\/p>
2] Inyecci\u00f3n de comandos<\/strong><\/h3>
Una aplicaci\u00f3n se vuelve vulnerable a la inyecci\u00f3n de comandos, en caso de que el atacante pueda influir en los par\u00e1metros de la l\u00ednea de comandos o en los comandos de Unix en su conjunto. Sin embargo, dado que ejecutar comandos UNIX en Rails no es com\u00fan, 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.<\/p>
Estos son algunos de los m\u00e9todos comunes de l\u00ednea de comandos de Rails:
%x[\u2026]
sistema()
ejecutivo()
`…`
Tambi\u00e9n cabe se\u00f1alar que hay m\u00e1s de una forma de encadenar comandos, pero eso tambi\u00e9n depende del sistema operativo del alojamiento. Ejemplos: \u201c&\u201d, \u201c&&\u201d, \u201c|\u201d, \u201c||\u201d 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.<\/p>
3] Inyecci\u00f3n SQL<\/strong><\/h3>
La inyecci\u00f3n SQL ocurre cuando un usuario puede manipular un valor que se usa de manera insegura dentro de una consulta SQL. Esto puede provocar p\u00e9rdida de datos, fugas de datos y privilegios elevados, entre otros resultados no deseados.<\/p>
La inyecci\u00f3n SQL es un ataque muy f\u00e1cil y com\u00fan que suele ocurrir y su impacto puede ser muy severo dependiendo del sitio web y de la situaci\u00f3n en la que ocurre.<\/p>
Como desarrolladores, debemos ocuparnos de todas aquellas posibilidades en las que puede ocurrir la inyecci\u00f3n de SQL y debemos manejarlas en consecuencia.<\/p>
As\u00ed es como se ve la inyecci\u00f3n SQL:<\/p>
Empleado.all(:condiciones => "designaci\u00f3n = #{params[:designaci\u00f3n]}")<\/code><\/pre>
El c\u00f3digo anterior es vulnerable a la inyecci\u00f3n de SQL, el siguiente c\u00f3digo evitar\u00e1 la inyecci\u00f3n de SQL.<\/p>
Empleado.all(:condiciones => ['designaci\u00f3n =?', par\u00e1metros[:designaci\u00f3n]])<\/code><\/pre>
O<\/p>
Empleado.all(:condiciones => {:designaci\u00f3n => par\u00e1metros[:designaci\u00f3n]})<\/code><\/pre>
Contramedidas contra la inyecci\u00f3n SQL en Rails<\/strong><\/h5>
Probar cada declaraci\u00f3n para inyecci\u00f3n SQL puede ser un trabajo tedioso, pero debemos tomar algunas contramedidas, como un esc\u00e1ner de c\u00f3digo est\u00e1tico como un guardafrenos, y usted puede escribir algunos casos de prueba unitaria.
a)Regla general:<\/strong>\u2013 Nunca uses par\u00e1metros en la inflexi\u00f3n de cuerdas (#{}) as\u00ed
P.ej<\/p>
Usuario.donde("nombre = '#{params[:nombre]}'")<\/code><\/pre>
b)Cuidado que los par\u00e1metros tambi\u00e9n pueden ser una matriz, por ejemplo:<\/strong><\/p>
params[:user] si agrega ?user[]=1 a la URL. \u00bfEl usuario existe? params[:usuario] luego ejecutar\u00e1 la consulta SELECCIONAR 1 COMO uno DE \u201cusuarios\u201d DONDE (1) LIMITAR 1.<\/p>
4]Secuencias de comandos entre sitios (XSS)<\/strong><\/h3>
Con la ayuda de XSS, un atacante puede ejecutar scripts en el contexto de seguridad de su aplicaci\u00f3n web.<\/p>
Considere este fragmento de vista de Rails: <%= @flat.title %>. Si el t\u00edtulo del piso se edita junto con la adici\u00f3n del HTML, esta vista de Rails representa ese HTML en el contexto de seguridad de la aplicaci\u00f3n. Por lo tanto, el navegador ejecutar\u00e1 HTML, que es XSS.<\/p>
De hecho, esto no funciona en Rails hoy en d\u00eda todav\u00eda, en Rails versi\u00f3n 2 se le pedir\u00eda escapar de cada entrada del usuario: <%= h(@flat.title) %>
Hoy en d\u00eda, 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\u00e1metro, de la base de datos,\u2026), se escapar\u00e1 autom\u00e1ticamente al usarlo de esta manera: <%= @flat.title %>
En Rails 3.0, la protecci\u00f3n contra XSS es un comportamiento predeterminado.<\/p>
Contramedidas<\/strong><\/h3>
a) Una estrategia de Pol\u00edtica de seguridad de contenidos (CSP)<\/strong><\/p>
Una seguridad de contenido Pol\u00edtica<\/a> tiene b\u00e1sicamente la forma de un encabezado HTTP y esto hace una declaraci\u00f3n de las reglas sobre qu\u00e9 fuentes est\u00e1n permitidas para todo tipo de activos. Como consecuencia de seguir estas reglas, todo lo dem\u00e1s est\u00e1 prohibido. Una vez implementado correctamente, es capaz de eliminar todas las vulnerabilidades de Cross-Site-Scripting (XSS) en su aplicaci\u00f3n.<\/p>
b) HTML seguro, ActiveSupport::SafeBuffer<\/strong><\/p>
Rails 3 introdujo el m\u00f3dulo 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\u00e1metros. La bandera se devuelve con "string".html_safe?.<\/p>
El m\u00e9todo de escape HTML h() escapa de la cadena que marca una cadena como segura para HTML.<\/p>
h("html>").html_safe? #=> verdadero ("html>").html_safe? #=>falso<\/code><\/pre>
c) Prevenci\u00f3n XSS OWASP (Proyecto de seguridad de aplicaciones web abiertas)<\/strong><\/p>
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).<\/p>
d) Protecci\u00f3n XSS en plantillas HAML<\/strong><\/p>
Al utilizar las plantillas Haml, en lugar de ERB, las cadenas se escapan autom\u00e1ticamente 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\u00e1ticamente. La notaci\u00f3n != en Haml funciona de la misma manera que <%= raw(\u2026) %> funciona en ERB, por lo que representa la versi\u00f3n sin escape.
Por defecto,<\/p>
=" enfatizado " != " enfatizado "<\/em><\/em><\/em><\/em><\/code><\/pre>
compila a:<\/p>
enfatizado<\/em> enfatizado<\/em><\/code><\/pre>
Por lo tanto, se debe tener cuidado al usar != en Haml y se debe asegurar que ning\u00fan dato del usuario quede sin escape.
A continuaci\u00f3n se presentan algunas medidas preventivas que se pueden tomar al desarrollar la aplicaci\u00f3n de rieles.<\/p>
1]Autenticaci\u00f3n<\/strong><\/h5>
Utilice dispositivo o gema Authlogic.
\u2013 Para habilitar la autenticaci\u00f3n, no olvide agregar -><\/p>
clase Controlador de proyecto < Controlador de aplicaci\u00f3n
filtro_antes: autenticar_usuario
\u2013 De forma predeterminada, Devise requiere solo 6 caracteres para una contrase\u00f1a. El m\u00ednimo se puede cambiar en: \/config\/initializers\/devise.rb
config.contrase\u00f1a_longitud = 8..128
\u2013 Puede cambiar la complejidad de la contrase\u00f1a agregando el siguiente c\u00f3digo en el modelo de usuario.<\/p>
validar: contrase\u00f1a_complejidad def contrase\u00f1a_complejidad si contrase\u00f1a.presente? y no contrase\u00f1a.match(\/\\A(?=.*[az])(?=.*[AZ])(?=.*\\d).+\\z\/) errores.add :contrase\u00f1a, "debe incluir al menos una letra min\u00fascula, una letra may\u00fascula y un d\u00edgito" final<\/code><\/pre>
2]Referencia directa insegura a objetos o navegaci\u00f3n forzada<\/strong><\/h5>
\u2013 Las aplicaciones Ruby on Rails utilizan una estructura de URL tranquila, lo que hace que las rutas utilizadas sean en su mayor\u00eda 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\u00edficamente. No existe tal tipo de protecci\u00f3n incorporada desde el principio en una aplicaci\u00f3n Vanilla Rails. Adem\u00e1s, se puede realizar manualmente a nivel del controlador.
\u2013 Utilice cancancan o pandit para control de acceso<\/p>
3] Asignaci\u00f3n masiva y par\u00e1metros s\u00f3lidos<\/strong><\/h5>
- clase Proyecto < ActiveRecord::Base attr_accessible :nombre, :admin fin<\/code><\/pre>
Seg\u00fan el ejemplo anterior, con el atributo admin accesible, lo siguiente podr\u00eda funcionar:
\u2013 curl -d \u201cproyecto[nombre]=triage&proyecto[admin]=1\u201d host:puerto\/proyectos
\u2013 config.active_record.whitelist_attributes = verdadero<\/p>
4]Redirecciones y reenv\u00edos<\/strong><\/h5>
\u2013 Es recomendable evitar el uso de redirecciones que utilizan par\u00e1metros
Por ejemplo:- \/\/www.example.com\/redirect?url=\/\/www.example_commerce_site.com\/checkout
\u2013 la protecci\u00f3n restrictiva es utilizar :only_path<\/p>
comenzar si ruta = URI.parse(params[:url]).ruta redirigir_a ruta finalizar URI de rescate::InvalidURIError redirecci\u00f3n_to '\/' fin<\/code><\/pre>
\u2013 Tener un hash de sitios aprobados y permitir que solo ellos sean redirigidos.<\/p>
5]Rutas de renderizado din\u00e1mico<\/strong><\/h5>
\u2013 Se debe tener cuidado al renderizar din\u00e1micamente cualquier vista en funci\u00f3n de alguna condici\u00f3n. Podr\u00eda provocar que se cargue la vista de administrador.<\/p>
6] Intercambio de recursos entre or\u00edgenes<\/strong><\/h5>
\u2013 Me gusta la carga de archivos.
\u2013 El sitio receptor debe restringir y permitir \u00fanicamente los dominios incluidos en la lista blanca y asegurarse de que las solicitudes tambi\u00e9n provengan \u00fanicamente de esos dominios.
\u2013 Configure tambi\u00e9n 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\u00eda primero para determinar si el sitio remoto o receptor permite el dominio solicitante.
\u2013 Se env\u00eda una solicitud POST. Una vez m\u00e1s, se debe configurar el encabezado para que la transacci\u00f3n se muestre como exitosa.<\/p>
7]Errores de l\u00f3gica empresarial<\/strong><\/h5>
\u2013 Las aplicaciones, independientemente de la tecnolog\u00eda en la que se basen, pueden contener errores de l\u00f3gica empresarial que tienden a provocar errores de seguridad. Puede resultar realmente complicado detectar estos errores de seguridad utilizando herramientas automatizadas. Pr\u00e1cticas como revisiones peri\u00f3dicas de los c\u00f3digos, programaci\u00f3n de pares y redacci\u00f3n de pruebas unitarias pueden ayudarle a evitar que surjan estos errores de seguridad.<\/p>
8]Archivos confidenciales<\/strong><\/h5>
A continuaci\u00f3n se muestran algunos archivos que debemos cuidar al desarrollar una aplicaci\u00f3n web.
\/config\/database.yml: puede contener credenciales de producci\u00f3n.
\/config\/initializers\/secret_token.rb: contiene un secreto utilizado para codificar las cookies de sesi\u00f3n.
\/db\/seeds.rb: puede contener datos semilla, incluido el usuario administrador de arranque.
\/db\/development.sqlite3: puede contener datos reales.<\/p>
9]Cifrado<\/strong><\/h5>
Ruby on Rails utiliza cifrado del sistema operativo. Casi nunca deber\u00edas escribir tus propias soluciones de cifrado.
Actualizar Rails y tener un proceso para actualizar dependencias.<\/p>
Herramientas para detectar problemas de seguridad en aplicaciones Rails<\/strong><\/h4>
  • Guardafrenos<\/li>
  • auditor\u00eda de paquetes<\/li>
  • C\u00f3digo hom\u00f3nimo::Amanecer<\/li>
  • Bastidor::Ataque<\/li>
  • Tar\u00e1ntula<\/li>
  • Cintur\u00f3n de herramientas Hakiri<\/li><\/ul>\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/div>\n\t\t\t\t\t<\/div>\n\t\t<\/section>\n\t\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t\t
    \n\t\t\t
    \n\t\t\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t
    Suscr\u00edbete para recibir las \u00faltimas actualizaciones<\/h2>\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
    \n\t\t\t\t
    \n\t\t\t\t\t\t\t
    \t\t\t\t\t