Безопасность и мониторинг
Урок 7.7 — Безопасность и мониторинг
Безопасность: что тестировщику нужно знать
Тестирование безопасности — это отдельная большая область (пентест, security QA). Но любой тестировщик должен понимать базовые концепции, чтобы проверять очевидные уязвимости.
Аутентификация vs Авторизация
Эти два понятия часто путают:
| Понятие | Вопрос | Пример |
|---|---|---|
| Аутентификация | Кто ты? | Логин по паролю, вход через Google |
| Авторизация | Что тебе разрешено? | Может ли пользователь редактировать чужой профиль? |
Тестировщик проверяет:
- Можно ли получить доступ к данным без авторизации (без логина)?
- Может ли обычный пользователь выполнить действие, доступное только администратору?
- Может ли пользователь А получить доступ к данным пользователя Б (IDOR)?
HTTPS vs HTTP
- HTTP — данные передаются в открытом виде. Любой в сети может перехватить и прочитать.
- HTTPS — данные зашифрованы. Перехватить можно, прочитать — нельзя.
Тестировщик проверяет: весь сайт работает по HTTPS? Особенно страницы входа и оплаты. Если где-то используется HTTP — это баг.
Типичные уязвимости: концептуально
SQL-инъекция (SQL Injection) Атакующий вводит в форму часть SQL-запроса, чтобы изменить логику запроса к базе данных.
Пример уязвимого поля логина: если ввести в поле email строку ' OR '1'='1, можно войти без пароля.
Что тестировщик делает: вводит в текстовые поля специальные символы (', ", ;) и проверяет, не возвращается ли ошибка SQL или неожиданный результат.
XSS (Cross-Site Scripting) Атакующий вставляет JavaScript-код в поле ввода, и браузер другого пользователя его выполняет.
Пример: ввести в поле имени <script>alert('XSS')</script>. Если при просмотре профиля появляется alert — уязвимость есть.
Токены и сессии
| Подход | Как работает | Что хранится у клиента |
|---|---|---|
| Session-based | Сервер хранит сессию, клиент получает session ID | Cookie с session ID |
| Token-based (JWT) | Сервер создаёт подписанный токен с данными | JWT-токен в localStorage или Cookie |
Что проверяет тестировщик:
- Инвалидируется ли токен при выходе из системы?
- Работает ли токен после истечения срока (exp)?
- Если скопировать токен из одного браузера — работает ли он в другом?
Мониторинг: как узнают о поломках в проде
В продакшене нет тестировщика. Нужно следить за тем, что происходит автоматически.
Sentry — инструмент трекинга ошибок:
- Автоматически собирает JavaScript-ошибки с фронта и исключения с бэка
- Показывает, сколько пользователей столкнулись с ошибкой
- Сохраняет стек вызовов — разработчику не нужно воспроизводить
Datadog, New Relic, Prometheus + Grafana — мониторинг производительности:
- Показывают время отклика, нагрузку на сервер, использование памяти
- Алерты — уведомления, если метрика вышла за порог (например, время ответа > 2с)
Что тестировщик может использовать:
- Попроси доступ к Sentry на тестовом окружении — видишь ошибки в реальном времени
- Ошибки в Sentry иногда всплывают ещё до того, как пользователь успеет написать баг-репорт
Итоги модуля 7
Ты прошёл обзор всего технологического стека:
| Урок | Тема | Ключевой навык тестировщика |
|---|---|---|
| 7.1 | Введение | Понимать, зачем знать стек |
| 7.2 | Frontend | DevTools, консоль, SPA, кросс-браузерность |
| 7.3 | Backend | HTTP-коды ошибок, логи, API-контракт |
| 7.4 | База данных | SELECT для проверки, консистентность данных |
| 7.5 | API | Postman, Swagger, REST vs GraphQL |
| 7.6 | Инфраструктура | Окружения, CI/CD, Git-ветки |
| 7.7 | Безопасность | Auth vs AuthZ, HTTPS, XSS/SQLi, мониторинг |
Что мы запомним
- Аутентификация = кто ты; Авторизация = что тебе можно
- HTTPS — обязателен; HTTP для чувствительных данных — это баг
- SQL-инъекция и XSS — базовые уязвимости, которые тестировщик проверяет вручную
- Sentry и другие инструменты мониторинга — союзники тестировщика в бою с продакшн-багами
- Знание технологий — не про код, а про то, чтобы быть эффективным участником команды разработки