access control
16 artículos con esta etiqueta
Acceso no autorizado a la app Toypo (697.209 usuarios afectados, según Toypo): teléfonos, nombres y direcciones filtrados, y qué deben hacer los usuarios de apps de tiendas
Toypo Inc. confirmó el 4 de octubre de 2026 un acceso no autorizado de un tercero a su app de gestión de clientes, la app Toypo, y en un aviso fechado el 14 de octubre indicó que hay 697.209 usuarios afectados y que su información puede haberse filtrado. Una segunda página de aviso de Toypo, sin fecha y sin cifra de personas, afirma que la información se filtró. Desde el 13 de octubre la empresa contacta uno por uno a los afectados, también mediante notificaciones push en la app. Según la empresa, una parte de su sistema tenía un fallo de control de acceso que permitía a un usuario autenticado obtener información de otros usuarios a la que no tenía derecho, y sus registros muestran que un tercero lo usó para obtener información de usuarios. El fallo ya está corregido. La información que puede haberse filtrado es el número de teléfono y el ID de usuario o identificadores similares y, cuando están registrados, el nombre, el nombre en kana, el correo electrónico, la fecha de nacimiento, el género y la dirección. Según la empresa, no se incluyen contraseñas ni otras credenciales de acceso, números de tarjeta de crédito ni otros datos de pago, puntos, historial de visitas a tiendas ni historial de compras o uso, y los usuarios no necesitan cambiar la contraseña ni hacer nada más en la app. No se ha confirmado ningún daño secundario concreto. Ha informado a la Comisión de Protección de Información Personal. Se está organizando una evaluación de seguridad por un tercero. En los avisos de tiendas que usan la app, JR Kyushu Food Service indica que están afectados unos 26.900 de unos 61.500 miembros registrados, y Mannoya, 12 de los 212 miembros de su app oficial Kineya Mannoya. El contacto de Toypo es 0120-546-030 (días laborables de 9:00 a 18:00, hora de Japón; el centro de llamadas atiende hasta las 18:00 del 30 de octubre y después el contacto dentro de la app). Conclusión de este sitio: un mensaje que acierta con su número de teléfono y su nombre no es necesariamente auténtico. No use sus enlaces ni números; compruébelo mediante el contacto dentro de la app o el contacto que figura en el aviso.
Acceso no autorizado a Commune (166.505 registros de miembros, contados por comunidad): se filtraron datos de miembros de comunidades corporativas — qué deben hacer los miembros y los operadores
El 9 de octubre de 2026, Commune Inc. anunció que sus servicios de comunidades para empresas, Commune y Commune for Work, fueron accedidos sin autorización por un tercero externo, y que los datos de miembros de algunas comunidades se filtraron. Las filtraciones ocurrieron desde aproximadamente las 18:00 del 5 de octubre hasta aproximadamente las 21:00 del 6 de octubre, y desde las 13:17 hasta las 14:36 del 7 de octubre (hora de Japón). Su primer aviso indicó unos 307.000 miembros (estimación de personas únicas) como máximo posiblemente afectado. En un seguimiento del 21 de octubre, tras una investigación detallada, confirmó que 166.505 miembros resultaron afectados (el total de identificadores de miembro contados por comunidad, de modo que las personas en varias comunidades se cuentan una vez por cada una; incluye comunidades gestionadas por la empresa y comunidades de prueba o demostración, y excluye cuentas creadas por el atacante), y que 125.601 de ellos tenían datos que incluían direcciones de correo electrónico filtradas. En el resto, los datos filtrados incluyen nombres visibles, perfiles y pertenencias a grupos privados. A 144 miembros se les cambió la contraseña por una temporal sin su acción. No se confirmó la filtración de las propias contraseñas ni de mensajes directos, y la empresa no conserva datos de pago. Atribuye el incidente a enlaces de invitación de comunidades privadas obtenidos de forma ilegítima y a la suplantación de administradores. Empresas clientes que gestionan comunidades en el servicio también han publicado avisos; JMAM dijo que los nombres, direcciones, edades y números de teléfono de los perfiles de miembros de su comunidad Toki Labo también se filtraron. Para evitar el uso indebido de las direcciones de correo filtradas, Commune Inc. detuvo todas las comunidades por mantenimiento de emergencia desde las 00:50 del 10 de octubre y adoptó medidas como hacer obligatoria la autenticación de dos factores para las cuentas de administrador. El 16 de octubre anunció que las comunidades se reabrirían por fases, empezando por los clientes que lo soliciten, solo en la versión para navegador web y con algunas funciones restringidas (la aplicación, el nuevo registro con dirección de correo y el restablecimiento por «He olvidado mi contraseña» siguen no disponibles). Afirma que no se encontraron nuevos accesos no autorizados ni filtraciones durante el mantenimiento o las pruebas. El seguimiento del 21 de octubre también indica que la empresa presentó un informe preliminar ante el Ministerio de Asuntos Internos y Comunicaciones (Oficina Regional de Telecomunicaciones de Kanto) el 9 de octubre, ha comenzado a consultar a la policía, no encontró programas, cuentas ni configuraciones dejados por el atacante tras analizar todos los registros, y prepara una investigación forense por una organización externa. La opinión de este sitio: consulte el aviso de la empresa que gestiona su comunidad para saber si está afectado, y no abra enlaces de correos que aseguren provenir de la comunidad.
Filtración de datos de NewsPicks (nombres de titulares de tarjetas y últimos dígitos, hasta 362.000 registros): qué se filtró a través de una herramienta de administración interna y qué deben hacer los usuarios
El 8 de octubre de 2026, Uzabase, Inc. anunció que una herramienta de administración utilizada en la operación de su servicio de noticias NewsPicks había sido accedida sin autorización por un tercero, y que datos personales de algunos usuarios podrían haberse filtrado. Su segundo aviso, del 9 de octubre, indicó que la intrusión aprovechó una vulnerabilidad de esa herramienta y ofreció recuentos máximos estimados por cada elemento: parte de los datos de tarjeta usados para pagos en la web (nombre del titular y los últimos 3 o 4 dígitos del número de tarjeta, entre otros) 362.000; direcciones de correo electrónico 323.000; categoría de nivel de puesto 273.000; afiliación 65.000; nombres 59.000; y otros. La empresa afirma que los números completos de tarjeta y los códigos de seguridad nunca se almacenaron en sus sistemas y no se filtraron, y que no se ha confirmado ninguna filtración de contraseñas. No se ha confirmado ningún daño secundario. La opinión de este sitio: un mensaje que cita los últimos dígitos de su tarjeta o su empleador no demuestra que sea auténtico. No abra enlaces; verifique a través de la aplicación oficial o de un sitio oficial que abra usted mismo, y vigile los extractos de su tarjeta.
Filtración de datos de skyticket (Adventure Inc.) (unos 14,64 millones de registros): contraseñas, datos bancarios de reembolso y datos de tarjetas de algunos usuarios expuestos. Qué deben hacer hoy los usuarios
El 9 de octubre de 2026, Adventure Inc. anunció tres incidentes de acceso no autorizado separados, cada uno por una vía distinta, que afectaron a su sitio de comparación y reserva de viajes skyticket. En el primero, se utilizó indebidamente una función administrativa como punto de partida para llegar a otros servidores y a datos almacenados en la nube; se filtraron unos 14,64 millones de registros, con nombres (también escritos como figuran en el pasaporte), fechas de nacimiento, direcciones de correo electrónico, números de teléfono, direcciones y el nombre del remitente usado en las transferencias bancarias, y unos 4,13 millones incluían contraseñas de socios con hash. En el segundo, se explotó una vulnerabilidad en un sistema de gestión empresarial, y 17.780 registros (incluidos duplicados, y se siguen contando) que contenían datos de cuentas bancarias de reembolso se filtraron o podrían haberse filtrado. En el tercero, una página de finalización de reservas de autobús podía mostrarse sin iniciar sesión, y unas 12.000 reservas fueron o podrían haber sido vistas. La empresa afirmó primero que los números de tarjeta no estaban entre los datos filtrados, pero lo corrigió en un segundo aviso del 16 de octubre: el número de tarjeta, el nombre del titular y la fecha de caducidad (en algunos casos, solo el número; sin códigos de seguridad) de hasta 6.140 personas que se registraron o usaron una tarjeta de crédito para pagar la cuota de la membresía «skyticket Premium» entre febrero de 2017 y junio de 2018 se filtraron en el primer incidente, junto con los ID de socio, nombres y contraseñas de un servicio de prestaciones sociales ofrecido como ventaja de Premium. No se expusieron imágenes de pasaportes y, a fecha del aviso del 9 de octubre, el único perjuicio secundario confirmado fue un acceso no autorizado a una cuenta de socio (el segundo aviso no indica si los datos de tarjetas filtrados han sido utilizados indebidamente). La opinión de este sitio: los socios deben cambiar hoy su contraseña desde el sitio o la aplicación oficial, cambiarla en todos los servicios donde la reutilizaron, revisar los extractos de la tarjeta a partir de octubre si se registraron o usaron una tarjeta para la cuota Premium en ese periodo, ignorar los mensajes sobre reembolsos, compensaciones o cambios de reserva, y no dar nunca a nadie el PIN bancario ni un código de un solo uso.
Exposición pública del almacenamiento en la nube: cuando los datos pueden filtrarse aunque Block Public Access esté activado
Las filtraciones de buckets vienen de la configuración, no de un ataque. La frase clave de la documentación: los ajustes de bloqueo del acceso público no modifican las políticas ni las ACL existentes; los ajustes públicos siguen debajo del bloqueo y, si se quita el bloqueo, vuelve el acceso público. Por eso el objetivo no es «el bloqueo está activado», sino «nada es público aunque se desactive el bloqueo». Aplícalo a nivel de cuenta, porque una política de bucket puede dar a alguien la capacidad de desactivar el bloqueo a nivel de bucket. Y «público» se define de forma más amplia de lo que se suele pensar.
Vulnerabilidades en la subida de archivos: cómo evitar web shells y RCE desde el diseño
El problema de una vulnerabilidad de subida no es «recibir un archivo», sino dónde lo pones y si se puede ejecutar. Punto de subida sin autenticación + sin validación del tipo + guardado bajo la raíz web + scripts que se ejecutan ahí = web shell → RCE. Defiéndete por capas: (1) autenticación/permisos + CSRF en el punto de subida, (2) lista de permitidos en el servidor + inspección del contenido, (3) almacenamiento fuera de la raíz web (o ejecución desactivada), (4) nombres aleatorios y nunca confiar en rutas del usuario. No dependas de un solo control; ten algo que pueda detener el ataque en cada paso.
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 vigente de 2025 (anunciada en noviembre de 2025) la sigue encabezando el control de acceso roto; la configuración incorrecta de seguridad sube al segundo puesto y se añaden dos categorías nuevas: fallos en la cadena de suministro de software y gestión incorrecta de condiciones excepcionales. La SSRF se integró en el control de acceso roto. 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 ASP.NET Core — una referencia de endurecimiento para producción
ASP.NET Core es un framework maduro y estable, 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 en Django — una referencia de endurecimiento para producción
Django incluye muchos 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 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 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 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.
Autenticación frente a autorización: un inicio de sesión por sí solo no protege los datos de otros usuarios
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 el 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: un fallo que expone los datos de otras personas al 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 principal: 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.