access control
16 статей с этим тегом
Несанкционированный доступ к приложению Toypo (затронуты 697 209 пользователей, по данным Toypo): утекли номера телефонов, имена и адреса, и что делать пользователям приложений магазинов
Toypo Inc. подтвердила 4 октября 2026 года несанкционированный доступ третьей стороны к своему приложению для управления клиентами, приложению Toypo, а в уведомлении от 14 октября сообщила, что затронуты 697 209 пользователей и что их информация могла утечь. Вторая страница уведомления Toypo, без даты и без числа людей, говорит, что информация утекла. С 13 октября компания связывается с затронутыми по одному, в том числе через push-уведомления в приложении. По словам компании, в части её системы был изъян контроля доступа, позволявший аутентифицированному пользователю получать информацию других пользователей, на которую у него не было прав, и по журналам третья сторона использовала его для получения информации пользователей. Изъян устранён. Информация, которая могла утечь, — номер телефона и ID пользователя или похожие идентификаторы и, если указаны, имя, имя в каане, адрес электронной почты, дата рождения, пол и адрес. Пароли и другие данные для входа, номера кредитных карт и другие платёжные данные, баллы, история посещений магазинов и история покупок или использования не затронуты, говорит компания, и менять пароли или предпринимать другие действия в приложении не нужно. Конкретного вторичного ущерба не подтверждено. Компания сообщила в Комиссию по защите персональной информации. Готовится оценка безопасности третьей стороной. В уведомлениях магазинов, использующих приложение, JR Kyushu Food Service сообщает, что затронуты около 26 900 из около 61 500 зарегистрированных участников, а Mannoya — 12 из 212 участников официального приложения Kineya Mannoya. Контакт Toypo: 0120-546-030 (по будням 9:00–18:00 по японскому времени; колл-центр принимает звонки до 18:00 30 октября, затем — обращение через приложение). Вывод этого сайта: сообщение, в котором верно указаны ваш номер телефона и имя, не обязательно подлинное. Не пользуйтесь его ссылками и номерами; проверяйте через обращение в приложении или контакт из уведомления.
Несанкционированный доступ к Commune (166 505 записей участников, подсчитанных по сообществам): данные участников корпоративных сообществ утекли. Что должны сделать участники и операторы
9 октября 2026 года Commune Inc. сообщила, что её сервисы сообществ для бизнеса, Commune и Commune for Work, подверглись несанкционированному доступу со стороны постороннего лица, а данные участников некоторых сообществ утекли. Утечки происходили примерно с 18:00 5 октября до примерно 21:00 6 октября и с 13:17 до 14:36 7 октября (время Японии). В первом уведомлении назывались около 307 000 участников (оценка уникальных людей) как максимально возможное число затронутых. В дополнении от 21 октября, после подробного расследования, компания подтвердила, что затронуты 166 505 участников (сумма идентификаторов участников, подсчитанных по сообществам, поэтому люди, состоящие в нескольких сообществах, учтены по одному разу в каждом; сюда входят сообщества, которые ведёт компания, и тестовые и демонстрационные сообщества, а аккаунты, созданные злоумышленником, не учтены), и что 125 601 из них утекли данные, включая адреса электронной почты. У остальных утекли отображаемые имена, профили и данные о членстве в закрытых группах. У 144 участников пароли были без их действий изменены на временные. Утечка самих паролей или личных сообщений не подтверждена, а платёжных данных компания не хранит. Она связывает инцидент с незаконно полученными пригласительными ссылками на закрытые сообщества и с выдачей себя за администраторов. Компании-клиенты, которые ведут сообщества на этом сервисе, также опубликовали уведомления. JMAM сообщила, что в её сообществе Toki Labo также утекли имена, адреса, возраст и номера телефонов из профилей участников. Чтобы предотвратить злоупотребление утёкшими адресами электронной почты, Commune Inc. с 00:50 10 октября остановила все сообщества для экстренного техобслуживания и приняла меры, в том числе сделала двухфакторную аутентификацию обязательной для учётных записей администраторов. 16 октября компания объявила, что сообщества будут открываться поэтапно, начиная с клиентов, которые об этом просят, только в версии для веб-браузера и с некоторыми ограничениями функций (приложение, новая регистрация по адресу электронной почты и сброс пароля через «Забыли пароль» остаются недоступными). Она заявляет, что в ходе техобслуживания и тестирования не обнаружено нового несанкционированного доступа или утечки. В дополнении от 21 октября также говорится, что 9 октября компания подала предварительный отчёт в Министерство внутренних дел и коммуникаций Японии (Канто-бюро электросвязи), начала консультации с полицией, после анализа всех журналов не нашла программ, учётных записей или настроек, оставленных злоумышленником, и готовит криминалистическое расследование силами сторонней организации. Мнение этого сайта: проверьте уведомление компании, которая ведёт ваше сообщество, чтобы узнать, затронуты ли вы, и не открывайте ссылки в письмах, которые якобы пришли от сообщества.
Утечка данных NewsPicks (имена держателей карт и последние цифры, до 362 000 записей): что утекло через внутренний административный инструмент и что делать пользователям
8 октября 2026 года Uzabase, Inc. сообщила, что административным инструментом, который используется в работе новостного сервиса NewsPicks, без разрешения воспользовалось третье лицо, и что персональные данные некоторых пользователей могли утечь. В её втором уведомлении от 9 октября говорится, что вторжение использовало уязвимость в этом административном инструменте, и приводятся максимальные расчётные количества по каждой позиции: часть данных карт, используемых для платежей в интернете (имя держателя карты и последние 3 или 4 цифры номера карты и т. д.), 362 000; адреса электронной почты 323 000; категория уровня должности 273 000; принадлежность 65 000; имена 59 000; и другие. Компания заявляет, что полные номера карт и коды безопасности никогда не хранились в её системах и не утекли, а утечка паролей не подтверждена. Вторичный ущерб не подтверждён. Позиция этого сайта: сообщение, в котором указаны последние цифры вашей карты или ваш работодатель, не является доказательством его подлинности. Не открывайте ссылки, проверяйте через официальное приложение или сайт, который вы открываете сами, и следите за выписками по картам.
Утечка данных skyticket (Adventure Inc.) (около 14,64 млн записей): раскрыты пароли, банковские реквизиты для возврата и данные карт части пользователей. Что делать пользователям сегодня
9 октября 2026 года Adventure Inc. объявила о трёх отдельных случаях неправомерного доступа, каждый из которых произошёл по своему пути, затронувших сайт сравнения и бронирования путешествий skyticket. В первом случае административная функция была использована неправомерно и стала отправной точкой для доступа к другим серверам и данным, хранящимся в облаке. Утекло около 14,64 млн записей, включая имена (в том числе написанные как в паспорте), даты рождения, адреса электронной почты, номера телефонов, адреса и имя отправителя, указанное при банковских переводах. Около 4,13 млн из них содержали хешированные пароли участников. Во втором случае была использована уязвимость в системе управления бизнесом, и 17 780 записей (с учётом дубликатов, подсчёт продолжается) с реквизитами банковских счетов для возврата средств утекли или могли утечь. В третьем случае страница завершения бронирования автобуса могла открываться без входа в систему, и около 12 000 бронирований были или могли быть просмотрены. Компания сначала заявила, что номера карт не входили в утёкшие данные, но во втором уведомлении от 16 октября это было исправлено: номер карты, имя держателя и срок действия (у части людей только номер; коды безопасности не раскрыты) до 6 140 человек, которые зарегистрировали или использовали кредитную карту для оплаты членства «skyticket Premium» в период с февраля 2017 года по июнь 2018 года, утекли в первом случае вместе с идентификаторами участников, именами и паролями сервиса социальных выплат, который предоставлялся как бонус Premium. Изображения паспортов не раскрыты. По состоянию на уведомление от 9 октября единственным подтверждённым вторичным ущербом был один неправомерный вход в аккаунт участника (во втором уведомлении не сказано, использовались ли утёкшие данные карт). Позиция этого сайта: участникам следует сегодня сменить пароль на официальном сайте или в приложении, сменить его там, где он использовался повторно, проверить выписки по картам начиная с октября, если они регистрировали или использовали карту для оплаты Premium в этот период, игнорировать сообщения о возврате средств, компенсациях или изменении бронирований и никогда не сообщать никому PIN-код банковской карты или одноразовый код.
Публичный доступ к облачному хранилищу: почему данные могут утечь даже при включённом Block Public Access
Утечки из бакетов возникают из-за настройки, а не из-за атаки. Главная строка в документации: настройки блокировки публичного доступа не меняют существующие политики и ACL. Публичные настройки остаются под блокировкой, и если её снять, публичный доступ вернётся. Поэтому цель — не «блокировка включена», а «ничего не публично даже без блокировки». Включайте её на уровне аккаунта: политика бакета может дать кому-то право отключить блокировку на уровне бакета. И «публичным» AWS считает больше, чем обычно думают.
Уязвимости загрузки файлов: как предотвратить веб-шеллы и RCE на уровне архитектуры
Проблема уязвимости загрузки не в том, что сервер «принимает файл», а в том, куда его кладут и может ли он выполниться. Точка без аутентификации + нет проверки типа + хранение в корне сайта + там выполняются скрипты = веб-шелл → RCE. Защищайтесь слоями: (1) аутентификация/права + CSRF на точке загрузки, (2) белый список на сервере + проверка содержимого, (3) хранение вне корня сайта (или запрет выполнения), (4) случайные имена файлов, никакого доверия путям от пользователя. Не полагайтесь на одну меру: на каждом шаге должно быть что-то, что остановит атаку.
Что такое OWASP Top 10: эталонный список 10 главных рисков веб-приложений
OWASP Top 10 — список «самых критичных рисков веб-приложений», который некоммерческая организация OWASP публикует раз в несколько лет. Это общий язык для разработчиков и тех, кто эксплуатирует системы. Актуальную редакцию 2025 года (объявлена в ноябре 2025 года) по-прежнему возглавляет нарушение контроля доступа; ошибки конфигурации безопасности поднялись на второе место, и добавлены две новые категории: сбои цепочки поставок ПО и неправильная обработка исключительных ситуаций. SSRF вошла в категорию нарушения контроля доступа. Это КАТЕГОРИИ рисков, а не отдельные эксплойты, — используйте их как ракурс для аудита своего приложения.
Что такое PCI DSS: стандарт безопасности для работы с данными платёжных карт
PCI DSS (Payment Card Industry Data Security Standard) — международный стандарт для бизнеса, который хранит, обрабатывает или передаёт данные карт. Его задают карточные бренды, и он требует защиты сети, шифрования хранимых данных, контроля доступа по принципу наименьших привилегий, мониторинга/логирования и управления уязвимостями. На практике самый безопасный шаг — не хранить номера карт у себя: передать обработку совместимому платёжному провайдеру (токенизация) и сузить область применения.
Безопасность ASP.NET Core — справочник по продакшн-хардингу
ASP.NET Core — зрелый, стабильный фреймворк, но инциденты приходят из настроек. Это рабочий справочник: (1) приоритетный чек-лист хардинга (P0–P2), (2) руководство по областям — не раскрывать детальные ошибки / Developer Exception Page в проде, вынос секретов наружу (User Secrets/окружение/Key Vault), CVE зависимостей NuGet, авторизация ([Authorize], fallback запрет по умолчанию, ресурсная/владелец), over-posting (DTO/[Bind]), небезопасная десериализация (избегать BinaryFormatter), HTTPS/заголовки/antiforgery, SSRF, и (3) чек-лист самопроверки. Только защита — без шагов атаки.
Безопасность Django — справочник по продакшн-хардингу
В Django много безопасных значений по умолчанию (ORM, CSRF, авто-экранирование, auth), но инциденты приходят из настроек. Это рабочий справочник: (1) приоритетный чек-лист хардинга (P0–P2), (2) руководство по областям — DEBUG=False + ALLOWED_HOSTS, вынос SECRET_KEY наружу, CVE зависимостей pip, продакшн-настройки безопасности (SECURE_SSL_REDIRECT/HSTS/SESSION_COOKIE_SECURE и др.), авторизация (область владельца), инъекции и вывод (raw/extra, mark_safe), CSRF/сессии/admin, SSRF/загрузки, и (3) чек-лист самопроверки. Только защита — без шагов атаки.
Безопасность Express (Node.js) — референс по продакшн-закалке
Express минималистичен — по умолчанию он почти ничего не защищает, поэтому защиту вы добавляете сами. Это рабочий референс: (1) чек-лист закалки по приоритету (P0–P2), (2) руководство по областям — заголовки безопасности (helmet) + отключение x-powered-by, CVE зависимостей npm, валидация ввода и инъекции (SQL/NoSQL операторная), аутентификация и авторизация по владельцу, ограничение частоты и лимиты размера, сессии/cookie/CSRF, SSRF, продакшн-обработка ошибок (без экспозиции stack), NODE_ENV, и (3) чек-лист самопроверки. Только защита — без шагов атаки.
Безопасность Laravel — справочник по продакшн-харденингу
Значения по умолчанию Laravel сильны; продакшн-инциденты приходят из конфигурации и эксплуатации. Это рабочий справочник: (1) чек-лист харденинга по приоритетам (P0–P2), (2) таблица опасных значений по умолчанию, (3) рекомендации по областям — секреты/APP_KEY, продакшн-конфигурация (APP_DEBUG/кеширование), авторизация (Policy/Gate, Mass Assignment), инъекции/вывод (привязка Eloquent, Blade), сессии/CSRF/cookie, загрузки, HTTPS/заголовки/ограничение частоты, CVE зависимостей Composer, и (4) чек-лист самопроверки. Только защита — без шагов атаки.
Безопасность Next.js — практическая референс-инструкция по хардненингу продакшна
Значения по умолчанию у Next.js довольно безопасны, но инциденты случаются на границе сервер/клиент. Это рабочий референс: (1) приоритетный чек-лист хардненинга (P0–P2), (2) руководство по областям — граница и переменные окружения (NEXT_PUBLIC_), CVE зависимостей (включая RCE в ядре), авторизация Server Actions / Route Handlers + валидация ввода, SSRF на серверных запросах, заголовки безопасности/CSP, аутентификация/сессия/куки, ограничение частоты, и (3) чек-лист самопроверки. Только защита — без шагов атаки.
Безопасность Ruby on Rails — справочник по продакшн-хардингу
Rails поставляется с соглашениями и безопасными значениями по умолчанию (защита от CSRF, Strong Parameters, ORM), но продакшн-инциденты приходят из эксплуатации. Это рабочий справочник: (1) приоритетный чек-лист хардинга (P0–P2), (2) руководство по областям — секреты и credentials (master key/secret_key_base), продакшн-конфигурация (force_ssl, без раскрытия исключений), CVE gem'ов, Strong Parameters/Mass Assignment, авторизация (Pundit, область владельца), инъекции и опасные методы (интерполяция в where/send/constantize), сессии/cookie/CSRF, SSRF/загрузки, и (3) чек-лист самопроверки. Только защита — без шагов атаки.
Аутентификация и авторизация: один только вход не защищает данные других пользователей
Аутентификация — проверка того, кто вы; авторизация — решение о том, что вам можно делать. Это разные вещи, и добавить вход — не значит настроить авторизацию. Без привязки данных к владельцу (user_id) получается «вошёл = видит все данные» — Broken Access Control, которую OWASP ставит на первое место. Добавьте scaffold с открытой регистрацией — и посторонний сможет зарегистрироваться и получить доступ. Защита: привязывайте каждый запрос к владельцу, закрывайте ненужную регистрацию, стройте эшелонированную оборону, ведите аудит и логи доступа до инцидента, отслеживайте новые регистрации.
Что такое IDOR: уязвимость, раскрывающая чужие данные при изменении идентификатора
IDOR позволяет пользователю изменить ?id=124 на 125 и прочитать чужой счёт или персональные данные — нарушение контроля доступа. Основная защита: на сервере при каждом доступе проверять, разрешён ли вошедшему пользователю этот объект. Трудноугадываемые идентификаторы — не решение.