Уязвимости веб-приложений: инъекции, XSS и нарушение аутентификации
Уязвимости веб-приложений: инъекции, XSS и нарушение аутентификации
Каждый раз, когда вы открываете социальную сеть, интернет-магазин или банковское приложение на своем смартфоне, вы взаимодействуете с веб-приложением. Под красивым интерфейсом скрывается сложный механизм: ваш телефон (клиент) отправляет запросы, а удаленный компьютер (сервер) их обрабатывает, извлекает данные из базы и отправляет ответ.
Именно на стыке передачи и обработки этих данных возникают бреши в безопасности. В этичном хакинге понимание того, как работают веб-уязвимости, — это фундамент. Сегодня мы разберем три самые критичные угрозы, которые можно обнаружить и протестировать прямо с экрана мобильного устройства.
SQL-инъекции: как заговорить с базой данных
Большинство современных сайтов хранят информацию в базах данных. Чтобы получить нужную информацию, сервер общается с базой с помощью специального языка — SQL (Structured Query Language).
SQL-инъекция (SQLi) возникает, когда веб-приложение берет данные, введенные пользователем, и вставляет их в SQL-запрос без предварительной проверки. Это позволяет злоумышленнику «внедрить» свой собственный код и заставить базу данных выполнить незапланированные команды.
Представьте, что вы пришли в закрытый клуб. Охранник спрашивает ваше имя и сверяет его со списком. Если вы скажете: «Меня зовут Иван, ИЛИ я владелец этого клуба», глупый охранник может пропустить вас, услышав вторую часть фразы. Именно так работает SQL-инъекция.
Рассмотрим классический пример обхода авторизации. В коде сервера запрос к базе данных может выглядеть так:
SELECT * FROM users WHERE username = '[ВВОД_ПОЛЬЗОВАТЕЛЯ]' AND password = '[ВВОД_ПОЛЬЗОВАТЕЛЯ]'
Если в поле логина ввести специальную полезную нагрузку (payload) вида ' OR 1=1 --, запрос превратится в следующее:
SELECT * FROM users WHERE username = '' OR 1=1 --' AND password = '...'
Разберем этот трюк по частям:
- Одинарная кавычка
'закрывает поле ввода логина. - Оператор
ORдобавляет альтернативное условие. - Выражение
1=1всегда является истинным (математический факт). - Символы
--в языке SQL означают начало комментария. База данных просто проигнорирует всё, что написано после них (включая проверку пароля).
В результате база данных читает запрос так: «Найди пользователя с пустым именем, ИЛИ просто верни правду». Поскольку условие истинно, система пускает атакующего в первый попавшийся аккаунт, который чаще всего принадлежит администратору.
Как тестировать SQLi со смартфона
В концепции Pocket Pentest поиск SQL-инъекций начинается с разведки полей ввода. Вы можете использовать обычный мобильный браузер:
- Найдите параметры в URL-адресе, например:
https://example.com/item?id=5. - Попробуйте добавить одинарную кавычку в конец:
?id=5'. - Если страница выдает ошибку базы данных (например, SQL syntax error) или часть контента исчезает, это верный признак того, что сервер уязвим.
Для более глубокого анализа на Android можно использовать терминал Termux с установленным инструментом sqlmap, который автоматизирует процесс поиска и эксплуатации инъекций.
Межсайтовый скриптинг (XSS): троянский конь в браузере
Если SQL-инъекция атакует сервер, то Межсайтовый скриптинг (XSS) нацелен на других пользователей приложения. Эта уязвимость возникает, когда сайт позволяет одному пользователю внедрить исполняемый код (обычно на языке JavaScript) в веб-страницы, которые просматривают другие люди.
Браузер доверяет коду, который приходит от легитимного сайта. Если хакеру удастся поместить туда свой скрипт, браузер жертвы послушно его выполнит.
Существует три основных типа XSS:
| Тип XSS | Как работает | Пример из жизни |
|---|---|---|
| Хранимый (Stored) | Вредоносный код навсегда сохраняется в базе данных сервера (например, в комментариях). | Хакер оставляет отзыв к товару со скрытым скриптом. Любой, кто откроет страницу товара, подвергнется атаке. |
| Отраженный (Reflected) | Скрипт передается через ссылку и немедленно «отражается» сервером обратно в браузер жертвы. | Хакер отправляет жертве ссылку на поиск по сайту: site.com/search?q=<script>.... Жертва кликает, скрипт выполняется. |
| DOM-based | Уязвимость находится не на сервере, а в самом JavaScript-коде страницы, который неправильно обрабатывает данные. | Скрипт на странице берет часть URL (например, после символа #) и вставляет ее в текст без проверки. |
XSS-уязвимости позволяют злоумышленникам внедрять произвольные скрипты в веб-страницы, которые будут исполняться в браузерах других пользователей.
Что может сделать XSS? Самый частый сценарий — кража сессионных файлов cookie. Cookie — это ваш цифровой паспорт на сайте. Если злоумышленник украдет его с помощью скрипта, он сможет зайти в ваш аккаунт без логина и пароля.
Практика: поиск XSS с телефона
Для базового поиска XSS вам не нужны сложные программы. Достаточно мобильной клавиатуры. Попробуйте ввести в поле поиска или в форму комментария простейший HTML-тег:
<h1>Тест</h1>
Если после отправки слово «Тест» стало огромным и жирным (превратилось в заголовок), значит, сайт не фильтрует ввод (не проводит санитизацию). Следующим шагом этичный хакер попробует ввести безопасный JavaScript-код, например, <script>alert('XSS')</script>. Если на экране телефона появится всплывающее окно с надписью «XSS» — уязвимость подтверждена.
Нарушение аутентификации: потерянные ключи
Даже если сайт защищен от инъекций и XSS, он может быть взломан из-за логических ошибок. Нарушение аутентификации — это широкий класс уязвимостей, связанных с тем, как приложение проверяет личность пользователя и управляет его сессией.
Представьте гостиницу. Вы показали паспорт на ресепшене (ввели логин и пароль) и получили ключ-карту от номера (сессионный токен). Если замок на двери плохой, или ключ-карты выдаются по порядку (номер 1, номер 2, номер 3), кто угодно сможет проникнуть в вашу комнату.
Типичные проблемы аутентификации:
- Слабые пароли и отсутствие защиты от перебора (Brute-force). Если сайт позволяет вводить пароль 10 000 раз подряд без блокировки, хакер просто переберет все возможные комбинации.
- Предсказуемые идентификаторы сессий. Если после входа сайт выдает вам cookie вида
session_id=105, злоумышленник может вручную поменять в своем браузере значение на106и оказаться в чужом аккаунте. - Передача данных в открытом виде. Если сайт использует протокол HTTP вместо защищенного HTTPS, любой человек, подключенный к той же публичной сети Wi-Fi (например, в кафе), может перехватить ваши пароли.
Защита и этичный подход
Главное правило защиты от всех описанных уязвимостей — никогда не доверять пользовательскому вводу.
Разработчики должны использовать параметризованные запросы для защиты от SQLi (когда данные передаются отдельно от команд базы данных), экранировать спецсимволы для предотвращения XSS и внедрять строгие политики паролей с многофакторной аутентификацией (MFA).
Для вас, как для начинающего пентестера, важно помнить об этике. Тестировать реальные сайты без письменного разрешения их владельцев — это уголовное преступление.
Pocket Challenge (Безопасная тренировка): Чтобы легально оттачивать навыки со смартфона, зарегистрируйтесь на платформах вроде TryHackMe или PortSwigger Web Security Academy. Они предоставляют изолированные, специально уязвимые веб-страницы. Вы можете открывать их прямо в мобильном браузере Chrome или Safari, вводить полезные нагрузки в формы и наблюдать за реакцией системы, не нарушая закон.