Вступление
— «Security-тестирование? Нет уж, я не хакер и даже не пытаюсь им стать!»
Знакомо? Считается, что тестировать безопасность должны специально обученные специалисты в толстовках с капюшоном и хакерским ноутбуком. Но на самом деле даже обычный QA может (и должен!) проверять базовую безопасность приложений.
Сегодня расскажу, с чего начать, если слова «XSS», «SQL-инъекция» и «OWASP» кажутся тебе страшнее фразы «релиз в пятницу вечером».
1. Почему тестирование безопасности нужно каждому QA?
В 2025 году безопасность — это уже не просто фича, это обязательное условие выхода приложения на рынок. Даже минимальные знания безопасности делают тебя круче как профессионала и экономят команде огромные деньги на исправление уязвимостей.
Простая статистика:
- Более 60% взломов происходит через самые простые ошибки в приложениях.
- Устранение одной уязвимости после релиза в среднем в 30 раз дороже, чем до релиза.
2. Базовые термины, которые должен знать каждый QA
- OWASP (Open Web Application Security Project) — международная организация, собирает топ-10 самых популярных уязвимостей приложений.
- SQL-инъекция — попытка вставить вредоносный SQL-запрос через поле ввода данных.
- XSS (Cross-Site Scripting) — возможность внедрить вредоносный JavaScript-код на страницу, чтобы украсть пользовательские данные.
- CSRF (Cross-Site Request Forgery) — атака, заставляющая пользователя выполнить нежелательное действие (например, перевод денег).
- Brute force — подбор пароля простым перебором.
3. OWASP Top-5 уязвимостей, которые должен проверять каждый QA
1. Инъекции (Injection)
Самая простая проверка:
Введи в поле для имени ' OR 1=1 --.
Если система сломалась или вернула всё содержимое базы — поздравляю, ты нашёл SQL-инъекцию!
2. XSS (Cross-Site Scripting)
Простая проверка: введи в текстовые поля
htmlКопироватьРедактировать<script>alert('QA XSS');</script>
Если браузер покажет сообщение — это баг, XSS!
3. Небезопасная авторизация
Примеры: хранение паролей в открытом виде, слишком простые пароли, нет ограничений по числу попыток входа.
Проверяй:
- Попробуй простой пароль «123456». Если он прошёл — баг.
- Попробуй войти с неверным паролем много раз. Если не заблокировали — баг.
4. Небезопасные данные
Открой консоль браузера, посмотри куки и локальное хранилище. Если видишь пароли, токены или личные данные в открытом виде — это баг.
5. Небезопасная загрузка файлов
Попробуй загрузить файл с расширением .php или .exe. Если сервер не проверяет тип файла и загружает его — это уязвимость.
4. Простые инструменты для тестирования безопасности, доступные каждому QA
- OWASP ZAP
Простой бесплатный инструмент, который автоматически найдёт базовые проблемы в веб-приложении. Запускаешь, вводишь адрес сайта — получаешь список потенциальных багов безопасности. - Burp Suite Community Edition
Отлавливает HTTP-запросы и ответы. Удобно проверять API, авторизацию, поля ввода на базовые уязвимости. - Postman
Простой способ проверить API на безопасность. Попробуй отправить некорректные запросы или вредоносные данные и посмотри, как API реагирует.
5. Примеры простых проверок, которые может сделать каждый QA прямо сегодня
Проверка на SQL-инъекции:
Попробуй в поля ввода:
' OR 1=1; --
Проверка на XSS:
<img src=x onerror=alert('XSS by QA')>
Проверка слабой авторизации:
- Пароль: password, 123456
- Логин: admin/admin, root/root
6. Советы, как быстро повысить свои знания по безопасности
- Изучи OWASP Top-10. Там кратко и понятно расписано, что это за уязвимости и как их найти.
- Подпишись на профильные каналы в Telegram или YouTube (OWASP Russia, CyberSecurity Hub, QA-каналы по безопасности).
- Используй готовые чек-листы безопасности (легко найти в сети).
7. Мифы о Security-тестировании, которые мешают начать
- «Нужны глубокие знания программирования».
Нет, для базовых проверок достаточно минимальных знаний HTML и SQL. - «Security-тестирование требует дорогих инструментов».
OWASP ZAP и Burp Suite Community бесплатны и мощны. - «Этим должны заниматься профессиональные хакеры».
Безопасность — ответственность всей команды, и QA в том числе.
8. Что делать, если нашёл уязвимость?
- Зафиксируй шаги, которые привели к уязвимости.
- Напиши баг-репорт с приоритетом Critical/Blocker.
- Немедленно сообщи команде. Не публикуй открыто эту информацию.
- Убедись, что баг не выпустили в продакшен.
9. Итоги
Security-тестирование — это не сложно, не страшно и реально доступно каждому QA, даже если ты не "хакер". Достаточно знать базовые техники и использовать простые инструменты, чтобы стать намного круче и полезнее для команды.
Это не только ценный опыт, но и очень интересное направление, которое может существенно повлиять на твою карьеру и зарплату.