misconfiguration
10 статей с этим тегом
Публичный доступ к облачному хранилищу: почему данные могут утечь даже при включённом Block Public Access
Утечки из бакетов возникают из-за настройки, а не из-за атаки. Главная строка в документации: настройки блокировки публичного доступа не меняют существующие политики и ACL. Публичные настройки остаются под блокировкой, и если её снять, публичный доступ вернётся. Поэтому цель — не «блокировка включена», а «ничего не публично даже без блокировки». Включайте её на уровне аккаунта: политика бакета может дать кому-то право отключить блокировку на уровне бакета. И «публичным» AWS считает больше, чем обычно думают.
4 частые ошибки в безопасности: настройки по умолчанию, забытые сервисы, отсутствие мониторинга и излишнее доверие к проверке ввода
Инциденты возникают из небольшого набора повторяющихся схем, и их проще увидеть, если сортировать не по технологиям, а по убеждениям. Их четыре: настройки по умолчанию безопасны (ничего не настроили), неиспользуемое безвредно (ничего не закрыли), мы бы заметили (ничего не видно) и проверенный ввод безопасен (вводу доверили слишком многое). Чтобы это исправить, не нужны глубокие технические знания — нужна привычка проверять. Ниже — на что смотреть в каждом случае.
Безопасность 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) чек-лист самопроверки. Только защита — без шагов атаки.
Безопасность по фреймворкам — защита, специфичная для вашего стека
Какой бы фреймворк вы ни использовали, *типы* слабых мест, которые бьют атакующие, в основном одинаковы (контроль доступа, секреты, инъекции, CVE зависимостей, неверная настройка). Различаются лишь «опасные значения по умолчанию» каждого фреймворка и «место, которое чаще всего атакуют». Наш сайт даёт для каждого фреймворка ловушки по умолчанию и шаги харденинга. Начните с главы для того стека, который вы действительно используете.
Безопасность Laravel — справочник по продакшн-харденингу
Значения по умолчанию Laravel сильны; продакшн-инциденты приходят из конфигурации и эксплуатации. Это рабочий справочник: (1) чек-лист харденинга по приоритетам (P0–P2), (2) таблица опасных значений по умолчанию, (3) рекомендации по областям — секреты/APP_KEY, продакшн-конфигурация (APP_DEBUG/кеширование), авторизация (Policy/Gate, Mass Assignment), инъекции/вывод (привязка Eloquent, Blade), сессии/CSRF/cookie, загрузки, HTTPS/заголовки/ограничение частоты, CVE зависимостей Composer, и (4) чек-лист самопроверки. Только защита — без шагов атаки.
Безопасность Spring Boot — референс по продакшн-закалке
Spring Boot — стабильный фреймворк, но инциденты приходят из зависимостей, конфигурации и авторизации. Это рабочий референс: (1) чек-лист закалки по приоритету (P0–P2), (2) руководство по областям — CVE зависимостей (класса Log4Shell, судите по работающей версии), продакшн-конфиг и вынесенные наружу секреты, авторизация Spring Security (default-deny/method security/проверки владельца), сокращение экспозиции Actuator/управления, небезопасная десериализация, инъекции, заголовки/CSRF/сессия, SSRF, и (3) чек-лист самопроверки. Только защита — без шагов атаки.
Оставили файл с секретом в публичной директории? Проверьте свой webroot
Всё, что в вашем webroot, любой может скачать по URL. Забытый JSON с токеном/учётными данными, .env или резервная копия означают мгновенную утечку — и если он пришёл из общего шаблона, тот же файл лежит на каждом сайте. Исправление: кладите в публичную директорию только то, чем можно публично делиться, держите секреты вне webroot с правами 600, а найдя один — проверьте каждый сайт и хост.
Что такое подделка X-Forwarded-For (XFF): ошибка конфигурации доверенного прокси и защита
XFF — заголовок, подделываемый клиентом. Неразборчивый сканер помещает пробы инъекций в подделанный XFF, а настройка «доверять всем прокси (wildcard)» пропускает это. Краткосрочное исправление: санировать IP-заголовок на границе. Исправление первопричины: доверять только правильным прокси (или никаким). Нулевое воздействие всё равно оставило настройку для исправления.
Случай, когда .env в Laravel был доступен публично: ошибка размещения на шаред-хостинге и как её исправить
Причина: всё приложение сидело под веб-корнем; видимым должен быть только public/. Исправление в три шага — временная блокировка через .htaccess, смена ключей, реструктуризация — затем профилактика процессом.