access control
10 статей с этим тегом
Что такое OWASP Top 10 — эталонный список 10 главных рисков веб-приложений
OWASP Top 10 — список, который некоммерческая организация OWASP публикует раз в несколько лет, «самые критичные риски веб-приложений». Это общий язык для разработчиков и тех, кто эксплуатирует системы. Актуальная редакция (2021) начинается с нарушения контроля доступа, за ним идут инъекции, ошибки конфигурации, уязвимые и устаревшие компоненты, сбои аутентификации и другое. Это КАТЕГОРИИ рисков, а не отдельные эксплойты — используйте их как оптику для аудита своего приложения.
Что такое PCI DSS — стандарт безопасности для работы с данными платёжных карт
PCI DSS (Payment Card Industry Data Security Standard) — международный стандарт для бизнеса, который хранит, обрабатывает или передаёт данные карт. Его задают карточные бренды, и он требует защиты сети, шифрования хранимых данных, контроля доступа по принципу наименьших привилегий, мониторинга/логирования и управления уязвимостями. На практике самый безопасный шаг — не хранить номера карт у себя: передать обработку совместимому платёжному провайдеру (токенизация) и сузить область применения.
Безопасность 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) чек-лист самопроверки. Только защита — без шагов атаки.
Безопасность 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) чек-лист самопроверки. Только защита — без шагов атаки.
Безопасность 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) чек-лист самопроверки. Только защита — без шагов атаки.
Безопасность Express (Node.js) — референс по продакшн-закалке
Express минималистичен — по умолчанию он почти ничего не защищает, поэтому защиту вы добавляете сами. Это рабочий референс: (1) чек-лист закалки по приоритету (P0–P2), (2) руководство по областям — заголовки безопасности (helmet) + отключение x-powered-by, CVE зависимостей npm, валидация ввода и инъекции (SQL/NoSQL операторная), аутентификация и авторизация по владельцу, ограничение частоты и лимиты размера, сессии/cookie/CSRF, SSRF, продакшн-обработка ошибок (без экспозиции stack), NODE_ENV, и (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 и прочитать чужой счёт или персональные данные — нарушение контроля доступа. Реальная защита: на сервере при каждом доступе проверять, разрешён ли вошедшему пользователю этот объект. Трудноугадываемые идентификаторы — не решение.