Тестирование безопасности для QA: От новичка до профи

Научитесь находить security-баги шаг за шагом — опыт в безопасности не требуется!

🎯 Для кого эта статья?

Эта статья создана для:

  • ✅ Полных новичков, которые никогда не занимались тестированием безопасности
  • ✅ QA инженеров, которые хотят добавить навыки безопасности
  • ✅ Разработчиков, интересующихся security-тестированием
  • ✅ Студентов, изучающих веб-безопасность

Никаких предварительных знаний не требуется! Мы объясним всё с нуля с помощью простых аналогий.

📍 Вы находитесь здесь:

[✓] Статья 1: Основы QA
[✓] Статья 2: Практика QA  
[✓] Статья 3: DSA для QA
[✓] Статья 4: Фреймворки автоматизации
[✓] Статья 5: CI/CD
[✓] Статья 6: Техники тест-дизайна
[✓] Статья 7: Нагрузочное тестирование
[✓] Статья 8: Работа в Apple
[→] Статья 9: Тестирование безопасности

Прогресс: 100% + Бонус ✨

🏠 Что такое тестирование безопасности? (Простое объяснение)

Представьте, что ваше приложение — это дом:

Часть домаВ приложенииУгроза
🚪 Входная дверьФорма входа (login)Взлом пароля
🪟 ОкнаAPI endpointsНесанкционированный доступ
🔐 СейфБаза данныхКража данных
📮 Почтовый ящикФормы вводаВнедрение вредоносного кода
🎥 КамерыЛогиОтслеживание злоумышленников

Тестирование безопасности = проверяем все “двери и окна” дома, чтобы убедиться, что злоумышленник не может войти! 🏠🔒

📚 Тестирование безопасности для абсолютных новичков

Шаг 1: Поймите базовые термины

ТерминПростое объяснениеПример из жизни
УязвимостьСлабое место, которое можно использоватьНезапертая дверь
ЭксплойтСпособ использовать уязвимостьВойти через незапертую дверь
АутентификацияПроверка “кто вы?”Показать паспорт
АвторизацияПроверка “что вам разрешено?”Пропуск в здание
ШифрованиеПревращение данных в нечитаемый кодСекретный язык
HTTPSЗащищённое соединениеБронированный фургон для данных
SQL-инъекцияВнедрение команд БД через вводПодделка документов
XSSВнедрение скриптов на страницуПодмена объявлений

Шаг 2: Три вещи, которые проверяют ВСЕ security-тестеры

1. 🔐 АУТЕНТИФИКАЦИЯ - Могу ли я войти без пароля?
2. 🎫 АВТОРИЗАЦИЯ - Могу ли я делать то, что мне запрещено?
3. 📝 ВВОД ДАННЫХ - Могу ли я сломать систему странным вводом?

Шаг 3: Ваш первый тест безопасности! 🎯

Попробуйте это на любом тестовом сайте (НИКОГДА на реальных сайтах без разрешения!):

Упражнение: Проверка контроля доступа

1. Создайте два аккаунта (Пользователь A и Пользователь B)
2. Войдите как Пользователь A
3. Найдите URL с ID (например: /profile/123 или /order/456)
4. Попробуйте изменить ID на другой номер
5. Если вы видите данные Пользователя B — вы нашли уязвимость! 🐛

🔟 OWASP Top 10 — Простыми словами

OWASP (Open Web Application Security Project) составил список из 10 самых опасных уязвимостей. Вот они простыми словами:

#НазваниеОбъяснение для 5-летнегоАналогия с домом
A01Нарушение контроля доступа”Я попал в чужую комнату!”Ключ от одной комнаты открывает все
A02Криптографические сбои”Секреты хранятся без шифра”Записка с паролем на холодильнике
A03Инъекции”Злые команды в текстовом поле”Записка “отдай все деньги” в почте
A04Небезопасный дизайн”Дом построили без замков”Архитектор забыл про двери
A05Неправильная конфигурация”Оставили ключ под ковриком”Стандартный пароль “admin”
A06Устаревшие компоненты”Старый сломанный замок”Замок 1950 года с YouTube-видео как открыть
A07Проблемы с идентификацией”Не проверили паспорт”Пустили всех без вопросов
A08Нарушение целостности”Кто-то подменил продукты”Отравленная еда из доставки
A09Отсутствие логирования”Нет камер наблюдения”Вор пришёл и ушёл незамеченным
A10Подделка запросов (SSRF)“Обманули слугу сделать плохое”Поддельный приказ от хозяина

📚 Хотите узнать больше? Смотрите Статья 10: OWASP Top 10 — Глубокое погружение для полного покрытия с лабораториями, реальными примерами и практическими упражнениями!

Почему QA инженеры должны знать тестирование безопасности

В современном мире безопасность — ответственность каждого. Как QA инженер, вы уже умеете находить баги — уязвимости безопасности это просто особая категория багов с серьёзными последствиями.

Почему это важно:

  • 🔓 Утечки данных стоят компаниям миллионы
  • 💼 Навыки безопасности увеличивают вашу рыночную стоимость на 30-50%
  • 🎯 Многие компании ожидают от QA базовых проверок безопасности
  • 🏆 Нахождение security-багов = высокий импакт

Часть 1: OWASP Top 10 - Подробнее

1. Нарушение контроля доступа (A01:2021)

Что это простыми словами: Представьте гостиницу, где ваш ключ от комнаты 101 вдруг открывает ВСЕ комнаты. Это — нарушение контроля доступа! 🏨

Что это технически: Пользователи могут получить доступ к ресурсам или выполнить действия, которые им недоступны.

Попробуйте сами (безопасное упражнение):

1. Зайдите на тестовый сайт и найдите URL с числом:
   https://example.com/profile/123
   
2. Попробуйте изменить число:
   https://example.com/profile/124
   https://example.com/profile/1
   
3. Если вы видите чужие данные — это IDOR уязвимость! 🐛

Как тестировать:

✓ Попробуйте получить доступ к данным других пользователей, изменяя ID в URL
✓ Тестируйте горизонтальную эскалацию привилегий (пользователь A → данные пользователя B)
✓ Тестируйте вертикальную эскалацию привилегий (пользователь → действия админа)
✓ Проверьте, можно ли обойти контроль доступа модификацией запросов

Примеры тест-кейсов:

# Тест: Может ли пользователь получить доступ к профилю другого пользователя?
# Оригинальный URL: /api/users/123/profile
# Изменяем на: /api/users/456/profile

# Тест: Может ли обычный пользователь получить доступ к админским эндпоинтам?
# Пробуем: /api/admin/users (как обычный пользователь)

# Тест: IDOR (Insecure Direct Object Reference)
def test_idor_vulnerability():
    # Логинимся как пользователь A
    response = client.get("/api/orders/1001")  # Заказ пользователя A
    assert response.status_code == 200
    
    # Пробуем получить доступ к заказу пользователя B
    response = client.get("/api/orders/1002")  # Заказ пользователя B
    assert response.status_code == 403  # Должно быть запрещено!

2. Криптографические сбои (A02:2021)

Что это простыми словами: Это как хранить пароль от сейфа на записке, приклеенной к сейфу. Данные есть, но защиты нет! 📝

Что это технически: Неспособность защитить конфиденциальные данные надлежащим шифрованием.

Как тестировать:

✓ Проверьте, передаются ли конфиденциальные данные по HTTPS
✓ Убедитесь, что пароли хешируются (не хранятся в открытом виде)
✓ Проверьте наличие конфиденциальных данных в URL, логах или сообщениях об ошибках
✓ Проверьте, используются ли старые/слабые алгоритмы шифрования

Чеклист:

ОбластьЧто проверять
HTTPSВсе страницы используют HTTPS, нет смешанного контента
ПаролиХешируются с bcrypt/Argon2, никогда не логируются
API ключиНе раскрываются в клиентском коде
CookiesУстановлены флаги Secure и HttpOnly
ЗаголовкиHSTS включён

3. Инъекции (A03:2021)

Что это: Недоверенные данные отправляются интерпретатору как часть команды или запроса.

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

  • SQL Injection - Запросы к базе данных
  • XSS - Скрипты в браузере
  • Command Injection - Команды ОС
  • LDAP Injection - Службы каталогов

Тест-кейсы SQL Injection:

-- Базовые payload'ы для тестирования SQL injection:
' OR '1'='1
' OR '1'='1' --
'; DROP TABLE users; --
' UNION SELECT username, password FROM users --

-- В полях поиска, формах логина, URL параметрах

Тестирование на практике:

# Тест формы логина на SQL injection
def test_sql_injection_login():
    payloads = [
        "' OR '1'='1",
        "admin'--",
        "' OR 1=1--",
        "1; DROP TABLE users",
    ]
    
    for payload in payloads:
        response = client.post("/login", data={
            "username": payload,
            "password": "anything"
        })
        # НЕ должен залогиниться с инъекцией
        assert "Welcome" not in response.text
        assert response.status_code != 200

4. Небезопасный дизайн (A04:2021)

Что это: Отсутствующие или неэффективные меры безопасности на этапе проектирования.

Как тестировать:

✓ Проверьте бизнес-логику на наличие уязвимостей
✓ Тестируйте ограничение частоты запросов на чувствительных операциях
✓ Проверьте отсутствующие требования безопасности
✓ Убедитесь, что было проведено моделирование угроз

Примеры сценариев:

Сценарий: Сброс пароля без верификации
  Допустим я запрашиваю сброс пароля для любого email
  Когда я получаю ссылку для сброса
  Тогда я НЕ должен иметь возможность сбросить пароль без доступа к email

Сценарий: Неограниченные попытки входа
  Допустим форма логина существует
  Когда я пробую 100 неправильных паролей
  Тогда аккаунт должен быть заблокирован или ограничен

5. Неправильная конфигурация безопасности (A05:2021)

Что это: Небезопасные конфигурации по умолчанию, незавершённые настройки или подробные сообщения об ошибках.

Как тестировать:

✓ Проверьте учётные данные по умолчанию
✓ Ищите ненужные включённые функции
✓ Убедитесь, что сообщения об ошибках не раскрывают информацию
✓ Проверьте заголовки безопасности

Чеклист заголовков безопасности:

# Необходимые заголовки безопасности
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
X-Frame-Options: DENY
Content-Security-Policy: default-src 'self'
X-XSS-Protection: 1; mode=block
Referrer-Policy: strict-origin-when-cross-origin

Тест с curl:

# Проверка заголовков безопасности
curl -I https://yoursite.com | grep -E "(Strict|X-Content|X-Frame|Content-Security|X-XSS)"

6. Уязвимые и устаревшие компоненты (A06:2021)

Что это: Использование библиотек, фреймворков или компонентов с известными уязвимостями.

Как тестировать:

# NPM проекты
npm audit

# Python проекты
pip-audit
safety check

# Проверка конкретных CVE
# Используйте Snyk, OWASP Dependency-Check или GitHub Dependabot

7. Ошибки идентификации и аутентификации (A07:2021)

Что это: Слабые механизмы аутентификации, позволяющие злоумышленникам компрометировать учётные записи.

Как тестировать:

✓ Тестируйте слабые политики паролей
✓ Проверьте управление сессиями (таймаут, инвалидация)
✓ Проверьте реализацию MFA
✓ Тестируйте функциональность "запомнить меня"
✓ Проверьте поток сброса пароля

Тест-кейсы:

def test_weak_password_allowed():
    # НЕ должен разрешать слабые пароли
    weak_passwords = ["123456", "password", "qwerty", "abc123"]
    
    for pwd in weak_passwords:
        response = client.post("/register", data={
            "username": "testuser",
            "password": pwd
        })
        assert "Слишком слабый пароль" in response.text

def test_session_fixation():
    # Получаем сессию до логина
    session_before = client.cookies.get('session_id')
    
    # Логинимся
    client.post("/login", data={"username": "user", "password": "pass"})
    
    # Сессия должна измениться после логина
    session_after = client.cookies.get('session_id')
    assert session_before != session_after

8. Нарушения целостности ПО и данных (A08:2021)

Что это: Код и инфраструктура, которые не защищают от нарушений целостности.

Как тестировать:

✓ Убедитесь, что обновления ПО приходят из доверенных источников
✓ Проверьте безопасность CI/CD пайплайна
✓ Тестируйте небезопасную десериализацию
✓ Проверьте цифровые подписи на обновлениях

9. Ошибки логирования и мониторинга (A09:2021)

Что это: Недостаточное логирование и мониторинг, позволяющие атакам оставаться незамеченными.

Как тестировать:

✓ Убедитесь, что неудачные попытки входа логируются
✓ Проверьте наличие алертов на события безопасности
✓ Тестируйте целостность логов (нет подделки)
✓ Убедитесь, что PII не логируется

Что должно логироваться:

СобытиеПриоритет
Неудачные попытки входаВысокий
Ошибки контроля доступаВысокий
Ошибки валидации вводаСредний
Действия администратораВысокий
Изменения пароляСредний

10. Подделка запросов на стороне сервера (SSRF) (A10:2021)

Что это: Приложение получает удалённый ресурс без валидации URL, предоставленного пользователем.

Как тестировать:

# Тест SSRF в полях ввода URL
ssrf_payloads = [
    "http://localhost/admin",
    "http://127.0.0.1:22",
    "http://169.254.169.254/latest/meta-data/",  # AWS metadata
    "file:///etc/passwd",
    "http://internal-server.local/",
]

def test_ssrf_prevention():
    for payload in ssrf_payloads:
        response = client.post("/fetch-url", data={"url": payload})
        assert response.status_code == 400
        assert "Неверный URL" in response.text

Часть 2: Основные техники тестирования безопасности

2.1 Тестирование валидации ввода

Золотое правило: Никогда не доверяйте пользовательскому вводу!

# Комплексный набор тестов валидации ввода
class TestInputValidation:
    
    # XSS Payload'ы
    xss_payloads = [
        "<script>alert('XSS')</script>",
        "<img src=x onerror=alert('XSS')>",
        "javascript:alert('XSS')",
        "<svg onload=alert('XSS')>",
        "'-alert('XSS')-'",
        "<body onload=alert('XSS')>",
    ]
    
    # SQL Injection Payload'ы
    sqli_payloads = [
        "' OR '1'='1",
        "1; DROP TABLE users--",
        "' UNION SELECT * FROM users--",
        "1' AND '1'='1",
    ]
    
    # Path Traversal Payload'ы
    path_payloads = [
        "../../../etc/passwd",
        "....//....//....//etc/passwd",
        "%2e%2e%2f%2e%2e%2f%2e%2e%2fetc/passwd",
    ]
    
    def test_xss_in_all_inputs(self, all_input_fields):
        for field in all_input_fields:
            for payload in self.xss_payloads:
                response = submit_form(field, payload)
                assert payload not in response.text
                assert html.escape(payload) in response.text or \
                       "Неверный ввод" in response.text

2.2 Тестирование аутентификации

class TestAuthentication:
    
    def test_brute_force_protection(self):
        """Тест работы блокировки аккаунта"""
        for i in range(10):
            response = login("admin", f"wrong_password_{i}")
        
        # Аккаунт должен быть заблокирован
        response = login("admin", "correct_password")
        assert "Аккаунт заблокирован" in response.text
    
    def test_password_complexity(self):
        """Тест требований к паролю"""
        weak_passwords = [
            ("short", "Слишком короткий"),
            ("alllowercase", "Нужна заглавная буква"),
            ("ALLUPPERCASE", "Нужна строчная буква"),
            ("NoNumbers!", "Нужна цифра"),
            ("NoSpecial123", "Нужен спецсимвол"),
        ]
        
        for password, expected_error in weak_passwords:
            response = register(password=password)
            assert expected_error in response.text
    
    def test_session_expiration(self):
        """Тест истечения сессии"""
        token = login_and_get_token()
        
        # Ждём истечения сессии (или мокаем время)
        time.sleep(SESSION_TIMEOUT + 1)
        
        response = access_protected_resource(token)
        assert response.status_code == 401

2.3 Тестирование авторизации (Контроль доступа)

class TestAuthorization:
    
    def test_horizontal_privilege_escalation(self):
        """Пользователь A не должен получить доступ к данным пользователя B"""
        # Логинимся как пользователь A
        token_a = login("user_a", "password_a")
        
        # Получаем заказ пользователя A
        response = get_order(token_a, order_id=100)  # Заказ пользователя A
        assert response.status_code == 200
        
        # Пробуем получить заказ пользователя B
        response = get_order(token_a, order_id=200)  # Заказ пользователя B
        assert response.status_code == 403
    
    def test_vertical_privilege_escalation(self):
        """Обычный пользователь не должен получить доступ к админским функциям"""
        user_token = login("regular_user", "password")
        
        admin_endpoints = [
            "/api/admin/users",
            "/api/admin/settings",
            "/api/admin/logs",
        ]
        
        for endpoint in admin_endpoints:
            response = client.get(endpoint, headers={"Authorization": user_token})
            assert response.status_code == 403
    
    def test_idor_in_api(self):
        """Тест Insecure Direct Object References"""
        user_token = login("user1", "password")
        
        # Должен получить доступ к своему профилю
        response = client.get("/api/users/1/profile", 
                             headers={"Authorization": user_token})
        assert response.status_code == 200
        
        # НЕ должен получить доступ к чужому профилю
        response = client.get("/api/users/2/profile",
                             headers={"Authorization": user_token})
        assert response.status_code == 403

2.4 Тестирование безопасности API

class TestAPISecurity:
    
    def test_rate_limiting(self):
        """API должен иметь ограничение частоты запросов"""
        responses = []
        for i in range(100):
            response = client.get("/api/search?q=test")
            responses.append(response.status_code)
        
        # Должны увидеть 429 (Too Many Requests) после лимита
        assert 429 in responses
    
    def test_api_versioning(self):
        """Старые версии API должны быть deprecated"""
        response = client.get("/api/v1/users")  # Старая версия
        assert response.status_code == 410  # Gone
    
    def test_sensitive_data_exposure(self):
        """API не должен раскрывать чувствительные поля"""
        response = client.get("/api/users/1")
        user_data = response.json()
        
        sensitive_fields = ["password", "ssn", "credit_card", "api_key"]
        for field in sensitive_fields:
            assert field not in user_data
    
    def test_mass_assignment(self):
        """Пользователи не должны устанавливать админские поля"""
        response = client.put("/api/users/1", json={
            "name": "John",
            "role": "admin",  # Должно игнорироваться
            "is_verified": True  # Должно игнорироваться
        })
        
        user = get_user(1)
        assert user["role"] != "admin"
        assert user["is_verified"] != True

Часть 3: Инструменты тестирования безопасности

3.1 Инструменты разработчика в браузере

Что можно найти:

  • Конфиденциальные данные в localStorage/sessionStorage
  • API ключи в JavaScript файлах
  • Небезопасные cookies (отсутствуют флаги Secure/HttpOnly)
  • Предупреждения о смешанном контенте
  • Нарушения CSP
// Проверка конфиденциальных данных в хранилище браузера
console.log("LocalStorage:", localStorage);
console.log("SessionStorage:", sessionStorage);
console.log("Cookies:", document.cookie);

// Проверка раскрытых API ключей в объекте window
Object.keys(window).filter(k => 
  k.toLowerCase().includes('key') || 
  k.toLowerCase().includes('token') ||
  k.toLowerCase().includes('secret')
);

3.2 Burp Suite (Необходимый инструмент)

Ключевые функции для QA:

  1. Proxy - Перехват и модификация запросов
  2. Repeater - Повтор и модификация запросов
  3. Intruder - Автоматизированное тестирование с payload’ами
  4. Scanner - Автоматическое обнаружение уязвимостей

Базовый рабочий процесс:

1. Настройте браузер на использование Burp прокси (127.0.0.1:8080)
2. Просматривайте приложение как обычно
3. Просмотрите запросы в Proxy > HTTP history
4. Отправьте интересные запросы в Repeater
5. Модифицируйте и повторяйте для тестирования уязвимостей

3.3 OWASP ZAP (Бесплатная альтернатива)

# Запуск ZAP в headless режиме для CI/CD
docker run -t owasp/zap2docker-stable zap-baseline.py \
  -t https://yoursite.com \
  -r report.html

3.4 Инструменты командной строки

# Nikto - Сканер веб-серверов
nikto -h https://yoursite.com

# SQLMap - Тестирование SQL injection
sqlmap -u "https://yoursite.com/search?q=test" --batch

# Nmap - Сканирование сети
nmap -sV -sC yoursite.com

# SSLyze - Тестирование SSL/TLS
sslyze yoursite.com

# Проверка заголовков безопасности
curl -I https://yoursite.com | grep -iE "strict|x-frame|x-content|csp|x-xss"

3.5 Автоматизированное тестирование безопасности в CI/CD

# Пример GitHub Actions
name: Security Tests

on: [push, pull_request]

jobs:
  security:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      
      # Сканирование зависимостей
      - name: Run npm audit
        run: npm audit --audit-level=high
      
      # SAST (Статический анализ)
      - name: Run Semgrep
        uses: returntocorp/semgrep-action@v1
      
      # DAST (Динамический анализ)
      - name: Run OWASP ZAP
        uses: zaproxy/action-baseline@v0.7.0
        with:
          target: 'https://staging.yoursite.com'
      
      # Сканирование секретов
      - name: Run Gitleaks
        uses: gitleaks/gitleaks-action@v2

Часть 4: Чеклист тестирования безопасности

Чеклист безопасности перед релизом

## Аутентификация и управление сессиями
- [ ] Применяется строгая политика паролей
- [ ] Блокировка аккаунта после неудачных попыток
- [ ] Реализован таймаут сессии
- [ ] Инвалидация сессии при выходе
- [ ] Безопасная генерация токенов сессии
- [ ] MFA доступен для чувствительных аккаунтов

## Авторизация
- [ ] Контроль доступа на основе ролей работает
- [ ] Нет горизонтальной эскалации привилегий
- [ ] Нет вертикальной эскалации привилегий
- [ ] API эндпоинты надлежащим образом защищены
- [ ] Админские функции ограничены

## Валидация ввода
- [ ] Все входные данные валидируются на сервере
- [ ] SQL injection протестирован и заблокирован
- [ ] XSS протестирован и заблокирован
- [ ] Ограничения на загрузку файлов установлены
- [ ] Path traversal заблокирован

## Защита данных
- [ ] HTTPS везде (нет смешанного контента)
- [ ] Конфиденциальные данные зашифрованы в покое
- [ ] Нет конфиденциальных данных в URL
- [ ] Пароли надлежащим образом хешируются
- [ ] PII не логируется

## Заголовки безопасности
- [ ] HSTS включён
- [ ] X-Content-Type-Options: nosniff
- [ ] X-Frame-Options: DENY
- [ ] Content-Security-Policy установлен
- [ ] Referrer-Policy настроен

## Обработка ошибок
- [ ] Общие сообщения об ошибках для пользователей
- [ ] Нет stack trace в продакшене
- [ ] Нет конфиденциальной информации в ошибках

## Зависимости
- [ ] Нет известных уязвимостей
- [ ] Зависимости обновлены
- [ ] Проверено соответствие лицензий

Часть 5: Примеры реальных багов безопасности

Пример 1: IDOR в интернет-магазине

Баг: Детали заказа раскрываются через предсказуемые URL
Серьёзность: Высокая
URL: /api/orders/12345

Шаги воспроизведения:
1. Залогиньтесь как пользователь A
2. Посмотрите свой заказ: /api/orders/100
3. Измените URL на: /api/orders/101 (заказ другого пользователя)
4. Наблюдайте: Видны детали чужого заказа

Импакт: Любой аутентифицированный пользователь может просмотреть любой заказ,
        раскрывая личные данные, адреса, платёжную информацию

Исправление: Проверять, что заказ принадлежит аутентифицированному пользователю

Пример 2: SQL Injection в поиске

Баг: SQL Injection в поиске товаров
Серьёзность: Критическая
URL: /search?q=

Шаги воспроизведения:
1. Перейдите на страницу поиска
2. Введите: ' OR '1'='1' --
3. Наблюдайте: Возвращены все товары (SQL выполнен)
4. Введите: ' UNION SELECT username, password FROM users --
5. Наблюдайте: Раскрыты учётные данные пользователей

Импакт: Полный доступ к базе данных, утечка данных

Исправление: Использовать параметризованные запросы

Пример 3: XSS в профиле пользователя

Баг: Stored XSS в поле био профиля
Серьёзность: Высокая
Расположение: Био в профиле пользователя

Шаги воспроизведения:
1. Перейдите в настройки профиля
2. Введите био: <script>alert(document.cookie)</script>
3. Сохраните профиль
4. Посмотрите профиль (как любой пользователь)
5. Наблюдайте: JavaScript выполняется

Импакт: Захват сессии, угон аккаунта

Исправление: Санитизировать вывод, внедрить CSP

Часть 6: Вопросы по безопасности на собеседовании

Частые вопросы и ответы

В: В чём разница между аутентификацией и авторизацией?

Аутентификация: Проверка КТО вы (идентичность)
  - Логин/пароль, MFA, биометрия
  
Авторизация: Проверка ЧТО вы можете делать (разрешения)
  - Проверка ролей, списки контроля доступа

В: Объясните SQL Injection и как его предотвратить.

SQL Injection: Внедрение вредоносного SQL через пользовательский ввод

Предотвращение:
1. Использовать параметризованные запросы (prepared statements)
2. Использовать ORM фреймворки
3. Валидация и санитизация ввода
4. Минимальные привилегии для базы данных

Пример (Python):
# Плохо (уязвимо)
query = f"SELECT * FROM users WHERE id = {user_id}"

# Хорошо (параметризовано)
query = "SELECT * FROM users WHERE id = ?"
cursor.execute(query, (user_id,))

В: Что такое XSS и какие типы существуют?

XSS (Cross-Site Scripting): Внедрение вредоносных скриптов

Типы:
1. Stored XSS - Скрипт сохранён в базе данных
2. Reflected XSS - Скрипт в URL, отражается обратно
3. DOM XSS - Скрипт манипулирует DOM напрямую

Предотвращение:
- Кодирование вывода
- Content Security Policy (CSP)
- Валидация ввода
- HttpOnly cookies

В: Как тестировать нарушение контроля доступа?

1. Тестировать IDOR - Изменять ID в URL/API
2. Тестировать горизонтальную эскалацию - Доступ к данным других пользователей
3. Тестировать вертикальную эскалацию - Доступ к админским функциям
4. Тестировать отсутствие контроля на уровне функций
5. Тестировать манипуляцию JWT/токенов
6. Тестировать path traversal

Часть 7: Развитие навыков тестирования безопасности

План обучения

Уровень 1: Основы (Неделя 1-2)
├── OWASP Top 10
├── Базовые концепции веб-безопасности
├── DevTools браузера для безопасности
└── Основы HTTP/HTTPS

Уровень 2: Инструменты (Неделя 3-4)
├── Основы Burp Suite
├── OWASP ZAP
├── Инструменты командной строки
└── Расширения браузера

Уровень 3: Практика (Неделя 5-8)
├── OWASP WebGoat
├── Damn Vulnerable Web Application (DVWA)
├── HackTheBox
├── PortSwigger Web Security Academy
└── Bug bounty программы (сначала только чтение)

Уровень 4: Интеграция (Неделя 9-12)
├── Безопасность в CI/CD
├── Моделирование угроз
├── Требования безопасности
└── Автоматизация безопасности

Бесплатные ресурсы

РесурсТипСсылка
OWASP WebGoatПрактикаhttps://owasp.org/www-project-webgoat/
PortSwigger AcademyОбучениеhttps://portswigger.net/web-security
HackTheBoxCTFhttps://www.hackthebox.com/
TryHackMeОбучениеhttps://tryhackme.com/
OWASP Testing GuideРуководствоhttps://owasp.org/www-project-testing/

Итоги

Добавление тестирования безопасности в ваш набор навыков как QA инженера:

✅ Увеличивает вашу ценность - Навыки безопасности очень востребованы
✅ Улучшает качество продукта - Находите баги раньше хакеров
✅ Защищает пользователей - Предотвращает утечки данных и кражу личности
✅ Продвигает вашу карьеру - Открывает двери к ролям в безопасности

Ключевые выводы:

  1. Выучите OWASP Top 10 наизусть
  2. Практикуйтесь на уязвимых приложениях
  3. Добавьте проверки безопасности в ваши тест-планы
  4. Используйте инструменты типа Burp Suite и ZAP
  5. Автоматизируйте тесты безопасности в CI/CD

Что дальше?

Продолжайте своё обучение:

  • 🔒 Получите сертификаты: CompTIA Security+, CEH, OSCP
  • 🐛 Присоединитесь к bug bounty программам: HackerOne, Bugcrowd
  • 📚 Читайте: “The Web Application Hacker’s Handbook”
  • 🛠️ Практикуйтесь ежедневно с CTF задачами

Помните: Безопасность — это не разовая активность. Это образ мышления, который должен быть частью каждой тестовой активности!

Удачного (этичного) хакинга! 🔐