Пентест и аудит 2026-10-07 8 мин ЧТЕНИЯ

Проверка сайта на безопасность: 7 главных дыр, через которые уводят данные

Разбор семи критических уязвимостей современных веб-сайтов, приводящих к утечкам клиентских баз и перехвату управления. Примеры эксплойтов, уязвимого кода и готовые патчи для защиты.

S Автор: Команда Site Check Security

Подавляющее большинство резонансных инцидентов с утечками баз данных и компрометацией веб-сервисов происходят не из-за изощренных атак спецслужб или неизвестных 0-day уязвимостей. В 9 случаях из 10 злоумышленники проникают в инфраструктуру через элементарные огрехи конфигурации и архитектуры: забытые тестовые эндпоинты, открытые порты СУБД, небезопасные заголовки CORS или отсутствие параметризации SQL-запросов, эксплуатация которых занимает менее минуты.

Когда персональные данные клиентов или финансовые транзакции попадают в открытый доступ, бизнес мгновенно сталкивается с миллионными штрафами регуляторов, блокировками платежных шлюзов и катастрофической потерей доверия аудитории. Проведение точечного аудита по этим семи векторам риска — первоочередной шаг для любого веб-проекта перед запуском коммерческого трафика.

1. Дыра №1: Публично доступные конфигурационные файлы (.env, .git)

Оставленные в корне веб-сервера файлы .env или папки репозитория .git — классическая катастрофа. Автоматические сканеры злоумышленников непрерывно перебирают пути /.env, /.git/config и /docker-compose.yml по всему диапазону IPv4. Если веб-сервер отдает эти файлы, злоумышленник за секунды получает мастер-пароль к боевой базе данных, приватные ключи платежных шлюзов и секреты JWT.

Блокировка доступа к конфигурационным и архивным файлам в Nginx
                  # Запрет доступа ко всем служебным файлам и репозиториям в Nginx
location ~* /\.(env|git|svn|htaccess|docker|aws) {
    deny all;
    access_log off;
    return 404;
}

location ~* \.(bak|config|sql|dump|old)$ {
    deny all;
    return 404;
}
                

2. Дыра №2: Открытые наружу порты СУБД (PostgreSQL, MongoDB, Redis)

Развертывание баз данных с биндингом на 0.0.0.0 вместо 127.0.0.1 или приватной подсети VPC открывает порты 5432 (Postgres), 27017 (Mongo) или 6379 (Redis) для всего интернета. Ботнеты проводят брутфорс учетных записей или мгновенно шифруют базы вымогательскими скриптами.

Обратите внимание: Redis, запущенный без пароля на публичном порту, позволяет удаленному атакующему с помощью команд config set dir и config set dbfilename записать собственный публичный ключ SSH в /root/.ssh/authorized_keys и получить мгновенный root-доступ к серверу.

3. Дыра №3: Нарушение контроля доступа на уровне объектов (BOLA / IDOR)

Если API возвращает данные заказа по прямому идентификатору (например, GET /api/orders/9482) и не проверяет, принадлежит ли этот заказ авторизованному в текущей сессии пользователю, атакующий напишет скрипт с инкрементом чисел и выгрузит всю базу клиентов. Каждая выборка из базы обязана содержать фильтр по ID текущего пользователя или организации.

4. Дыра №4: Избыточно разрешающая политика CORS

Разработчики, устав бороться с ошибками CORS на фронтенде, часто включают Access-Control-Allow-Origin: * совместно с Access-Control-Allow-Credentials: true. В результате любой сторонний фишинговый сайт, открытый пользователем в соседней вкладке, может отправлять AJAX-запросы к вашему API от имени жертвы и считывать конфиденциальные ответы.

Безопасная валидация источников в Express.js
                  // Безопасная настройка CORS со строгим белым списком доменов
import cors from 'cors';

const allowedOrigins = ['https://site-check.velar.plus', 'https://app.velar.plus'];

app.use(cors({
  origin: (origin, callback) => {
    if (!origin || allowedOrigins.includes(origin)) {
      callback(null, true);
    } else {
      callback(new Error('Заблокировано политикой CORS'));
    }
  },
  credentials: true,
  methods: ['GET', 'POST', 'PUT', 'DELETE'],
}));
                

5. Дыра №5: SQL-инъекции через конкатенацию строк в запросах

Прямая склейка пользовательского ввода с SQL-запросом остается в топе рисков OWASP. Любой ввод из query-параметров или тела POST-запроса обязан обрабатываться исключительно через подготовленные параметризованные выражения (Prepared Statements) или проверенные ORM (Prisma, Drizzle, TypeORM).

6. Дыры №6 и №7: Отсутствие защитных флагов у Cookie и подробный вывод ошибок

Установка сессионных кук без флагов HttpOnly (защита от кражи через XSS), Secure (передача только по HTTPS) и SameSite=Lax (защита от CSRF) ставит под угрозу аккаунты всех пользователей. А вывод стектрейсов ошибок сервера с паролями БД на статус 500 предоставляет атакующему готовую карту уязвимостей системы.

Чек-лист безопасности для разработчика

  • ✓ Заблокировать в Nginx отдачу файлов /.env, /.git и резервных копий .sql/.bak
  • ✓ Привязать порты Postgres, Mongo и Redis строго к локальному интерфейсу 127.0.0.1
  • ✓ Проверить все API-эндпоинты на предмет IDOR: пользователь видит только свои данные
  • ✓ Заменить wildcard (*) в заголовках CORS на строгий белый список доменов
  • ✓ Убедиться, что сессионные cookie имеют флаги HttpOnly, Secure и SameSite
  • ✓ Отключить подробный вывод стектрейсов ошибок в продакшене

Резюме и ключевые выводы аудитора безопасности

При запуске веб-сервисов и приложений на базе современных фреймворков (Next.js, Astro, React, Supabase) безопасность периметра не должна быть второстепенным этапом. Более 85% утечек конфиденциальных данных и взломов баз данных происходят не из-за изощрённых уязвимостей нулевого дня (0-day), а по причине тривиальных ошибок конфигурации: забытых тестовых эндпоинтов, открытых файлов окружения, некорректных правил CORS и отсутствия строгих политик разграничения доступа (RLS).

Регулярный превентивный аудит внешнего контура с помощью Site Check позволяет обнаружить опасные сигнатуры за считанные секунды и закрыть векторы атак до того, как они попадут в поле зрения автоматизированных ботнетов.