ИнфоБез

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-ответы.

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

Web Security #3. Cookie и Session HTTP не помнит предыдущие запросы. Допустим, ты отправил:

POST /login HTTP/1.1

username=alice&password=secret

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

Это Alice.

Но через секунду браузер отправляет:

GET /profile HTTP/1.1

Как сервер поймёт, что это снова Alice? Для этого часто используется session cookie. После успешного входа сервер может ответить:

HTTP/1.1 200 OK
Set-Cookie: session=abc123

Браузер сохраняет cookie. Следующий запрос:

GET /profile HTTP/1.1
Host: example.com
Cookie: session=abc123

Сервер смотрит:

abc123 → Alice

И понимает, кто отправил запрос. Упрощённо:

Login
  |
  v
Server создаёт session
  |
  v
Browser получает cookie
  |
  v
Browser отправляет cookie с последующими запросами
  |
  v
Server определяет пользователя

Теперь становится понятно, почему защита cookie так важна. Например:

Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax

Secure означает, что cookie должна отправляться через HTTPS. HttpOnly запрещает обычному JavaScript читать cookie. SameSite ограничивает некоторые cross-site запросы. Главная мысль: Если session cookie позволяет серверу узнать пользователя, то получение этой cookie может дать доступ к его сессии. Поэтому session management — важная часть Web Security. Практика: Открой DevTools:

Application
→ Cookies

Найди cookie, которая появляется после входа. Посмотри:

Name
Value
Secure
HttpOnly
SameSite

Не меняй cookie на реальных сервисах. Для экспериментов используй собственное приложение или учебную лабораторию.

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

Web Security #2. HTTP: GET, POST и параметры В прошлом посте мы увидели простой HTTP-запрос:

GET /profile?id=123 HTTP/1.1
Host: example.com

Разберём его подробнее. GET — это HTTP-метод. /profile — путь, по которому обращается браузер. id=123 — параметр. Сервер получает примерно такую информацию:

Метод: GET
Путь: /profile
Параметр id: 123

Но данные можно отправлять не только через URL. Например, форма входа:

POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded

username=alice&password=secret

Здесь логин и пароль находятся в теле запроса. Получается:

GET
    данные часто находятся в URL

POST
    данные обычно находятся в body

Но важно понимать: POST не означает «безопасно». Если приложение принимает:

POST /change-email HTTP/1.1

email=alice@example.com

то пользователь всё равно контролирует значение email. Поэтому сервер должен проверить:

1. Кто отправил запрос?
2. Авторизован ли пользователь?
3. Имеет ли он право менять email?
4. Корректно ли значение email?

HTTP ничего этого автоматически не проверяет. HTTP просто доставляет данные от клиента к серверу. А безопасность должна обеспечиваться приложением. Практика: Открой DevTools → Network. Найди:

GET-запрос
POST-запрос

Для каждого посмотри:

Method
URL
Query Parameters
Request Headers
Request Body
Response

Попробуй объяснить каждую часть запроса своими словами. Это базовый навык, без которого дальше изучать Web Security будет сложно.

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

Solar JSOC - Флагманский SOC с гарантией Гарантии крупнейшего коммерческого SOCа России теперь доступны вам. Узнать больше

Три основных типа тестирования на проникновение Черный ящик (Black Box): • При черном ящике тестировщику предоставляется минимум информации о системе или сети, которую он собирается тестировать. • Тестировщик должен использовать все доступные методы и инструменты для сбора информации и выявления уязвимостей, таким образом, имитируя действия реального злоумышленника. Белый ящик (White Box): • При белом ящике тестировщику предоставляется полная информация о системе или сети, включая архитектуру, код и другие технические детали. • Тестировщик может использовать эту информацию для более глубокого анализа и проверки уязвимостей, что позволяет более точно сосредоточиться на критических областях. Серый ящик (Gray Box): • Сочетает в себе элементы как черного, так и белого ящиков. Тестировщику предоставляется частичная информация о системе или сети. • Это позволяет тестировщику иметь некоторое представление о системе, но при этом сохранять элемент неожиданности, как в черном ящике.

Средства криптографической защиты информации (СКЗИ) — комплекс аппаратных, программных или комбинированных решений, предназначенных для обеспечения безопасности информации путем ее шифрования и других криптографических методов. Основные функции СКЗИ: Шифрование данных — процесс преобразования данных в форму, недоступную для несанкционированного доступа, с использованием ключа шифрования. Шифрование может быть симметричным (один ключ для шифрования и дешифрования) или асимметричным (разные ключи для шифрования и дешифрования). Цифровая подпись — технология, позволяющая удостоверить подлинность и целостность данных, а также подтвердить авторство сообщения. Это достигается с помощью закрытого и открытого ключей. Контроль целостности данных — механизмы, обеспечивающие защиту данных от несанкционированных изменений. Обычно используются криптографические хеш-функции, которые вычисляют уникальное значение для каждого сообщения. Аутентификация — процесс подтверждения подлинности пользователя или устройства с использованием криптографических механизмов. Это может включать проверку сертификатов, паролей или биометрических данных. Управление ключами — процессы генерации, хранения, распределения и уничтожения криптографических ключей, которые обеспечивают безопасность криптографических операций. Примеры СКЗИ: Программные: TrueCrypt, VeraCrypt, BitLocker. Аппаратные: криптографические токены, смарт-карты, HSM (Hardware Security Module). Комбинированные средства: VPN-решения с встроенным шифрованием, такие как IPsec или TLS/SSL.

YaC/e 2026: кто и как будет учить в 2030 году Обсудим будущее преподавания на онлайн-конференции Яндекса YaC/e 2026. 30 сентября. Участие бесплатно, вышлем сертификат участника! Регистрируйтесь до 29 сентября. Узнать больше

LINUX FORENSICS #7 — MINIMAL TRIAGE Базовый набор: date -u hostname uname -a cat /etc/os-release who last -a ps auxf ss -tulpn ss -ntp ip addr ip route systemctl list-timers --all systemctl list-unit-files --state=enabled crontab -l sudo crontab -l journalctl --since "24 hours ago" После сбора: Система ↓ Пользователи ↓ Процессы ↓ Сеть ↓ Логи ↓ Persistence ↓ Файлы ↓ Timeline ↓ IOC Не удаляем подозрительные файлы до их фиксации и анализа.

Москвич М70 Москвич М70 — современный городской кроссовер с двухлитровым турбодвигателем, 9- ступенчатым «автоматом», точной настройкой шасси и современной мультимедиа с Apple CarPlay / Android Авто. Пройдите тест-драйв и убедитесь: время компромиссов закончилось. Москвич М70 от 2 539 000 ₽.* «Москвич». Точность решений. Узнать больше #реклама moskvich-m.ru О рекламодателе

LINUX FORENSICS #6 — ФАЙЛЫ Недавно изменённые файлы: find /etc /tmp /var/tmp /home \ -type f -mtime -1 -ls 2>/dev/null По конкретной дате: find / -xdev -type f \ -newermt '2026-09-17 00:00:00' \ -ls 2>/dev/null Подозрительный файл: file suspicious stat suspicious sha256sum suspicious Для ELF: readelf -h suspicious strings -n 8 suspicious Не запускайте подозрительный файл на исследуемой системе. Фиксируем: путь → время → владелец → права → SHA-256 → содержимое