OWASP TOP 10 Day 4

--- title: OWASP TOP 10 Day 4 tags: OWASP TOP 10 slideOptions: transition: fade center: true parallaxBackgroundImage: 'https://hackmd.io/_uploads/SJhktzri2.png' --- # OWASP TOP 10 Day 4 # A04:2021 Insecure Design Insecure Design - это обширная категория, представляющая различные недостатки, причину возникновения которых можно описать “отсутствующим или неэффективным дизайном управления”. Примеры уязвимостей небезопасного дизайна: - Отсутствие надлежащей авторизации и аутентификации - Недостаточная валидация ввода - Чрезмерное раскрытие данных - Недостаточное протоколирование и мониторинг - Небезопасные API и интерфейсы - Игнорирование уязвимостей бизнес-логики Стратегии устранения: - Безопасный жизненный цикл разработки - Аутентификация и авторизация - Проверка достоверности вводимых данных - Минимизация данных - Протоколирование и мониторинг - Безопасные API ## Упражнения https://portswigger.net/web-security/authentication/other-mechanisms/lab-password-reset-broken-logic # A05:2021 Security Misconfiguration Множественные проблемы конфигурации приложения, фреймворков, веб-серверов и пр. ## Уязвимости конфигураций ### Почему такие уязвимости появляются? Уязвимости конфигурации приложения и его компонентов весьма разнообразны, что нельзя назвать одну или несколько причин их возникновения. Наиболее частыми причинами возникновения уязвимостей являются случаи когда: - любой из компонентов приложения недостаточно защищен или разрешения облачных сервисов некорректно настроены; - включены или присутствуют лишние функции (например, неиспользуемые порты, службы, страницы, учетные записи или привилегии); - учетные записи и пароли, создаваемые по умолчанию, используются без изменений; - обработка ошибок позволяет осуществить трассировку стека или получить слишком подробные сообщения об ошибках; - отключены или некорректно настроены последние обновления безопасности; - не выбраны безопасные значения параметров защиты серверов приложений, фреймворков (например, Struts, Spring, [ASP.NET](http://ASP.NET)), библиотек и т. п.; - сервер не использует безопасные заголовки или директивы, а также если они некорректно настроены; - ПО устарело или имеет компоненты с известными уязвимостями. ### Примеры узвимостей приложений #### Уязвимости раскрытия конфиденциальной информации - [Java Stack trace](https://hackerone.com/reports/41469) (Do you want to see my big beanstack.io ?) - [PHP Stack trace](https://hackerone.com/reports/150018) - [Apache Status](https://hackerone.com/reports/541347) ### Уязвимости присущие веб-фреймворкам Абсолютное большинство фреймворков имеют файлы конфигурации, конфигурацию по умолчанию и параметры безопасности, а также плагины и модули влияющие на безопасность всего приложения. Все эти компоненты могут иметь не эталонные значения и нести угрозу из-за некорректной настройки функций обеспечения безопасности. Примеры: - [Spring Boot Actuator](https://www.acunetix.com/vulnerabilities/web/spring-boot-actuator/) - [ASP.NET application trace enabled](https://www.acunetix.com/vulnerabilities/web/asp-net-application-trace-enabled/) - [RoR Security](https://guides.rubyonrails.org/security.html) - [Apache Tomcat Manager](https://www.tenable.com/plugins/was/98525) ### Уязвимости конфигурации коробочных приложений Примеры: - [Gitlab Directory Traversal](https://snyk.io/vuln/SNYK-DEBIANUNSTABLE-GITLAB-560292) - [Jenkins weak password](https://www.acunetix.com/vulnerabilities/web/jenkins-weak-password/) - [Jira SSRF](https://jira.atlassian.com/browse/JRASERVER-69793) ### Уязвимости присущие веб-серверам Зачастую веб-серверы страдают от уязвимостей ошибок конфигурации не меньше приложений, работающих на их основе. Популярные веб-серверы имеют весьма гибкие возможности настройки, что приводит и к плачевным последствиям в случае ошибок возникающих в их мощном функционале. Примеры - Общедоступный php-fpm ``` 47: fastcgi_pass $server_addr:9000; ``` - Path traversal при использовании alias ``` location /i/ { alias /data/w3/images/; } ``` `/i/top.gif` => `/data/w3/images/top.gif` ``` location /i { alias /data/w3/images/; } ``` `/i../app/config.py` => `/data/w3/app/config.py` ## Как избежать уязвимостей конфигурации? Необходимо реализовать процесс безопасной настройки, включая: - воспроизводимость процессов для быстрого создания безопасных, изолированных сред. Среды для разработки, контроля качества и эксплуатации должны быть настроены одинаково, но иметь разные учетные данные. Процессы должны быть автоматизированы для минимизации затрат на создание новых безопасных сред; - использование платформ только с необходимым набором функций, компонентов, документации и образцов. Удалите или не устанавливайте лишние компоненты или фреймворки; - проверку и актуализацию параметров настройки безопасности в соответствии с выпускаемыми бюллетенями, обновлениями и исправлениями (см. A9:2017-Использование компонентов с известными уязвимостями), а также проверку разрешений облачных хранилищ (например, для контейнеров S3); - создание сегментированной архитектуры приложения, обеспечивающей эффективное разграничение компонентов или клиентов с помощью контейнеризации или облачных групп безопасности; - использование безопасных директив для клиентов, например, Безопасных заголовков; - автоматизацию проверки эффективности используемых конфигураций и настроек во всех средах. ## Дополнительные материалы - [Разбор уязвимой конфигурации веб-сервера Nginx (Задания №5. NGINX config)](https://habr.com/ru/company/dsec/blog/461077/) - [Обнаружение и перечисление контейнеров Amazon S3](https://blog.websecurify.com/2017/10/aws-s3-bucket-discovery.html) - [Руководство по настройке заголовков безопасности](https://habr.com/ru/company/southbridge/blog/471746/) ### Примеры из Тинькофф Банка [https://jira.tcsbank.ru/browse/APPSEC-1302](https://jira.tcsbank.ru/browse/APPSEC-1302) - Nginx Alias Traversal ## Упражнения - [https://portswigger.net/web-security/information-disclosure](https://portswigger.net/web-security/information-disclosure) ### Упражнение 1 Раскрытие информации в истории контроля версий - [https://portswigger.net/web-security/information-disclosure/exploiting/lab-infoleak-in-version-control-history](https://portswigger.net/web-security/information-disclosure/exploiting/lab-infoleak-in-version-control-history) (Сложность: средняя) ### Упражнение 2 Раскрытие исходного кода через резервные файлы - [https://portswigger.net/web-security/information-disclosure/exploiting/lab-infoleak-via-backup-files](https://portswigger.net/web-security/information-disclosure/exploiting/lab-infoleak-via-backup-files) (Сложность: низкая) ## XXE Старые или плохо настроенные XML-процессоры обрабатывают ссылки на внешние сущности внутри документов. Эти сущности могут быть использованы для доступа к внутренним файлам через обработчики URI файлов, общие папки, сканирование портов, удаленное выполнения кода и отказ в обслуживании. ### XML ![](https://i.imgur.com/GC0KVk2.png) XML - это язык разметки, предназначенный для хранения, транспортировки и структурирования данных в человекочитаемом и машиночитаемом формате. ```xml <person> <name>John Doe</name> <age>30</age> </person> ``` ### DTD (document type definition) DTD - это способ определения структуры и законных элементов и атрибутов XML-документа ```dtd <!DOCTYPE person [ <!ELEMENT person (name, age)> <!ELEMENT name (#PCDATA)> <!ELEMENT age (#PCDATA)> ]> ``` DTD - document type difinition (типы данных) ### XML - Entity (Сущности) Entity - это компоненты, позволяющие представлять специальные символы или даже большие фрагменты данных в XML-документах (своеобразные переменные XML) Виды (сущности): - встроенные (символьные) - внутренние (сущности параметров) - внешние (сущности параметров) #### Встроенные Символьные сущности используются для представления специальных символов, которые имеют предопределенное значение в XML. Например: - `<` обозначает < (меньше, чем) - `>` обозначает > (больше, чем) - `&` представляет & (амперсанд) - `"` представляет " (двойную кавычку) - `'` представляет ' (одинарная кавычка) #### Внутренние Внутренние сущности определяются непосредственно в самом XML-документе. Они используются для представления строк текста, на которые можно ссылаться внутри документа. ```xml! <!DOCTYPE note [ <!ENTITY author "John Doe"> ]> <note> <from>&author;</from> <message>Hello, world!</message> </note> ``` #### Внешние Внешние сущности определяются вне основного XML-документа и, как правило, ссылаются на него с помощью системного идентификатора (URI). ```xml! <!DOCTYPE article [ <!ENTITY logo SYSTEM "logo.png"> ]> <article> <title>Introduction to XML</title> <image>&logo;</image> <content>This is a detailed explanation of XML.</content> </article> ``` ### XXE При XXE-атаке злоумышленник внедряет вредоносное содержимое в XML-документ, который затем обрабатывается XML-парсером приложения. Это вредоносное содержимое может включать ссылки на внешние сущности, которые контролируются злоумышленником. Когда парсер XML встречает эти сущности, он пытается их разрешить, что приводит к нежелательным последствиям. #### Возможные последствия атаки - Раскрытие данных - Отказ в обслуживании - Удаленное выполнение кода - Подделка запросов со стороны сервера (SSRF) XXE Example https://portswigger.net/web-security/xxe/lab-exploiting-xxe-to-retrieve-files ### Примеры из Тинкофф Банка - [https://jira.tcsbank.ru/browse/IPS-1282](https://jira.tcsbank.ru/browse/IPS-1282) - XXE в 3ds - [https://jira.tcsbank.ru/browse/IBUL-13423](https://jira.tcsbank.ru/browse/IBUL-13423) - XXE в SME - [https://jira.tcsbank.ru/browse/ACQ-11196](https://jira.tcsbank.ru/browse/ACQ-11196) - XXE в ACQ #### Как защищаться от таких уязвимостей? Практически все уязвимости XXE возникают из-за того, что библиотека разбора XML приложения поддерживает потенциально опасные возможности XML, которые приложению не нужны или которые оно не намерено использовать. Самый простой и эффективный способ предотвратить XXE-атаки - это отключить эти функции. Как правило, достаточно отключить разрешение внешних сущностей и отключить поддержку XInclude. Обычно это может быть сделано с помощью опций конфигурации или программным переопределением поведения по умолчанию. Обратитесь к документации по библиотеке разбора XML или API для получения подробной информации о том, как отключить ненужные функции. Пример отключения парсинга внешний сущностей для стандартного парсера Java: ``` dbf = javax.xml.parsers.DocumentBuilderFactory.newInstance() dbf.setExpandEntityReferences(false); DocumentBuilder db = dbf.newDocumentBuilder(); Document document = db.parse(<XML Source>); ``` #### Предотвращение XXE-атак по пунктам * Валидация ввода * Отключите разрешение внешних сущностей * Использовать белые списки * Политики безопасности содержимого * Брандмауэры и системы обнаружения вторжений ### Упражнения #### Упражнения 0 http://ttesting.ru:31337/xxe-1.php ### Упражнение 1 Эксплуатация XXE с использованием внешних сущностей для получения файлов - [https://portswigger.net/web-security/xxe/lab-exploiting-xxe-to-retrieve-files](https://portswigger.net/web-security/xxe/lab-exploiting-xxe-to-retrieve-files) ### Упражнение 2 Использование XXE для выполнения атак SSRF - [https://portswigger.net/web-security/xxe/lab-exploiting-xxe-to-perform-ssrf](https://portswigger.net/web-security/xxe/lab-exploiting-xxe-to-perform-ssrf) ## Дополнительные материалы - [PayloadsAllTheThings - XXE Injection](https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20Injection) # Client-Side Знакомство с атаками на клиентскую часть, механизмы защиты браузера и типовые уязвимости связанные с клиентской частью приложения. ## Браузер и механизмы защиты (Если хотите знать больше) - [Web security mozilla](https://developer.mozilla.org/en-US/docs/Web/Security) - [Burp Suite Academy](https://portswigger.net/web-security) ### SOP Политика одного источника (англ. Same Origin Policy (SOP)) является критическим механизмом безопасности, который ограничивает то, как документ или скрипт, загруженный из одного источника, может взаимодействовать с ресурсом из другого источника. Он помогает изолировать потенциально вредоносные документы, уменьшая возможные векторы атаки. ![изображение](https://www.appsecmonkey.com/static/images/same-origin-policy/figure-1.jpg) В следующей таблице приведены примеры сравнения источников с URL http://store.company.com/dir/page.html |URL|Результат|Причина| |---|---|---| |[http://store.company.com/dir2/other.html](http://store.company.com/dir2/other.html)|Тот же источник|Отличается только путь| |[http://store.company.com/dir/inner/another.html](http://store.company.com/dir/inner/another.html)|Тот же источник|Отличается только путь| |[https://store.company.com/page.html](https://store.company.com/page.html)|Источник не совпадает|Отличаются протоколы| |[http://store.company.com:81/dir/page.html](http://store.company.com:81/dir/page.html)|Источник не совпадает|Отличается порт (http:// имеет порт 80 по умолчанию)| |[http://news.company.com/dir/page.html](http://news.company.com/dir/page.html)|Источник не совпадает|Отличает доменное имя| ____ #### Разрешено - Отправлять простые запросы - Встраивать в страницу - <script src="…"></script> - \<link rel="stylesheet" href="…"> - \<img> - \<video> - \<iframe> etc #### Дополнительно https://apwt.gitbook.io/software-security/introduction/000introbasicbrowsersecurityconcepts/001sameoriginpolicy ### CORS Cross-Origin Resource Sharing — механизм, позволяющий получить доступ к ресурсам, которые находятся на другом источнике. Он помогает разрешить такие запросы как в примере выше. CORS делит запросы на простые и сложные. Простые запросы — это запросы, которые считаются “безопасными” (“_Request methods are considered “safe” if their defined semantics are essentially read-only_” из [RFC HTTP/1.1](https://www.rfc-editor.org/rfc/rfc7231#section-4.2)). То есть запросы, которые не изменят данные на сервере. Список безопасных методов и заголовков: ![](https://hackmd.io/_uploads/HyQ7oQtph.png) Браузер ожидает один или несколько следующих HTTP заголовков: - **Access-Control-Allow-Origin** (разрешенные источники) - **Access-Control-Allow-Methods** (разрешенные методы) - **Access-Control-Allow-Headers** (разрешенные заголовки) - **Access-Control-Allow-Credentials** (true/false, нужно ли передавать куки) ### CSP Content Security Policy - политика, созданная для ограничения для эксплуатации XSS Позволяет веб-приложению определить набор правил, которым будет следовать браузер на текущей странице **Пример 1** `Content-Security-Policy: default-src 'self'` Ограничение источников контента только исходным сервером (без поддоменов). **Пример 2** `Content-Security-Policy: default-src 'self' *.trusted.com` Можно получать контент с только с доверенного домена и его поддоменов. **Пример 3** `Content-Security-Policy: default-src 'self'; img-src *; media-src media1.com media2.com; script-src userscripts.example.com` Пользователи приложения могут вставлять в контент изображения из любых источников, но при этом загружать аудио- и видеофайлы только от доверенных провайдеров. Скрипты можно получать только с конкретного сервера, который содержит доверенный код. - Изображения будут доступны из любого источника (источник — «*»). - Прочие медиафайлы — с media1.com и media2.com (без поддоменов). - Исполняемый код — с userscripts.example.com. ## Атаки на клиентскую часть Основные виды атак на клиентов, через клиентскую часть приложения это: - Cross-site scripting (XSS) - Cross-site request forgery (CSRF) - Clickjacking (UI redressing) - Cross-origin resource sharing (CORS) Misconfiguration - DOM-based vulnerabilities ### Cross-site request forgery (CSRF) Подделка межсайтовых запросов (также известная как CSRF) - это уязвимость веб-безопасности, позволяющая злоумышленнику склонить пользователей к выполнению действий, которые они не намерены выполнять. Она позволяет злоумышленнику частично обходить одну и ту же политику происхождения, которая предназначена для предотвращения вмешательства различных веб сайтов друг в друга. #### Какой ущерб могут нанести атаки CSRF? При успешной атаке CSRF злоумышленник заставляет пользователя-жертву совершить непреднамеренное действие. Например, это может заключаться в изменении адреса электронной почты их аккаунта, смене пароля или осуществлении денежного перевода. В зависимости от характера действия, злоумышленник может получить полный контроль над учетной записью пользователя. Если взломанный пользователь имеет привилегированную роль в приложении, то злоумышленник может получить полный контроль над всеми данными и функциональностью приложения. #### Как CSRF работает? Для того, чтобы атака CSRF была возможной, должны быть выполнены три ключевых условия: - Соответствующее действие. Внутри приложения есть действие, которое злоумышленник имеет причину побудить. Это может быть как привилегированное действие (например, изменение разрешений для других пользователей), так и любое действие, связанное с пользовательскими данными (например, изменение собственного пароля пользователя). - Поддержание сеанса на основе куки-файлов. Выполнение действия включает в себя произведение одного или нескольких HTTP-запросов, и приложение полагается исключительно на куки сессии, чтобы идентифицировать пользователя, который сделал запрос. Не должно быть никакого другого механизма для отслеживания сессий или проверки запросов пользователей. - Нет непредсказуемых параметров запроса. Запросы, выполняющие действие, не содержат параметров, значения которых злоумышленник не может определить или угадать. Например, при смене пользователем пароля, функция не является уязвимой, если атакующему необходимо знать значение существующего пароля. Например, предположим, что в приложении есть функция, позволяющая пользователю изменять адрес электронной почты в своей учетной записи. Когда пользователь выполняет это действие, он делает HTTP-запрос, как показано ниже: ``` POST /email/change HTTP/1.1 Host: vulnerable-website.com Content-Type: application/x-www-form-urlencoded Content-Length: 30 Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE email=wiener@normal-user.com ``` Это соответствует условиям, требуемым для CSRF: - Действие по изменению адреса электронной почты на учетной записи пользователя представляет интерес для злоумышленника. После этого действия злоумышленник, как правило, может спровоцировать смену пароля и получить полный контроль над учетной записью пользователя. - Приложение использует сессионный cookie-файл для идентификации того, какой пользователь отправил запрос. Нет других маркеров или механизмов для отслеживания сеансов пользователя. - Атакующий может легко определить значения параметров запроса, необходимых для выполнения действия. При наличии этих условий злоумышленник может создать веб-страницу, содержащую следующий HTML: ``` <html> <body> <form action="https://vulnerable-website.com/email/change" method="POST"> <input type="hidden" name="email" value="pwned@evil-user.net" /> </form> <script> document.forms[0].submit(); </script> </body> </html> ``` Если пользователь-жертва зайдет на веб-страницу злоумышленника, произойдет следующее: - Страница злоумышленника спровоцирует HTTP-запрос на уязвимый веб-сайт. - Если пользователь входит на уязвимый веб-сайт, его браузер автоматически включает в запрос сессионные cookie-файлы (при условии, что cookie-файлы SameSite не используются). - Уязвимый веб-сайт будет обрабатывать запрос обычным способом, относиться к нему, как к сделанному пользователем-жертвой, и изменять свой адрес электронной почты. #### Предотвращение CSRF-атак Наиболее надежным способом защиты от атак CSRF является включение маркера CSRF в соответствующие запросы. Токен должен быть: - Непредсказуемым с высокой энтропией, как и для токенов сеанса в целом. - Привязанный к сеансу пользователя. - Строго проверяться в каждом случае перед выполнением соответствующего действия. ### Упражнения #### Упражнения 1 https://portswigger.net/web-security/csrf/lab-no-defenses #### Упражнения 2 https://portswigger.net/web-security/csrf/bypassing-token-validation/lab-token-validation-depends-on-request-method ## Дополнительные материалы - [Больше о безопасности браузера](https://developer.mozilla.org/en-US/docs/Web/Security) - [Борьба с CSRF при помощи SameSite Cookies](https://portswigger.net/web-security/csrf/samesite-cookies) - [Использование CSRF-токенов](https://portswigger.net/web-security/csrf/tokens) - [Памятка по защите от CSRF атак](https://cheatsheetseries.owasp.org/cheatsheets/Cross-Site_Request_Forgery_Prevention_Cheat_Sheet.html)