Ты открываешь браузер, вбиваешь google.com, и через секунду видишь страницу. Магия? Нет. За этой секундой скрывается целая цепочка событий, которую каждый разработчик обязан понимать. А если ты хочешь думать как хакер (этичный, разумеется 😏), то знать это — не опция, а необходимость.
Давай разберём всё по полочкам. Без занудства, с примерами из жизни.
🔍 DNS — телефонная книга интернета
Компьютеры не понимают google.com. Они работают с IP-адресами вроде 142.250.74.206. А DNS (Domain Name System) — это огромная телефонная книга, которая переводит человеческие адреса в машинные.
Что происходит, когда ты вводишь адрес сайта:
Кэш браузера — может, ты уже заходил? Тогда IP уже сохранён.
Кэш операционной системы — система тоже запоминает.
Роутер — даже он хранит свой кэш DNS.
DNS-резолвер провайдера — если нигде не нашлось, запрос летит к серверу провайдера.
Корневые DNS → TLD → авторитетный сервер — цепочка запросов, пока не найдётся ответ.
Вся эта история занимает миллисекунды. Но вот что интересно с точки зрения безопасности:
DNS-спуфинг — атакующий подменяет ответ DNS и отправляет тебя на фейковый сайт. Ты вводишь bank.com, а попадаешь на клон мошенников. Внешне — один в один. Именно поэтому одного DNS недостаточно — нужен HTTPS.
Попробуй сам: открой терминал и введи nslookup google.com или dig google.com. Увидишь, как твоя система ищет IP.
📡 HTTP — открытка без конверта
HTTP (HyperText Transfer Protocol) — это протокол, по которому браузер общается с сервером. Работает по принципу «запрос — ответ».
Анатомия HTTP-запроса:
GET /profile HTTP/1.1
Host: example.com
Cookie: session_id=abc123
User-Agent: Mozilla/5.0Сервер отвечает:
HTTP/1.1 200 OK
Content-Type: text/html
Set-Cookie: session_id=abc123
<html>...</html>Просто, правда? Но есть огромная проблема: HTTP передаёт всё открытым текстом. Представь, что ты отправляешь открытку по почте — любой почтальон может её прочитать. Логин, пароль, номер карты — всё видно.
Основные HTTP-методы:
GET «дай мне данные»
POST «вот мои данные»
PUT «обнови это»
DELETE «удали это»
Коды ответов, которые стоит запомнить:
200всё ок
301редирект
403запрещено
404не найдено
500сервер упал
Хакер, перехватив HTTP-трафик (например, в публичном Wi-Fi), видит абсолютно всё. Поэтому чистый HTTP сегодня — это уязвимость.
🔒 HTTPS — конверт с сургучной печатью
HTTPS — тот же HTTP, но обёрнутый в шифрование через TLS (Transport Layer Security). Теперь данные выглядят как мешанина символов для всех, кроме отправителя и получателя.
Как устанавливается защищённое соединение (TLS Handshake):
Клиент: «Привет, я хочу безопасно поговорить. Вот мои возможности шифрования.»
Сервер: «Привет! Вот мой SSL-сертификат — можешь проверить, что я настоящий.»
Клиент: проверяет сертификат через центр сертификации (CA).
Оба генерируют общий секретный ключ.
Дальше всё общение зашифровано этим ключом.
Зачем это хакеру?
Даже если злоумышленник перехватит HTTPS-трафик, он увидит лишь зашифрованный мусор. Но есть нюансы:
Устаревшие версии TLS (1.0, 1.1) имеют известные уязвимости. Неправильно настроенные сертификаты — если пользователь привыкнет нажимать «всё равно перейти», его можно обмануть. MITM (Man-in-the-Middle) — атакующий встаёт между клиентом и сервером, подставляя свой сертификат. Обращай внимание на замочек 🔒 в адресной строке!
🍪 Куки — цифровой бейджик
HTTP — протокол без состояния (stateless). Сервер не помнит тебя между запросами. Каждый раз ты для него — незнакомец. Куки решают эту проблему.
Cookie — маленький кусочек текста, который сервер просит браузер сохранить и отправлять с каждым запросом.
Как это работает:
Ты логинишься на сайте.
Сервер создаёт сессию и отвечает:
Set-Cookie: session_id=xyz789Браузер сохраняет эту куку.
При каждом следующем запросе браузер отправляет:
Cookie: session_id=xyz789Сервер видит ID и понимает: «А, это тот самый пользователь!»
Виды кук:
Session- Живут до закрытия браузера
Persistent- Живут до указанной даты
HttpOnly- JS не может их прочитать — защита от XSS
Secure - Отправляются только по HTTPS
SameSite - Защита от CSRF-атак
Почему хакеры охотятся за куками:
Если украсть чужую session cookie — можно войти на сайт от имени жертвы без логина и пароля. Это называется session hijacking (угон сессии).
Способы кражи: XSS (вредоносный скрипт ворует cookie), перехват трафика (если нет HTTPS), физический доступ к чужому браузеру.
🎫 Сессии — кто ты для сервера?
Сессия — это механизм хранения данных о пользователе на стороне сервера. Cookie содержит только ID сессии (ключ), а все данные (имя, роль, корзина покупок) лежат на сервере.
Cookie vs Session — в чём разница:
Cookie | Session | |
|---|---|---|
Где хранится | В браузере | На сервере |
Размер | До ~4 КБ | Без ограничений |
Безопасность | Клиент может изменить | Клиент видит только ID |
Пример |
|
|
JWT — альтернативный подход:
Вместо хранения сессий на сервере можно использовать JSON Web Token (JWT). Это токен, который содержит зашифрованную информацию о пользователе. Сервер не хранит состояние — всё внутри токена.
Структура: header.payload.signature
Плюсы: масштабируемость (не нужна общая БД сессий). Минусы: нельзя «убить» отдельный токен до истечения срока.
📱 Хочешь по-настоящему разобраться — практикуйся!
Теория — это фундамент, но настоящее понимание приходит только через практику. Попробуй Кодик — приложение, где ты учишься программированию через решение реальных задач. Никакой воды — только практика и понятные объяснения.
А ещё подписывайся на наш Telegram-канал — полезные посты по программированию, разборы тем и лайфхаки. Читай в метро, за обедом или перед сном 🚀
🧠 Итог
Интернет — это не магия. Это цепочка протоколов, каждый из которых решает свою задачу. DNS переводит имена в адреса, HTTP доставляет данные, HTTPS их шифрует, куки хранят состояние, а сессии — идентифицируют пользователя.
Понимание этих основ — первый шаг к тому, чтобы писать безопасный код и думать на шаг впереди. Не как обычный пользователь, а как тот, кто знает, что происходит под капотом. 🧠