ИнфоБез

Web Security #14. CORS: кто имеет право читать ответ Представим два сайта:

https://frontend.example
https://api.example

JavaScript на frontend хочет сделать:

fetch("https://api.example/profile")

Браузер видит:

Origin:
https://frontend.example

а ресурс находится на другом origin:

https://api.example

Здесь вступает в игру CORS — Cross-Origin Resource Sharing. Сервер может ответить:

Access-Control-Allow-Origin: https://frontend.example

Браузер понимает:

Этот origin разрешён.

Если сервер не разрешил origin, браузер ограничит доступ JavaScript к ответу. Очень важно: CORS — это в первую очередь механизм браузера. Он не является универсальным firewall. Например:

Attacker
   |
   v
Server

CORS не означает автоматически:

"Server не принимает запросы от attacker"

Он регулирует, может ли browser-код прочитать cross-origin response. Ещё одна распространённая ошибка:

Access-Control-Allow-Origin: *

вместе с неправильной конфигурацией credentials. Поэтому CORS нужно рассматривать вместе с:

Origins
Cookies
Credentials
Authentication
Browser security model

Практика: Открой DevTools → Network. Найди запрос к API. Посмотри:

Origin
Access-Control-Allow-Origin
Access-Control-Allow-Credentials

Затем ответь на вопрос:

Какой именно origin сервер разрешает читать этот response?

Web Security #13. JWT: что находится внутри токена JWT часто используется для authentication и передачи claims. Выглядит он примерно так:

xxxxx.yyyyy.zzzzz

У JWT три части:

header.payload.signature

Например, payload может содержать:

{
    "sub": "123",
    "role": "user"
}

Здесь:

sub = идентификатор пользователя
role = его роль

Важный момент: JWT обычно не является зашифрованным контейнером. Payload можно декодировать и прочитать. Поэтому нельзя помещать туда секреты вроде:

password
private_key
API secret

Но тогда возникает вопрос:

Если payload можно прочитать и изменить, почему нельзя просто поменять

role=user

на

role=admin

?

Потому что существует signature. Упрощённо:

Header + Payload
       |
       v
   Secret key
       |
       v
   Signature

Сервер пересчитывает подпись и проверяет, что токен не был изменён. Если payload изменили:

{
    "role": "admin"
}

подпись уже не соответствует содержимому. Практическая безопасность JWT зависит от:

Проверки signature
Проверки algorithm
Проверки expiration
Проверки issuer/audience
Безопасного хранения токена

Главная ошибка новичка:

«JWT — это зашифрованный пароль».

Нет. JWT — это формат передачи подписанных данных. Практика: Возьми JWT из своей учебной лаборатории. Разбери:

Header
Payload
Signature

Попробуй понять:

Какие данные находятся внутри?
Какие claims используются?
Есть ли expiration?
Как сервер проверяет подпись?

Учишься в 9-11 классе и изучаешь программирование? Прими участие в олимпиаде Высшая проба по промышленному программированию от Яндекса и ВШЭ! Получи опыт решения кейсов из индустрии, подарки от Яндекса, БВИ или 100 баллов по профильному предмету. Регистрируйся до 20 октября! Узнать больше #реклама 16+ olymp.hse.ru О рекламодателе

Web Security #12. Burp Suite: учимся видеть HTTP До этого мы много говорили о запросах:

GET /profile?id=123 HTTP/1.1
Cookie: session=abc123

Теперь нужен инструмент, который позволит удобно их изучать. Один из основных инструментов Web Security — Burp Suite. Схема работы:

Browser
   |
   v
 Burp Suite
   |
   v
Server

Burp получает HTTP-запрос и показывает его нам. Например:

GET /profile?id=123 HTTP/1.1
Host: lab.local
Cookie: session=abc123

Теперь можно увидеть:

Method
URL
Parameters
Headers
Cookies
Body
Response

Особенно полезен Repeater. Можно взять запрос:

GET /profile?id=123 HTTP/1.1

отправить его в Repeater и изменить:

GET /profile?id=124 HTTP/1.1

Затем сравнить ответы. Именно так удобно исследовать:

IDOR
Authentication
Authorization
Input validation
API
Cookies
Headers

Burp не ищет уязвимости вместо тебя. Он помогает задавать вопросы:

Что произойдёт, если изменить ID?
Что произойдёт, если убрать cookie?
Что произойдёт, если изменить method?
Что произойдёт, если изменить parameter?

Практика: Возьми учебную лабораторию. Сделай пять шагов:

1. Открой страницу.
2. Найди запрос в Proxy.
3. Отправь его в Repeater.
4. Измени одно значение.
5. Сравни Response.

Изменяй только один параметр за раз. Так гораздо легче понять причинно-следственную связь.

Авторизованные курсы по оборудованию Eltex от дилера №1 Проводим учебные курсы, включающие практические занятия и лабораторные работы. По итогу успешной сдачи экзаменов обучающемуся выдаётся официальный сертификат от завода Eltex. ⚡Обучение в офисе или онлайн ⚡Опытный преподавательский состав ⚡Лабораторные работы - 50% времени ⚡Обучение юридических и физических лиц Записаться #реклама 16+ eltexcm.ru О рекламодателе

Web Security #11. File Upload: почему загрузка файла — это security-проблема Почти каждый сайт умеет принимать файлы:

Аватар
Документ
Резюме
Изображение
PDF

Допустим, приложение принимает:

POST /upload HTTP/1.1
Content-Type: multipart/form-data

И разработчик проверяет:

filename заканчивается на .jpg

Кажется, что всё хорошо. Но расширение файла — это только одна характеристика. Нужно учитывать:

Имя файла
Расширение
MIME type
Реальное содержимое
Размер
Место хранения
Права доступа
Способ последующей обработки

Например, сервер может ожидать:

avatar.jpg

Но если приложение неправильно проверяет содержимое и потом размещает загруженный файл в web-доступном каталоге, это может создать серьёзную проблему. Безопасная архитектура обычно выглядит так:

Upload
  ↓
Validate
  ↓
Generate server-side filename
  ↓
Store outside executable web directory
  ↓
Serve as data

Например:

Пользователь:
avatar.jpg

Сервер:
f83a91c2.bin

И приложение само решает, как отдавать этот файл. Главная мысль:

Загруженный пользователем файл — недоверенные данные.

Практика: В учебной лаборатории найди upload functionality. Изучи:

Какие расширения разрешены?
Проверяется ли MIME type?
Проверяется ли содержимое?
Где хранится файл?
Можно ли открыть его напрямую через URL?

REKONFA: что интересного вас ждёт 15 октября 15 октября встречаемся на REKONFA — большой конференции Яндекс Рекламы. На сцене: — Глеб Доброрадных — о рекламном рынке и эффективности в сложных условиях — Алексей Штоколов — о новых продуктах и технологиях — Лиза Смирнова — о 360°-форматах и новых точках контакта — Александр Пушной — о человеке и ИИ — Александр Умаров — о персональном подходе, который помогает влюблять клиентов в бренд — Яна Чурикова — об актуальных задачах предпринимателей — Татьяна Мужицкая — о целях и энергии — Антон Беляев — об индивидуальности и проектах, которые любят зрители Вне сцены — зона продуктов Яндекс Рекламы, три игры, викторина, зоны Яндекс Ярда и eLama и нетворкинг. 15 октября, Москва, ВТБ Арена и онлайн. Участие бесплатное. Зарегистрироваться #реклама 18+ ya.rekonfa.ru О рекламодателе

Web Security #10. SSRF: когда сервер делает запрос вместо пользователя Представим сервис, который скачивает картинку по URL. Пользователь отправляет:

POST /download HTTP/1.1
Content-Type: application/json

{
    "url": "https://example.com/image.jpg"
}

Сервер делает запрос:

Web Server
    |
    | GET https://example.com/image.jpg
    v
example.com

Всё нормально. Но теперь представим архитектуру:

Internet
   |
   v
Web Server
   |
   +---- Internal API
   |
   +---- Database
   |
   +---- Admin panel

Web Server может иметь доступ к внутренним сервисам. Обычный пользователь — нет. Если пользователь может управлять URL, возникает важный вопрос:

Может ли он заставить сервер обратиться к внутреннему ресурсу?

Это и есть основная идея SSRF — Server-Side Request Forgery. Проблема не в самом HTTP-запросе. Проблема в том, что:

Пользователь
     |
     | управляет URL
     v
Web Server
     |
     | имеет другие сетевые права
     v
Internal Network

Сервер становится посредником между пользователем и внутренней сетью. Защита обычно включает:

Allowlist destinations
Network segmentation
Запрет доступа к внутренним адресам
Безопасную обработку redirects
Контроль DNS и URL

Практика: Используй специальную SSRF-лабораторию. Нарисуй схему:

Клиент
  ↓
Web application
  ↓
Что может увидеть web application?

Это упражнение часто полезнее, чем простое запоминание SSRF payload'ов.

2 курса в подарок при обучении команды — Я.Практикум Расширьте навыки команды без доплат. Получите 3 курса Яндекс Практикума по цене 1 Развивайте команду по трём направлениям — платите за одно. Так тоже можно. Оформите обучение в Практикуме для себя или сотрудников до 31 октября и получите бесплатно 2 курса: ✅ «Базовые навыки работы с ИИ» — о том, как применять ИИ в ежедневных рабочих задачах. ✅ «Экономика и бизнес-модель продукта» — о юнит-экономике и способах монетизации продуктов. Подберите обучение под любой запрос: в каталоге Практикума 180+ актуальных программ по ИИ, разработке, менеджменту, аналитике и другим направлениям. С нами уже сотрудничают 6000+ компаний. Начните и вы развивать команду с фокусом на бизнес-результат. Оставить заявку и получить бонусы Узнать больше #реклама 16+ practicum.yandex.ru О рекламодателе

Web Security #9. Path Traversal Представим сайт с загрузкой документов:

/download?file=report.pdf

Сервер хранит документы:

/app/files/
    report.pdf
    invoice.pdf
    manual.pdf

Приложение получает имя файла:

file = request.args["file"]

open("/app/files/" + file)

Разработчик ожидает:

report.pdf

Но проблема в том, что file контролирует пользователь. Приложение должно гарантировать:

Файл находится внутри /app/files/

а не просто добавлять пользовательский текст к пути. Если проверка сделана неправильно, пользователь может попытаться заставить приложение обратиться к файлу за пределами разрешённого каталога. Именно это называется Path Traversal. Упрощённая схема:

/app/files/
     |
     +-- report.pdf
     |
     +-- invoice.pdf

Приложение должно разрешать
только файлы из этого каталога.

Безопаснее:

base = "/app/files/"
requested = resolve(base, user_input)

if not requested.startswith(base):
    return 403

Конкретная реализация зависит от языка и framework, но идея одна:

Нельзя позволять пользовательскому вводу произвольно определять путь к файлу.

Практика: В учебной лаборатории найди endpoint:

/download?file=...

Посмотри:

что принимает параметр;
как он используется;
есть ли проверка пути;
что происходит при указании несуществующего файла.

Услуги дата-центра в Москве Размещение и аренда серверного оборудования в дата-центре. 👍 4 современных дата-центра в Москве. 👍 Лицензированный оператор связи. 👍 Индивидуальные конфигурации выделенных серверов под задачи клиента. 👍 Круглосуточная техническая поддержка в Телеграм, без ботов. Узнать цену #реклама 16+ itsoft.ru О рекламодателе

Web Security #8. CSRF: когда браузер отправляет запрос не по твоей воле Представим, что ты вошёл на:

bank.example

У браузера есть:

Cookie: session=abc123

Теперь ты открываешь другой сайт. Он может попытаться заставить браузер отправить запрос к bank.example. Например:

POST /change-email

Если браузер автоматически прикладывает нужную cookie, сервер может увидеть:

session=abc123

и решить:

Это запрос Alice.

Хотя Alice сама его не инициировала. Это и есть основная идея CSRF. Упрощённо:

Alice вошла в банк
        |
        v
Браузер хранит session cookie
        |
        v
Alice открывает другой сайт
        |
        v
Другой сайт пытается вызвать действие
        |
        v
Браузер отправляет запрос
        |
        v
Bank получает cookie

Один из классических механизмов защиты — CSRF token. Например:

<input
    type="hidden"
    name="csrf"
    value="random-token"
>

Сервер знает правильный token и проверяет его. Другой важный механизм:

SameSite cookie

Он ограничивает некоторые cross-site сценарии отправки cookies. Важно не путать:

XSS

означает, что атакующий добился выполнения JavaScript в контексте приложения.

CSRF

означает, что браузер жертвы может отправить нежелательный запрос с её полномочиями. Практика: Открой CSRF-лабораторию. Посмотри:

какой запрос изменяет состояние;
есть ли CSRF token;
проверяет ли сервер token;
какие cookie используются.

Олимпиада Высшая проба: промышленное программирование Участвуй в олимпиаде школьников 9-11 класса по промышленному программированию от Яндекса и ВШЭ. Победителям — БВИ или 100 баллов по профильному предмету в топовых вузах России. Регистрируйся до 20 октября! Узнать больше #реклама olymp.hse.ru О рекламодателе

Web Security #7. XSS: когда текст становится кодом Представим страницу профиля. Пользователь вводит имя:

Alice

Сервер сохраняет его. Затем приложение формирует HTML:

<h1>Hello, Alice</h1>

Всё нормально. Проблема появляется, когда приложение неправильно обрабатывает пользовательский ввод и браузер начинает воспринимать его как HTML или JavaScript. Например, приложение делает:

element.innerHTML = username;

Здесь username приходит от пользователя. Это опасный подход, если содержимое не должно быть HTML. Почему? Потому что браузер интерпретирует значение innerHTML как HTML-разметку. Вместо:

Привет, Alice

в страницу может попасть HTML, который браузер обработает как разметку. Если через такую точку удаётся выполнить JavaScript, это уже XSS. XSS бывает разных типов:

Stored XSS
Reflected XSS
DOM-based XSS

Например, при Stored XSS пользовательский ввод сохраняется на сервере. Другой пользователь открывает страницу. Сервер возвращает сохранённые данные. Браузер обрабатывает их как код. Схема:

Attacker input
      ↓
Application
      ↓
Database
      ↓
Victim browser
      ↓
JavaScript execution

Защита зависит от контекста, но основные методы:

Output encoding
Безопасная работа с DOM
Sanitization
Content Security Policy

Практика: Возьми учебную XSS-лабораторию. Найди место, куда вводится текст. Посмотри:

куда попадает ввод;
как сервер его возвращает;
как браузер его отображает.

Главный вопрос:

Может ли пользовательский текст оказаться там, где браузер ожидает HTML или JavaScript?

Встречай смартфон Honor — с выгодой для себя! ✅ Стильный дизайн ✅ Заряд надолго ✅ Качественные фото ✅ Быстрая и плавная работа Выбирай свой Honor по привлекательной цене! Купить #реклама market.yandex.ru О рекламодателе

Web Security #6. SQL Injection Представим страницу поиска:

/search?q=phone

Приложение получает phone. Разработчик хочет найти товары:

SELECT *
FROM products
WHERE name = 'phone';

Проблема появляется, если SQL строится обычной конкатенацией строк:

query = "SELECT * FROM products WHERE name = '" + user_input + "'"

Почему это опасно? Потому что приложение смешивает две разные вещи:

SQL-код
+
данные пользователя

Если специальные символы из пользовательского ввода начинают влиять на структуру SQL-запроса, пользовательский ввод перестаёт быть просто данными. Это и есть основная идея SQL Injection. Правильный подход — parameterized query:

cursor.execute(
    "SELECT * FROM products WHERE name = ?",
    (user_input,)
)

Теперь база данных получает отдельно:

SQL:
SELECT * FROM products WHERE name = ?

Данные:
phone

И не должна воспринимать содержимое phone как SQL-код. Главный принцип:

Небезопасно:
данные + SQL-код смешиваются

Безопасно:
SQL-код и данные передаются отдельно

Практика: Возьми OWASP Juice Shop, DVWA или лаборатории PortSwigger. Найди SQL Injection лабораторию. Твоя первая задача — не запомнить payload. Нужно понять цепочку:

HTTP parameter
      ↓
Application
      ↓
SQL query
      ↓
Database
      ↓
Response

Когда ты понимаешь эту цепочку, становится понятно, где возникает уязвимость.

Бесплатный курс по дизайну: веб, графический и UX/UI Что внутри: — старт в дизайне с нуля — личный наставник и поддержка по ходу обучения — доступ к платформе с уроками и заданиями — 4+ работ, которые можно добавить в портфолио — чат с участниками и единомышленниками — проверка домашних заданий и разбор ошибок — сертификат по итогам курса Подойдёт тем, кто: — хочет зайти в цифровую без большого опыта — задумывается о смене профессии — хочет освоить навык, который можно применять на практике — ищет понятный и спокойный старт в дизайне Для кого: — для новичков без подготовки — для тех, кто давно хочет попробовать себя в дизайне — для тех, кто ищет первый шаг на удаленке Узнать больше #реклама 16+ ydaev.ru О рекламодателе

Web Security #5. IDOR: когда ID недостаточно Представим интернет-магазин. У Alice есть заказ:

Order #1001

Браузер получает его через:

GET /api/orders/1001 HTTP/1.1
Cookie: session=alice

Сервер возвращает:

{
  "id": 1001,
  "owner": "alice",
  "total": 50
}

Теперь Alice меняет номер:

GET /api/orders/1002 HTTP/1.1
Cookie: session=alice

И сервер возвращает:

{
  "id": 1002,
  "owner": "bob",
  "total": 900
}

Вот здесь проблема. Почему сервер отдал чужой заказ? Скорее всего, логика была примерно такой:

order = database.get_order(order_id)
return order

Сервер получил 1002, нашёл заказ и просто вернул его. Но нужно проверить владельца:

order = database.get_order(order_id)

if order.owner_id != current_user.id:
    return 403

return order

То есть недостаточно спросить:

Существует ли заказ 1002?

Нужно спросить:

Имеет ли Alice право видеть заказ 1002?

Это пример Broken Access Control. А конкретно такой сценарий часто называют IDOR — Insecure Direct Object Reference. Практика: В учебном приложении найди запрос вроде:

/api/orders/123
/api/users/42
/api/documents/15

Измени идентификатор. Если сервер показывает объект другого пользователя — ты обнаружил проблему контроля доступа. Проверяй такое только в собственных системах или разрешённых лабораториях.

Почувствуйте ритм Дубая с отелями Jumeirah Семейный отдых обретает свой ритм - время для открытий, игр и особенных моментов вместе. Узнать больше #реклама jumeirah.com О рекламодателе

Web Security #4. Authentication и Authorization Эти два понятия очень легко перепутать. Authentication отвечает на вопрос:

Кто ты?

Например:

username: alice
password: ********

Сервер проверяет пароль и говорит:

Это Alice.

Это authentication. Authorization отвечает на другой вопрос:

Что Alice разрешено делать?

Например:

Alice:
  читать свой профиль       да
  изменить свой профиль     да
  удалить другого user      нет
  открыть admin panel       нет

Представим запрос:

GET /admin/users HTTP/1.1
Cookie: session=alice123

Сервер видит:

alice123 → Alice

Authentication пройдена. Но Alice — обычный пользователь. Поэтому сервер должен проверить authorization и вернуть:

HTTP/1.1 403 Forbidden

Проблема возникает, если сервер проверяет только наличие валидной сессии:

if session_is_valid():
    return admin_users()

Получается:

Пользователь вошёл?
        |
       да
        |
        v
Отдать admin_users()

Нужна дополнительная проверка:

if not session_is_valid():
    return 401

if not current_user.is_admin:
    return 403

return admin_users()

Запомни простое правило:

Authentication:
"Кто ты?"

Authorization:
"Что тебе разрешено?"

Многие серьёзные ошибки доступа начинаются именно с того, что эти две проверки смешивают. Практика: В учебном приложении найди страницу или API администратора. Посмотри:

Что происходит без авторизации?
Что происходит после обычного login?
Что происходит у администратора?

Сравни HTTP-ответы.