owned this note
owned this note
Published
Linked with GitHub
---
title: OWASP TOP 10 Day 5
tags: OWASP TOP 10
slideOptions:
transition: fade
center: true
parallaxBackgroundImage: 'https://hackmd.io/_uploads/SJhktzri2.png'
---
<style>
div#doc { max-width: 60%; }
.reveal {
font-size: 24px;
}
</style>
# OWASP TOP 10 Day 5
---
## Атаки на клиентскую часть
Основные виды атак на клиентов, через клиентскую часть приложения это:
- Cross-site scripting (XSS)
- Cross-site request forgery (CSRF)
- Clickjacking (UI redressing)
- Cross-origin resource sharing (CORS) Misconfiguration
- DOM-based vulnerabilities
---
### Cross-site scripting (XSS)
Межсайтовый скриптинг (также известный как XSS) - это уязвимость веб-безопасности, позволяющая злоумышленнику компрометировать взаимодействие пользователей с уязвимым приложением. Она позволяет злоумышленнику обходить политику одного источника (Same Origin Policy (SOP)), которая предназначена для разделения различных веб сайтов друг от друга.
---
Уязвимости межсайтового скриптинга, как правило, позволяют злоумышленнику маскироваться под пользователя-жертву, выполнять любые действия, которые может выполнить пользователь, и получать доступ к любым данным пользователя. Если пользователь-жертва имеет привилегированный доступ внутри приложения, то атакующий может получить полный контроль над всей функциональностью и данными приложения.
---
#### Как работает XSS?
Межсайтовый скриптинг работает путем манипулирования уязвимым веб-сайтом, чтобы он возвращал пользователям вредоносный JavaScript. Когда вредоносный код выполняется внутри браузера жертвы, злоумышленник может полностью скомпрометировать их взаимодействие с приложением.
---
#### Типы XSS-атак?
Существует три основных типа XSS-атак. Это:
---
- Отраженный XSS, где вредоносный скрипт происходит из текущего HTTP запроса.
---
- Хранимый XSS, где вредоносный скрипт приходит из хранилища данных веб-сайта.
---
- Dom-based XSS, где уязвимость существует в клиентском коде, а не в коде сервера.
---
Dom based XSS example
https://portswigger.net/web-security/cross-site-scripting/dom-based/lab-document-write-sink
XSS with CSRF bypass example
https://portswigger.net/web-security/cross-site-scripting/exploiting/lab-perform-csr
---
#### Как защищаться от атак XSS
Предотвращение межсайтового скриптинга в некоторых случаях тривиально, но может быть намного сложнее в зависимости от сложности приложения и способов обработки данных, контролируемых пользователем.
В целом, эффективное предотвращение уязвимостей XSS, чаще всего, предполагает сочетание следующих мер:
- Ввод фильтра для входных данных. В момент получения пользовательского ввода, фильтровать как можно строже, основываясь на том, что ожидается или допустимо.
- Кодировать данные на выходе. В момент, когда пользовательские данные выводятся в ответах HTTP, кодируйте выходные данные, чтобы предотвратить их интерпретацию в качестве активного содержимого. В зависимости от контекста вывода, это может потребовать применения комбинаций HTML, URL, JavaScript и CSS кодирования.
---
- Используйте соответствующие заголовки ответов. Для предотвращения XSS в ответах HTTP, которые не предназначены для HTML или JavaScript, можно использовать заголовки `Content-Type` и `X-Content-Type-Options`, чтобы убедиться, что браузеры интерпретируют ответы так, как вы собираетесь.
- Политика безопасности контента (англ. Content Security Policy (CSP)). В качестве последнего пункта защиты вы можете использовать Content Security Policy (CSP), чтобы уменьшить серьезность любых XSS-уязвимостей, которые все еще могут встречаться.
---
## Упражнения
### Упражнение 1
BWAPP XSS
### Упражнение 2
Хранение XSS в HTML-контексте без кодировки - [https://portswigger.net/web-security/cross-site-scripting/stored/lab-html-context-nothing-encoded](https://portswigger.net/web-security/cross-site-scripting/stored/lab-html-context-nothing-encoded) (Сложность: низкая)
### Упражнение 3
https://portswigger.net/web-security/cross-site-scripting/stored/lab-html-context-nothing-encoded
---
### Упражнение 4
https://portswigger.net/web-security/cross-site-scripting/contexts/lab-href-attribute-double-quotes-html-encoded
## Дополнительная информация
[https://portswigger.net/web-security/cross-site-scripting/cheat-sheet](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
---
# A08:2021 Software and Data Integrity Failures
Новая категория для 2021 года посвящена уязвимостям и рискам, связанными с обновлениями ПО, критическими данными и конвейерами CI/CD без проверки целостности.
---
---
Как предотвратить
- Используйте цифровые подписи или аналогичные механизмы для проверки того, что программное обеспечение или данные получены из ожидаемого источника и не были изменены.
- Убедитесь, что библиотеки и зависимости, такие как npm или Maven, используют надежные хранилища. Если у вас более высокий профиль риска, подумайте о размещении внутреннего проверенного репозитория с известными качествами.
- Убедитесь, что средство обеспечения безопасности цепочки поставок программного обеспечения, такое как проверка зависимостей OWASP или OWASP Cyclone DX, используется для проверки того, что компоненты не содержат известных уязвимостей.
---
- Убедитесь, что существует процесс проверки изменений кода и конфигурации, чтобы свести к минимуму вероятность того, что вредоносный код или конфигурация могут быть внедрены в ваш программный конвейер.
- Убедитесь, что ваш конвейер CI/CD имеет надлежащее разделение, конфигурацию и контроль доступа, чтобы обеспечить целостность кода, проходящего через процессы сборки и развертывания.
- Убедитесь, что неподписанные или незашифрованные сериализованные данные не отправляются ненадежным клиентам без какой-либо проверки целостности или цифровой подписи для обнаружения подделки или воспроизведения сериализованных данных.
---
Примеры сценариев атак
- Сценарий №1 Обновление без подписи: Многие домашние маршрутизаторы, телевизионные приставки, прошивки устройств и другое не проверяют обновления с помощью подписанной прошивки. Неподписанная прошивка становится все большей мишенью для злоумышленников и, как ожидается, будет только ухудшаться. Это вызывает серьезную озабоченность, так как часто нет никакого механизма для исправления, кроме как исправить в будущей версии и подождать, пока предыдущие версии устареют.
---
- Сценарий №2 Вредоносное обновление SolarWinds: Известно, что национальные государства атакуют механизмы обновления, причем недавней заметной атакой является атака SolarWinds Orion. У компании, разрабатывающей программное обеспечение, были безопасные процессы сборки и обновления целостности. Тем не менее, их удалось подорвать, и в течение нескольких месяцев фирма распространяла целенаправленное вредоносное обновление более чем 18 000 организаций, из которых пострадало около 100. Это одно из самых далеко идущих и серьезных нарушений такого рода в истории.
---
- Сценарий №3 Небезопасная десериализация: Приложение React вызывает набор микросервисов Spring Boot. Будучи функциональными программистами, они старались обеспечить неизменность своего кода. Решение, которое они придумали, заключается в сериализации состояния пользователя и передаче его туда и обратно с каждым запросом. Злоумышленник замечает подпись "rO0" Java object (в base64) и использует средство Java Serial Killer для удаленного выполнения кода на сервере приложений.
---
## Сериализация
Процесс перевода какой-либо структуры данных в последовательность байтов
Десериализация - обратная процедура - восстановление структуры данных из последовательности байтов
---
### PHP Deserialize
**функции**: serialize(obj)(объект), unserialize(string)(принимает строку и на основе ее конструирует обратный объект)
Использует полутекстовый формат.
Пример сериализованной строки:
`a:5:{i:0;s:3:“aaa”;i:1;i:1;i:2;b:1;i:3;d:3.5;i:4;a:1:{s:3:“xxx”;s:3:“zzz”;}}`
---
#### PHP deserialization - Как защищаться?
- Не десериализовывать пользовательские данные
- Начиная с PHP 7 добавлен второй параметр в функцию unserialize, в котором разработчик может указать какие классы разрешены к созданию при десериализации. Значение FALSE приводит к тому, что объекты классов не будут десериализоваться вообще.
---
### Другие десериализации
- Java
Подробнее о процессе сериализации: [https://habr.com/ru/post/60317/](https://habr.com/ru/post/60317/)
---
Пример класса:
```
import java.io.Serializable;
class TestSerial implements Serializable {
public byte count = 0;
public byte version = 100;
}
```
---
Пример сериализованного объекта из класса:
```
AC ED 00 05 73 72 00 0A 53 65 72 69 61 6C 54 65
73 74 A0 0C 34 00 FE B1 DD F9 02 00 02 42 00 05
63 6F 75 6E 74 42 00 07 76 65 72 73 69 6F 6E 78
70 00 64
```
---
Давайте рассмотрим, что собой представляет каждый байт в сериализованном объекте. В начале идёт информация о протоколе сериализации:
- `AC ED`: STREAM_MAGIC. Говорит о том, что используется протокол сериализации.
- `00 05`: STREAM_VERSION. Версия сериализации.
- `0x73`: TC_OBJECT. Обозначение нового объекта.
---
На первом шаге алгоритм сериализации записывает описание класса ассоциированного с объектом. В примере был сериализован объект класса TestSerial, следовательно алгоритм начал записывать описание класса TestSerial.
- `0x72`: TC_CLASSDESC. Обозначение нового класса.
- `00 0A`: Длина имени класса.
- `53 65 72 69 61 6c 54 65 73 74`: TestSerial, имя класса.
- `A0 0C 34 00 FE B1 DD F9`: SerialVersionUID, идентификатор класса.
- `0x02`: Различные флаги. Этот специфический флаг говорит о том, что объект поддерживает сериализацию.
- `00 02`: Число полей в классе.
---
Теперь алгоритм записывает поле byte version = 100;.
- `0x42`: Код типа поля. 42 это «B», которое закреплено за Byte.
- `00 05`: Длина имени поля.
- `63 6F 75 6E 74 42`: count, имя поля.
---
Затем алгоритм записывает следующее поле, byte version = 100; и заканчивает описание полей класса.
- `0x42`: Код типа поля.
- `00 07`: Длина имени поля.
- `76 65 72 73 69 6F 6E`: version, имя поля.
- `0x78`: TC_ENDBLOCKDATA, конец опционального блока данных для объекта.
- `0x70`: TC_NULL, обозначает то что больше нет суперклассов, потому что мы достигли верха иерархии классов.
---
До этого алгоритм сериализации записывал описание классов ассоциированных с объектом. Теперь будут записаны фактические данные ассоциированные с объектом.
- `00`: Значение поля count - 0
- `64`: Значение поля Version - 100
---
Стандартная десериализация в Java делается с помощью readObject
```
FileInputStream fis = new FileInputStream("temp.out");
ObjectInputStream oin = new ObjectInputStream(fis);
Object ts = oin.readObject();
```
---
Генерируем объект класса CacheManager, в качестве initHook передаем туда объект класса CommandTask. После этого выполняется readObject класса CacheManager, который выполняет метод run класса CommandTask
Сериализованный массив имеет стандартный заголовок - **ACED**. это маркер сериализованных данных.
**ysoserial** - инструмент для составления цепочек гаджетов для стандартной Java десериализации
[https://github.com/frohoff/ysoserial](https://github.com/frohoff/ysoserial)
CommonsCollections1
**Как защищаться?**
-- Не десериализировывать недоверенные данные
-- Основная защита - разрешение на загрузку только определенных классов в десеализации. В стандартной реализации отсутствует. Можно рекомендовать делать с помощью библиотеки [https://github.com/ikkisoft/SerialKiller](https://github.com/ikkisoft/SerialKiller).
-- Переопределить `ObjectInputStream.html#resolveClass()`
-- Использовать java version 9+ и JEP 290 https://openjdk.org/jeps/290
`jdk.serialFilter=!example.somepackage.SomeClass;example.somepackage.*;`
Упражнение [https://portswigger.net/web-security/deserialization/exploiting/lab-deserialization-exploiting-java-deserialization-with-apache-commons](https://portswigger.net/web-security/deserialization/exploiting/lab-deserialization-exploiting-java-deserialization-with-apache-commons)
**Если используете другие форматы**
-- Не использовать
Castor (XML)
fastjson < v1.2.68 (JSON)
XMLDecoder in the JDK (XML)
XStream < v1.4.17 (JSON and XML)
YamlBeans < v1.16 (YAML)
--Настраивать
fastjson v1.2.68+ (JSON)
json-io (JSON)
Kryo < v5.0.0
SnakeYAML (YAML)
-- По умолчанию безопасно
fastjson2 (JSON)
jackson-databind (JSON)
Kryo v5.0.0+ (custom format)
YamlBeans v1.16+ (YAML)
XStream v1.4.17+ (JSON and XML)
https://cheatsheetseries.owasp.org/cheatsheets/Deserialization_Cheat_Sheet.html
- Dot.NET
soap, xml, BinaryFormatter
[ysoserial.net](http://ysoserial.net) - инструмент для составления цепочек гаджетов для различных сериализаторов .Net.
**Как защищаться?**
-- Не использовать BinaryFormatter
-- Не позволять данным от клиента определять тип объекта
- Python
Pickle and YAML
**Как защищаться?**
-- yaml.safe_load - безопасный аналог
-- Не использовать pickle
## Упражнения
https://portswigger.net/web-security/deserialization/exploiting/lab-deserialization-modifying-serialized-objects
https://portswigger.net/web-security/deserialization/exploiting/lab-deserialization-modifying-serialized-data-types
https://portswigger.net/web-security/deserialization/exploiting/lab-deserialization-using-application-functionality-to-exploit-insecure-deserialization
https://portswigger.net/web-security/deserialization/exploiting/lab-deserialization-arbitrary-object-injection-in-php
https://www.root-me.org/ru/Zadachi-i-problemy/Veb-server/PHP-Serialization
# A09:2021 Security Logic and Monitoring
Пассивные и активные методы обеспечения безопасности веб-приложений
## Проблемы логгирования и мониторинга
- регистрировать все ошибки входа, доступа и проверки данных на стороне сервера с указанием контекста, достаточного для выявления подозрительных или вредоносных действий, а также хранить их для последующего анализа;
- регистрировать события в формате, наиболее подходящем для обработки централизованной службой журналирования;
- использовать контроль целостности журналов аудита важных транзакций для предотвращения подмены или удаления данных, например, с помощью доступных только для добавления таблиц БД;
- использовать эффективные системы мониторинга и предупреждения для своевременного обнаружения подозрительных действий и реагирования на них;
- разработать или утвердить руководство по реагированию на инциденты и устранению их последствий, такое как NIST 800-61 rev2.
## Средства обеспечения логирования, мониторинга и противодействия угрозам
### Web Application Firewall (WAF)
Файрвол веб-приложений (англ. Web application firewall, WAF) — совокупность мониторов и фильтров, предназначенных для обнаружения и блокирования сетевых атак на веб-приложение.
Подходы к детектированию атак:
- Cигнатурный анализ
- Репутационный фильтр IP адресов
- Поведенческий анализ
Дополнительные возможности:
- Защита от DDoS
- Сканеры уязвимостей
Представители:
- Nemesida WAF / Nemesida WAF Free
- Валарм WAF
- Barracuda Networks WAF
- Akamai Technologies Kona
- Citrix Netscaler Application Firewall
- Alibaba Cloud
- F5 Big-IP ASM
- Amazon Web Services AWS WAF
- Fortinet FortiWeb
- Cloudbric
- Imperva SecureSphere
- Cloudflare
- Penta Security WAPPLES
- Radware AppWall
- ModSecurity (Open Source)
Полезные заметки по работе с WAF:
[https://owasp.org/www-pdf-archive/OWASP_Stammtisch_Frankfurt_WAF_Profiling_and_Evasion.pdf](https://owasp.org/www-pdf-archive/OWASP_Stammtisch_Frankfurt_WAF_Profiling_and_Evasion.pdf)
### Security Information and Event Management (SIEM)
SIEM - объединение двух терминов, обозначающих область применения ПО: SIM (Security information management) — управление информацией о безопасности, и SEM (Security event management) — управление событиями безопасности.
Технология SIEM обеспечивает анализ в реальном времени событий (тревог) безопасности, исходящих от сетевых устройств и приложений, и позволяет реагировать на них до наступления существенного ущерба.
SIEM системы, вне зависимости от производителя, обладают следующим функционалом:
- Агрегация данных;
- Корреляция событий ;
- Оповещение;
- Анализ и управления рисками безопасности;
- Проведение расследования инцидентов;
- Формирование отчётов;
- Реакция на атаки.
Источниками данных для SIEM систем являются:
- IDS/IPS системы
- Антивирусные программы
- Журналы событий операционных систем
- Межсетевые экраны
- Сканеры уязвимостей
- Системы инвентаризации
- Прокси-сервера
- Системы аутентификации
### Популярные решения
Зарубежные:
- HPE ArcSight
- IBM QRadar Security Intelligence Platform
- McAfee Enterprise Security Manager
- RSA NetWitness Suite
- Splunk Enterprise Security
- Trustwave SIEM Enterprise
Российские:
- Ankey SIEM
- Positive Technologies MaxPatrol SIEM
- RuSIEM
- НПО «Эшелон» КОМРАД
- СёрчИнформ SIEM
Сравнение SIEM систем:
- [https://www.anti-malware.ru/compare/SIEM-systems](https://www.anti-malware.ru/compare/SIEM-systems)
- [https://www.anti-malware.ru/compare/SIEM-systems-part2](https://www.anti-malware.ru/compare/SIEM-systems-part2)
## Прочие средства
- BAS (Breach Attack Simulation)
- IDS (Intrusion Detection System)
- IPS (Intrusion Prevention System)
- UTM (Unified Threat Management)
- UEBA/UBA (User [and Entity] Behavioral Analytics)
- SOC (Security Operations Center)
- NGFW (Next-Generation Firewall)
- CASB (Cloud access security broker)
- DLP (Data Leak Prevention)
- DNS-ФИЛЬТРЫ
- EDR (Endpoint Detection and Response)
- IGA (Identity Governance and Administration)
## Дополнительные материалы
- [Implement Security Logging and Monitoring (OWASP )](https://owasp.org/www-project-proactive-controls/v3/en/c9-security-logging)
# A10:2021 Server-Side Request Forgery (SSRF)
Подделка запросов на стороне сервера (также известная как SSRF) - это уязвимость веб-безопасности, которая позволяет злоумышленнику побудить серверное приложение делать HTTP-запросы к произвольному домену по выбору злоумышленника.
### Почему такие уязвимости появляются?
Целевое приложение может иметь функциональные возможности для импорта данных из URL-адреса, публикации данных на URL-адрес или иного чтения данных из URL-адреса, который может быть взломан. Атакующий модифицирует вызовы к этой функциональности, предоставляя совершенно другой URL или манипулируя тем, как строятся URL (обход путей и т.д.).
```php!
<?php
/**
* Check if the 'url' GET variable is set
* Example - http://localhost/?url=http://testphp.vulnweb.com/images/logo.gif
*/
if (isset($_GET['url'])){
$url = $_GET['url'];
/**
* Send a request vulnerable to SSRF since
* no validation is being done on $url
* before sending the request
*/
$image = fopen($url, 'rb');
/**
* Send the correct response headers
*/
header("Content-Type: image/png");
/**
* Dump the contents of the image
*/
fpassthru($image);}
```
Когда манипулируемый запрос поступает на сервер, код на стороне сервера подхватывает манипулируемый URL и пытается прочитать данные к измененному URL.
### Как предотвратить
Разработчики могут предотвратить SSRF, реализовав некоторые или все следующие элементы управления по защите:
С сетевого уровня
- Разделить функции удаленного доступа к ресурсам в отдельных сетях для уменьшения влияния SSRF.
- Применяйте политику брандмауэра “deny by default” или правила контроля доступа к сети, чтобы блокировать весь трафик интернета, кроме необходимого.
С прикладного уровня:
- Очищайте и проверяйте все входные данные клиента.
- Используйте схему URL-адреса, порт и пункт назначения с белым списком разрешений.
- Не отправляйте необработанные ответы клиентам.
- Отключите перенаправление HTTP.
- Следите за согласованностью URL-адресов, чтобы избежать атак, например, повторная привязка DNS и условия гонки “время проверки до времени использования” (TOCTOU).
### Примеры сценариев атак
Злоумышленники могут использовать SSRF для атаки на системы, защищенные брандмауэрами веб-приложений, брандмауэрами или сетевыми списками управления доступом, используя такие сценарии:
- Сценарий №1: Сканирование портов внутренних серверов. Если сетевая архитектура несегментирована, злоумышленники могут составить карту внутренних сетей и определить, открыты или закрыты порты на внутренних серверах по результатам подключения или по времени, затраченному на подключение или отклонение полезных данных SSRF.
- Сценарий №2: Раскрытие конфиденциальных данных. Злоумышленники могут получить доступ к локальным файлам (например, внутренней службы) для получения конфиденциальной информации, file:///etc/passwd</span> and http://localhost:28017/.
- Сценарий №3: Доступ к хранилищу метаданных облачных служб. У большинства облачных провайдеров есть хранилище метаданных, http://169.254.169.254/. Злоумышленник может прочитать метаданные для получения конфиденциальной информации.
- Сценарий №4: Компрометация внутренних служб. Злоумышленник может злоупотреблять внутренними службами для проведения дальнейших атак, например, удаленное выполнение кода (RCE) или отказ в обслуживании (DOS).
## Дополнительные материалы
- Новая эра SSRF атак (Видео): [https://www.youtube.com/watch?v=D1S-G8rJrEk](https://www.youtube.com/watch?v=D1S-G8rJrEk)
- Новая эра SSRF атак (Слайды): [https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf](https://www.blackhat.com/docs/us-17/thursday/us-17-Tsai-A-New-Era-Of-SSRF-Exploiting-URL-Parser-In-Trending-Programming-Languages.pdf)
- SSRF Библия v2: [https://cheatsheetseries.owasp.org/assets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet_SSRF_Bible.pdf](https://cheatsheetseries.owasp.org/assets/Server_Side_Request_Forgery_Prevention_Cheat_Sheet_SSRF_Bible.pdf)
- [PayloadsAllTheThings - Server Side Request Forgery](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/Server%20Side%20Request%20Forgery)
- [Техники эксплуатации уязвимостей Blind SSRF](https://blog.assetnote.io/2021/01/13/blind-ssrf-chains/)
## Упражнения
- [https://portswigger.net/web-security/ssrf](https://portswigger.net/web-security/ssrf)
### Упражнение 1
Базовая SSRF против локального сервера - [https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-localhost](https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-localhost)
### Упражнение 2
https://portswigger.net/web-security/ssrf/lab-basic-ssrf-against-backend-system
### Упражнение 3
https://portswigger.net/web-security/ssrf/lab-ssrf-with-blacklist-filter
#OWASP
Google Drive
Gist
Clipboard
Sign in with Wallet
