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

⚠️ Дисклеймер:
Вся информация в этой статье предоставлена исключительно в образовательных целях. Автор и платформа HackerLab не поощряют и не несут ответственности за любые противоправные действия, совершённые на основе изложенного материала. Используйте знания этично и только в рамках закона.

Введение

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

Чтобы стать пентестером, недостаточно уметь отправлять запросы. Нужно понимать, как устроено веб-приложение, как данные путешествуют от браузера до базы — и где на этом пути можно сломать что-то важное.

Что такое веб-приложение

Веб-приложение — это сайт, у которого есть логика. Это не просто страничка с текстом, а полноценная система с пользователями, авторизацией, товарами, базами данных и API.

Когда ты заходишь на сайт, происходит следующее:

1. Браузер отправляет HTTP-запрос на сервер (например, GET /profile?id=42)
2. Сервер принимает запрос, обрабатывает его, достаёт данные из базы
3. Возвращает HTML-код страницы
4. Браузер отображает страницу, применяет CSS и запускает JavaScript

На каждом шаге — шанс на ошибку. И каждый шаг можно проанализировать.

Разбор: ты заходишь на https://example.com/profile?id=42

Что происходит:

• https:// — защищённый протокол связи
• example.com — домен (через DNS превращается в IP)
• /profile — путь на сервере, обрабатывается кодом
• ?id=42 — параметр, который можно изменить

Пентестер думает: «А что будет, если я подставлю ?id=43? А ?id=1 OR 1=1?»

HTML, CSS, JS — зачем они тебе?

Технология	Роль в приложении	Где искать уязвимости
HTML	Разметка страницы, формы, ввод	XSS, hidden-поля, параметры
CSS	Визуальное оформление	Редко, но возможны edge-кейсы
JS	Поведение на клиенте, интерактив	DOM-based XSS, уязвимый fetch

Пример:

Открываешь DevTools (F12), находишь форму логина. Видишь input с именем email. JS-проверка требует @, но ты знаешь, что на сервер можно отправить всё, что угодно.

Пентестер всегда смотрит: «Что валидирует браузер — а что можно обойти?»

HTTP-запросы: как браузер говорит с сервером

Пример запроса:

GET /profile?id=42 HTTP/1.1 Host: example.com Cookie: session=abc123 User-Agent: Firefox

Что здесь важно:

• Cookie — ключ к сессии. Его можно украсть (XSS) или подделать
• User-Agent — можно менять, чтобы обходить фильтры
• ?id=42 — можно попытаться использовать в атаке

Попробуй:

curl -v "https://example.com/profile?id=42"

Серверная логика: где принимаются решения

На сервере может быть любой язык: Python, PHP, Node.js, Ruby...

Пример (Flask, Python):

    
@app.route('/profile')
def profile():
    user_id = request.args.get("id")
    return db.query(f"SELECT * FROM users WHERE id={user_id}")
    

Видишь f"SELECT * FROM ..."? Здесь SQL-инъекция. Если подставить id=1 OR 1=1, получим все записи.

Сервер — это место, где пентестер ищет логические ошибки, плохие проверки, дырки в авторизации.

Базы данных: где лежит всё ценное

Каждое веб-приложение работает с базой данных. Именно туда сохраняются:

• логины и пароли (иногда в открытом виде)
• письма, посты, товары, комментарии
• токены и куки

Основные типы:

Тип	Где используется	Уязвимости
MySQL	WordPress, CMS	SQL-инъекции, дампы
SQLite	Мобильные/локальные	Легко читается, подменяется
MongoDB	Современные SPA	NoSQL-инъекции, открытые API

Если сервер плохо фильтрует вход — ты можешь пробраться в базу.

Тренировочные песочницы

1. HackTheBox
2. PortSwigger
3. HackerLab

Что запомнить

• Веб-приложение — это не просто сайт. Это клиент + сервер + база
• Всё, что ты видишь в адресной строке — можно изменить
• HTML/JS — источник XSS и DOM-уязвимостей
• Сервер часто обрабатывает параметры как есть
• База данных — конечная цель, именно там лежат флаги, пароли, доступ