Por framework
Seguridad de Ruby on Rails — Strong Parameters, autorización y CVE de gems
Rails tiene valores por defecto seguros, pero los incidentes vienen de la operación: Strong Parameters demasiado permisivos (Mass Assignment), autorización débil y CVE de gems. Ajusta el permit, autoriza explícitamente, monitorea los CVE. Defensivo, sin pasos de ataque.
Para: cualquiera que ejecute una app de Ruby on Rails. Aquí no hay pasos de ataque, solo mantener funcionando los valores por defecto seguros mientras cierras los huecos que abre la operación. Para el panorama completo, consulta el centro de seguridad por framework.
Los tres grandes tropiezos (se abren cuando te sales de los valores por defecto)
Los valores por defecto de Rails son excelentes, pero estos tres son tuyos para protegerlos deliberadamente.
① Mass Assignment
Permite de forma demasiado amplia y is_admin, etc. se sobrescriben inesperadamente.
② Autorización débil
Autenticado pero sin ámbito de propietario. Un cambio de ID revela datos de otros (IDOR).
③ CVE conocidos de gems
Fallos de gems (dependencias) sin parchear. Juzga por la versión en ejecución, parchea rápido.
Vigila también la SQLi por interpolación de cadenas en where, pasar la entrada del usuario a métodos dinámicos peligrosos (send/constantize), y la fuga de credentials/secret_key_base.
Cómo cerrarlas (3 pasos)
Mantén Strong Parameters al mínimo
is_admin desde la entrada del usuario. Abandona el "permito de forma amplia porque es cómodo".Haz la autorización explícita
current_user y haz la política explícita con Pundit / CanCanCan. Comprueba la propiedad en cada lectura/actualización/borrado (→ qué es IDOR).Monitorea los CVE de gems (dependencias) y parchea rápido
where, nunca interpolación de cadenas.Común (peligroso)
- Strong Parameters permitidos de forma amplia (Mass Assignment)
- sin autorización — "con sesión = puede ver"
- CVE conocidos de gems sin parchear
where("... #{params}")interpolación de cadenas
Correcto
- permit mantenido al mínimo
- autorización explícita (current_user/Pundit)
- gems con CVE monitoreados + parcheados rápido
wherecon marcadores de posición
La visión de este sitio: aunque las convenciones protejan, la autorización y las dependencias corren de tu cuenta
Los buenos valores por defecto de Rails borran mucho riesgo, pero la autorización — quién puede hacer qué — y la frescura de las dependencias son las dos cosas que un framework no puede proteger automáticamente. Los incidentes que seguimos viendo son menos ataques elaborados que del tipo "autenticado pero sin comprobación de propiedad". Así que el centro de gravedad es ajustar Strong Parameters, hacer explícita la autorización y monitorear los CVE de las gems. Por poco vistosos que sean, esos tres previenen la mayoría de los incidentes reales de Rails.
Sigue leyendo
- Centro: seguridad por framework · seguridad de Laravel (mismo MVC, forma de autorización similar)
- Práctica: el manual de respuesta a vulnerabilidades · monitorear los CVE de dependencias
- Glosario: qué es IDOR · qué es la inyección SQL
FAQ
Q¿Ruby on Rails es un framework seguro?
Rails sigue 'convención sobre configuración' y trae muchos valores por defecto seguros: la protección CSRF, Strong Parameters y la protección SQL basada en ORM son estándar. Usado correctamente es un framework sólido, pero salirse de los valores por defecto u omitir el trabajo necesario abre agujeros. Strong Parameters demasiado permisivos, autorización débil y CVE de gems (dependencias) sin parchear se repiten menos como problemas específicos de Rails que como problemas de la operación.
Q¿Qué debo vigilar con Strong Parameters?
Strong Parameters permite (permit) explícitamente qué campos aceptas, para prevenir el Mass Assignment (asignar en masa campos no deseados). El peligro es permitir de forma amplia por comodidad. Mantén los campos permitidos al mínimo y nunca dejes que un campo de privilegio como is_admin se asigne desde la entrada del usuario.
Q¿Por qué es peligroso 'si tienes la sesión iniciada, puedes verlo'?
Eso es autenticación sin autorización. Rails aporta el mecanismo de login (autenticación), pero si los datos pertenecen de verdad a ese usuario es una autorización específica de la app que debes escribir tú. Si omites acotar los recursos por current_user o hacer la política explícita con Pundit/CanCanCan, cambiar el ID en la URL puede revelar los datos de otro usuario (IDOR).