access control
10 artículos con esta etiqueta
Qué es el OWASP Top 10 — la lista estándar de los 10 mayores riesgos de las aplicaciones web
El OWASP Top 10 es una lista que la organización sin ánimo de lucro OWASP publica cada pocos años con los 'riesgos más críticos de las aplicaciones web'. Es un lenguaje común para desarrolladores y responsables de operación. La edición actual (2021) la encabeza el control de acceso roto, seguido de la inyección, la configuración incorrecta, los componentes vulnerables y obsoletos, los fallos de autenticación y más. Son CATEGORÍAS de riesgo, no exploits individuales — úsalas como lente para auditar tu propia aplicación.
Qué es PCI DSS — el estándar de seguridad para manejar datos de tarjetas de crédito
PCI DSS (Payment Card Industry Data Security Standard) es el estándar internacional para los negocios que almacenan, procesan o transmiten datos de tarjeta. Establecido por las marcas de tarjetas, exige protección de la red, cifrado de los datos almacenados, control de acceso con mínimo privilegio, monitorización/registro y gestión de vulnerabilidades. En la práctica, lo más seguro es no guardar tú mismo los números de tarjeta — deja el procesamiento a un proveedor de pagos conforme (tokenización) y reduce tu alcance.
Seguridad en Django — una referencia de endurecimiento para producción
Django viene «con pilas incluidas» y valores por defecto seguros (ORM, CSRF, autoescapado, auth), pero los incidentes vienen de la configuración. Esta es una referencia de trabajo: (1) una lista de endurecimiento ordenada por prioridad (P0–P2), (2) guía por área — DEBUG=False + ALLOWED_HOSTS, externalizar SECRET_KEY, CVE de dependencias pip, configuración de seguridad de producción (SECURE_SSL_REDIRECT/HSTS/SESSION_COOKIE_SECURE, etc.), autorización (alcance de propietario), inyección y salida (raw/extra, mark_safe), CSRF/sesiones/admin, SSRF/subidas, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.
Seguridad de Laravel — una referencia de hardening para producción
Los valores por defecto de Laravel son sólidos; los incidentes de producción vienen de la configuración y la operación. Esta es una referencia de trabajo: (1) un checklist de hardening ordenado por prioridad (P0–P2), (2) una tabla de valores por defecto peligrosos, (3) guía por área — secretos/APP_KEY, config de producción (APP_DEBUG/caché), autorización (Policy/Gate, Mass Assignment), inyección/salida (binding de Eloquent, Blade), sesiones/CSRF/cookies, subidas de archivos, HTTPS/cabeceras/limitación de tasa, CVE de dependencias de Composer, y (4) un checklist de autoverificación. Solo defensivo — sin pasos de ataque.
Seguridad de Next.js — una referencia de endurecimiento para producción
Los valores por defecto de Next.js son bastante seguros, pero los incidentes ocurren en la frontera servidor/cliente. Esta es una referencia de trabajo: (1) una lista de verificación de endurecimiento ordenada por prioridad (P0–P2), (2) guía por área — la frontera y las variables de entorno (NEXT_PUBLIC_), los CVE de dependencias (incluido RCE del núcleo), autorización + validación de entrada en Server Actions / Route Handlers, SSRF en las peticiones del lado servidor, cabeceras de seguridad/CSP, autenticación/sesión/cookies, limitación de tasa, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.
Seguridad en ASP.NET Core — una referencia de endurecimiento para producción
ASP.NET Core es una base madura y sólida, pero los incidentes vienen de la configuración. Esta es una referencia de trabajo: (1) una lista de endurecimiento ordenada por prioridad (P0–P2), (2) guía por área — no exponer errores detallados / la Developer Exception Page en producción, externalizar secretos (User Secrets/env/Key Vault), CVE de dependencias NuGet, autorización ([Authorize], denegación por defecto de reserva, basada en recurso/propietario), over-posting (DTOs/[Bind]), deserialización insegura (evitar BinaryFormatter), HTTPS/cabeceras/antiforgery, SSRF, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.
Seguridad de Express (Node.js) — una referencia de hardening para producción
Express es minimalista — casi no protege nada por defecto, así que las defensas las añades tú. Esta es una referencia práctica: (1) una lista de comprobación de hardening ordenada por prioridad (P0–P2), (2) guía por área — cabeceras de seguridad (helmet) + desactivar x-powered-by, CVE de dependencias npm, validación de entrada e inyección (SQL/operador NoSQL), autenticación y autorización acotada al propietario, limitación de tasa y topes de tamaño, sesiones/cookies/CSRF, SSRF, manejo de errores en producción (sin exponer la pila), NODE_ENV, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.
Seguridad en Ruby on Rails — una referencia de endurecimiento para producción
Rails trae convenciones y valores por defecto seguros (protección CSRF, Strong Parameters, un ORM), pero los incidentes de producción vienen de la operación. Esta es una referencia de trabajo: (1) una lista de endurecimiento ordenada por prioridad (P0–P2), (2) guía por área — secretos y credentials (master key/secret_key_base), configuración de producción (force_ssl, sin exposición de excepciones), CVE de gems, Strong Parameters/Mass Assignment, autorización (Pundit, alcance de propietario), inyección y métodos peligrosos (interpolación en where/send/constantize), sesiones/cookies/CSRF, SSRF/subidas, y (3) una lista de autoverificación. Solo defensiva — sin pasos de ataque.
¿Añadiste un inicio de sesión y lo llamaste seguro? — autenticación frente a autorización
Autenticación = verificar quién es alguien; autorización = decidir qué puede hacer. Son cosas distintas, y añadir un inicio de sesión no es autorización. Sin acotar los datos al propietario (user_id), 'con sesión iniciada = ve todos los datos' — el Broken Access Control número uno de OWASP. Añade encima un scaffold con registro abierto y un desconocido puede darse de alta y entrar. Defensas: acota cada consulta al propietario, cierra el registro que no necesites, defensa en profundidad, registros de auditoría/acceso antes de un incidente, detecta nuevas altas.
Qué es IDOR: ver los datos de otra persona con solo cambiar un ID
IDOR permite a un usuario cambiar ?id=124 por 125 y leer la factura o los datos personales de otra persona: control de acceso roto. La defensa real: en el servidor, comprobar en cada acceso si el usuario con sesión iniciada tiene permitido ese objeto. Los IDs difíciles de adivinar no son un arreglo.