La seguridad con ejemplos de la vida real siempre es más interesante.
Como probador de penetración, me encanta cuando entran proyectos basados en marcos de desarrollo rápido, como Ruby-on-Rails, Django, AdonisJs, Express, etc. Le permiten construir un sistema muy rápidamente debido al hecho de que los modelos de negocios saltan inmediatamente a todos los niveles, incluido el navegador del cliente. Model (modelos de objetos de negocio en la base de datos) y ViewModel (contrato para interactuar con los clientes) tales marcos a menudo se combinan para evitar cambios innecesarios de Model a ViewModel y viceversa, los servicios REST se generan automáticamente. Desde el punto de vista del desarrollo, simplemente puede desarrollar un modelo de negocio en el servidor y luego usarlo inmediatamente en el cliente, lo que sin duda aumenta la velocidad de desarrollo.
Una vez más, no estoy diciendo que los marcos antes mencionados sean malos, o que algo esté mal con ellos, tienen los medios y las herramientas para una protección adecuada, es solo que los desarrolladores cometen la mayoría de los errores con ellos. Esto también se vio en un proyecto ASP.NET MVC, en el que los desarrolladores hicieron las mismas vulnerabilidades al exponer Modelos en lugar de ViewModels ...
Vulnerabilidad: debido a la débil validación de los campos de los modelos entrantes del cliente, puede inyectar campos que no son provistos por la funcionalidad, pero que están en el modelo de negocio. Por ejemplo, hay un método que le permite cambiar solo el nombre de usuario y devuelve un objeto de perfil de usuario. ¿Qué sucede si copio el objeto devuelto, cambio todas las propiedades en él y lo envío nuevamente a la entrada? Puede resultar que puede cambiar cualquier propiedad del objeto (contraseña, rol), sin pasar por el flujo de trabajo estándar.
De los diversos proyectos que probamos para seguridad, daré ejemplos reales. Se han solucionado todas estas áreas problemáticas y se oculta cualquier información adicional en las capturas de pantalla.
Sistema 1En este sistema, solo se puede cambiar el nombre de usuario en el perfil. Pero al sustituir otro correo electrónico, pude cambiar el inicio de sesión del usuario. Además, las invitaciones a otros usuarios ahora dejaron este jabón.
Sistema 2En este ejemplo, un usuario simple logró cambiar el rol a administrador agregando el campo de roles, y mediante url / admin simplemente abrió el panel de administración del sistema con todas las transacciones, usuarios, informes, etc.
Sistema 3En este sistema, fue posible renovar una suscripción gratuita por un período indefinido. Está claro que el enfoque estándar requería que hubiera un pago.
El método de entrada tomaría, al parecer, solo el color seleccionado de acuerdo con la marca del espacio de trabajo y devolvería el objeto de todo el espacio de trabajo, incluido un volcado completo del objeto StripeCustomer, que reflejó el pago. Fue posible insertar no solo un campo, sino un enorme sub-objeto StripeCustomer, y como resultado, haber pagado una vez, o desde otro usuario, capturar este objeto y duplicarlo en todos sus espacios de trabajo.
Sistema 4Y finalmente Este sistema tenía el mismo problema: era posible cambiar la contraseña y la contraseña sin pasar por el flujo de trabajo inventado. La falta de protección contra CSRF y el almacenamiento de cookies de autenticación durante un largo período aumentaron el riesgo de esta vulnerabilidad al cielo. Un usuario malintencionado podría colocar una secuencia de comandos en un recurso popular con una solicitud para cambiar la contraseña del usuario actual de este sistema, y todos los usuarios que abrirían este recurso perderían el acceso al sistema.
Ocultar en el código del servidor en los metadatos para este campo, esto hizo posible no devolver este campo al cliente en la respuesta, pero este campo se procesó sin problemas en los datos de entrada.
El mensaje:- Nunca confíes en los datos entrantes de los usuarios, pueden hacer cualquier cosa con ellos.
- Tenga cuidado con los sistemas que no tienen una capa ViewModel-s separada y trabaje directamente con los modelos base
- Explore con más detalle las protecciones que ofrece su marco.
La información anterior se proporciona solo con fines educativos y educativos, no es necesario cómo hacer sus sistemas.
Denis Koloshko, probador de penetración, CISSP