<summary><strong>Вивчайте хакінг AWS від нуля до героя з</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Якщо ви хочете побачити вашу **компанію рекламовану на HackTricks**або**завантажити HackTricks у форматі PDF**, перевірте [**ПЛАНИ ПІДПИСКИ**](https://github.com/sponsors/carlospolop)!
* Відкрийте для себе [**Сім'ю PEASS**](https://opensea.io/collection/the-peass-family), нашу колекцію ексклюзивних [**NFT**](https://opensea.io/collection/the-peass-family)
* **Приєднуйтесь до** 💬 [**групи Discord**](https://discord.gg/hRep4RUj7f) або [**групи telegram**](https://t.me/peass) або**слідкуйте** за нами на **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Поділіться своїми хакерськими трюками, надсилайте PR до** [**HackTricks**](https://github.com/carlospolop/hacktricks) та [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) репозиторіїв GitHub.
Приєднуйтесь до сервера [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy), щоб спілкуватися з досвідченими хакерами та мисливцями за багами!
Політика безпеки контенту (CSP) визнана як технологія браузера, спрямована в основному на **захист від атак, таких як міжсайтовий скриптінг (XSS)**. Вона працює шляхом визначення та деталізації шляхів та джерел, з яких браузер може безпечно завантажувати ресурси. Ці ресурси охоплюють різноманітні елементи, такі як зображення, фрейми та JavaScript. Наприклад, політика може дозволяти завантаження та виконання ресурсів з того ж домену (self), включаючи вбудовані ресурси та виконання рядкового коду через функції, такі як `eval`, `setTimeout`або`setInterval`.
Реалізація CSP здійснюється за допомогою **відповідних заголовків**або шляхом включення **мета-елементів у HTML-сторінку**. Відповідно до цієї політики, браузери активно застосовують ці умови та негайно блокують будь-які виявлені порушення.
*`Content-Security-Policy`: Застосовує CSP; браузер блокує будь-які порушення.
*`Content-Security-Policy-Report-Only`: Використовується для моніторингу; повідомляє про порушення без їх блокування. Ідеально підходить для тестування в середовищах перед випуском в експлуатацію.
CSP обмежує походження завантаження як активного, так і пасивного контенту, контролюючи аспекти, такі як виконання вбудованого JavaScript та використання `eval()`. Приклад політики:
* **script-src**: Дозволяє конкретні джерела для JavaScript, включаючи URL-адреси, вбудовані скрипти, та скрипти, викликані обробниками подій або таблицями стилів XSLT.
* **default-src**: Встановлює типову політику для отримання ресурсів, коли відсутні конкретні директиви отримання.
* **child-src**: Вказує дозволені ресурси для веб-робітників та вбудованого вмісту фреймів.
* **connect-src**: Обмежує URL-адреси, які можна завантажити за допомогою інтерфейсів, таких як fetch, WebSocket, XMLHttpRequest.
* **frame-src**: Обмежує URL-адреси для фреймів.
* **frame-ancestors**: Вказує, які джерела можуть вбудовувати поточну сторінку, застосовується до елементів, таких як `<frame>`, `<iframe>`, `<object>`, `<embed>`, та `<applet>`.
* **img-src**: Визначає дозволені джерела для зображень.
* **font-src**: Вказує дійсні джерела для шрифтів, завантажених за допомогою `@font-face`.
* **manifest-src**: Визначає дозволені джерела файлів маніфесту програми.
* **media-src**: Визначає дозволені джерела для завантаження медіа-об'єктів.
* **object-src**: Визначає дозволені джерела для елементів `<object>`, `<embed>`, та `<applet>`.
* **base-uri**: Вказує дозволені URL-адреси для завантаження за допомогою елементів `<base>`.
* **form-action**: Перераховує дійсні кінцеві точки для відправки форм.
* **plugin-types**: Обмежує типи mime, які сторінка може викликати.
* **upgrade-insecure-requests**: Наказує браузерам переписувати HTTP-URL-адреси на HTTPS.
* **sandbox**: Застосовує обмеження, схожі на атрибут sandbox `<iframe>`.
* **report-to**: Вказує групу, якій буде відправлено звіт, якщо політика порушена.
* **worker-src**: Вказує дійсні джерела для скриптів Worker, SharedWorker або ServiceWorker.
* **prefetch-src**: Вказує дійсні джерела для ресурсів, які будуть завантажені або попередньо завантажені.
* **navigate-to**: Обмежує URL-адреси, на які документ може переходити будь-якими засобами (a, form, window.location, window.open, тощо).
### Джерела
*`*`: Дозволяє всі URL-адреси, за винятком тих, що мають схеми `data:`, `blob:`, `filesystem:`.
*`'self'`: Дозволяє завантаження з того ж домену.
*`'data'`: Дозволяє завантаження ресурсів через схему даних (наприклад, зображення, закодовані Base64).
*`'none'`: Блокує завантаження з будь-якого джерела.
*`'unsafe-eval'`: Дозволяє використання `eval()` та подібних методів, не рекомендується з погляду безпеки.
*`'unsafe-inline'`: Дозволяє використання вбудованих ресурсів, таких як вбудований `<script>`або`<style>`, не рекомендується з погляду безпеки.
*`'nonce'`: Білий список для конкретних вбудованих скриптів за допомогою криптографічного nonce (число, яке використовується один раз).
* Якщо у вас обмежене виконання JS, можливо отримати використаний nonce на сторінці за допомогою `doc.defaultView.top.document.querySelector("[nonce]")` та потім використовувати його для завантаження зловмисного скрипту (якщо використовується strict-dynamic, будь-яке дозволене джерело може завантажувати нові джерела, тому це не потрібно), як у:
*`'sha256-<hash>'`: Білістує скрипти з конкретним хешем sha256.
*`'strict-dynamic'`: Дозволяє завантажувати скрипти з будь-якого джерела, якщо вони були додані до білого списку за допомогою nonce або хеша.
*`'host'`: Вказує конкретний хост, наприклад, `example.com`.
*`https:`: Обмежує URL-адреси тільки тими, які використовують HTTPS.
*`blob:`: Дозволяє завантажувати ресурси з URL-адрес Blob (наприклад, URL-адреси Blob, створені за допомогою JavaScript).
*`filesystem:`: Дозволяє завантажувати ресурси з файлової системи.
*`'report-sample'`: Включає зразок порушеного коду в звіті про порушення (корисно для налагодження).
*`'strict-origin'`: Схожий на 'self', але забезпечує відповідність рівня безпеки протоколу джерел документу (ресурси з безпечних джерел можуть завантажувати ресурси з безпечних джерел).
*`'strict-origin-when-cross-origin'`: Надсилає повні URL-адреси при здійсненні запитів з однаковим походженням, але надсилає лише походження, коли запит є міждоменним.
*`'unsafe-allow-redirects'`: Дозволяє завантажувати ресурси, які негайно перенаправлять на інший ресурс. Не рекомендується, оскільки це підточує безпеку.
Якщо ви якось зможете зробити **дозволений JS-код створив новий тег скрипта** в DOM за допомогою вашого JS-коду, тому що дозволений скрипт створює його, **новий тег скрипта буде дозволено виконувати**.
Більше того, навіть якщо ви зможете завантажити **JS-код всередину** файлу, використовуючи розширення, яке приймається сервером (наприклад: _script.png_), цього буде недостатньо, оскільки деякі сервери, наприклад, сервер apache, **вибирають MIME-тип файлу на основі розширення**, а браузери, такі як Chrome, **відмовляться виконувати код Javascript** всередині чогось, що повинно бути зображенням. "На щастя", тут є помилки. Наприклад, з CTF я дізнався, що **Apache не розпізнає** розширення _**.wave**_, тому не надає йому **MIME-тип, подібний до audio/\***.
Отже, якщо ви знайдете XSS та можливість завантаження файлу, і вам вдасться знайти **неправильне розширення**, ви можете спробувати завантажити файл з цим розширенням та вмістом скрипта. Або, якщо сервер перевіряє правильний формат завантаженого файлу, створіть поліглот ([декілька прикладів поліглотів тут](https://github.com/Polydet/polyglot-database)).
Якщо неможливо впровадити JS, ви все ще можете спробувати витягти, наприклад, облікові дані, **впроваджуючи дію форми** (і можливо очікувати, що менеджери паролів автоматично заповнять паролі). Ви можете знайти [**приклад у цьому звіті**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp). Також зверніть увагу, що `default-src` не охоплює дії форми.
#### Пейлоади, використовуючи Angular + бібліотеку з функціями, які повертають об'єкт `window` ([перегляньте цей пост](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
У пості показано, що ви можете **завантажити** всі **бібліотеки** з `cdn.cloudflare.com` (або будь-якого іншого дозволеного репозиторію JS-бібліотек), виконати всі додані функції з кожної бібліотеки та перевірити, **які функції з яких бібліотек повертають об'єкт `window`**.
Згідно з [**цим CTF writeup**](https://blog-huli-tw.translate.goog/2023/07/28/google-zer0pts-imaginary-ctf-2023-writeup/?\_x\_tr\_sl=es&\_x\_tr\_tl=en&\_x\_tr\_hl=es&\_x\_tr\_pto=wapp#noteninja-3-solves), ви можете зловживати [https://www.google.com/recaptcha/](https://www.google.com/recaptcha/) всередині CSP для виконання довільного JS-коду, обхід CSP:
Можливо використовувати Google Apps Script для отримання інформації на сторінці всередині script.google.com. Як це [зроблено в цьому звіті](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/).
Сценарії, де `script-src` встановлено на `self` та певний домен, який додається до білого списку, можна обійти за допомогою JSONP. Кінцеві точки JSONP дозволяють небезпечні методи зворотного виклику, що дозволяють зловмиснику виконати XSS, робочий пейлоад:
Та ж сама уразливість виникне, якщо **довірча точка доступу містить відкритий перенаправлення**, оскільки, якщо початкова точка доступу є довіреною, перенаправлення є довіреним.
Як описано в [цьому пості](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses), існує багато доменів третіх сторін, які можуть бути дозволені десь у CSP, і можуть бути використані для витоку даних або виконання JavaScript-коду. Деякі з цих сторонніх служб:
Якщо ви знаходите будь-які з дозволених доменів у CSP вашої цілі, є ймовірність, що ви зможете обійти CSP, зареєструвавшись на службі третьої сторони і, або витікати дані на цю службу, або виконувати код.
Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, such as Cross Site Scripting (XSS) and data injection attacks. However, misconfigurations or bypasses in CSP can lead to security vulnerabilities.
#### Bypass Techniques
1.**Inline Scripts**: By using inline event handlers or script tags, attackers can execute arbitrary code even if CSP is in place.
2.**Unsafe Inline**: CSP directives like `unsafe-inline` allow the execution of inline scripts, which can be exploited by attackers.
4.**Nonce Bypass**: If a website uses nonces for script-src, attackers can bypass CSP by injecting scripts with a valid nonce.
5.**Self Bypass**: By allowing `'self'` as a valid source, attackers can host malicious scripts on the same domain to bypass CSP.
6.**Whitelist Bypass**: Attackers can exploit misconfigured whitelists to load scripts from unauthorized sources.
#### Conclusion
Understanding common CSP bypass techniques is crucial for security professionals to effectively secure web applications against potential attacks. Regularly testing and updating CSP configurations can help prevent security vulnerabilities.
Маєте можливість витягти дані, так само, як це завжди робилося з [Google Analytics](https://www.humansecurity.com/tech-engineering-blog/exfiltrating-users-private-data-using-google-analytics-to-bypass-csp)/[Google Tag Manager](https://blog.deteact.com/csp-bypass/). У цьому випадку ви виконуєте такі загальні кроки:
1. Створіть обліковий запис розробника Facebook тут.
2. Створіть новий додаток "Facebook Login" та виберіть "Веб-сайт".
3. Перейдіть до "Налаштування -> Основне" та отримайте свій "Ідентифікатор додатка".
4.На цільовому сайті, з якого ви хочете витягти дані, ви можете витягти дані, безпосередньо використовуючи гаджет Facebook SDK "fbq" через "customEvent" та дані вантажу.
5. Перейдіть до "Менеджер подій" вашого додатка та виберіть створений вами додаток (зверніть увагу, що менеджер подій можна знайти за URL, подібним до цього: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events
6. Виберіть вкладку "Тестові події", щоб побачити події, які надсилаються вашим веб-сайтом.
Потім, на стороні жертви, ви виконуєте наступний код для ініціалізації пікселя відстеження Facebook, щоб вказати на додаток облікового запису розробника Facebook атакуючого та виконати власну подію, подібну до цієї:
Щодо інших семи сторонніх доменів, вказаних у попередній таблиці, існує багато інших способів їх зловживання. Дивіться попередній [пост блогу](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses) для додаткових пояснень про інші зловживання сторонніми доменами.
Крім зазначеного вище перенаправлення для обходу обмежень шляху, існує ще одна техніка, яка називається Relative Path Overwrite (RPO) і може бути використана на деяких серверах.
Це працює, оскільки для браузера ви завантажуєте файл з назвою `..%2fangular%2fangular.js`, розташований під `https://example.com/scripts/react/`, що відповідає політиці CSP.
Отже, вони розкодують це, ефективно запитуючи `https://example.com/scripts/react/../angular/angular.js`, що еквівалентно `https://example.com/scripts/angular/angular.js`.
Рішення полягає в тому, щоб не трактувати `%2f` як `/` на стороні сервера, забезпечуючи послідовне тлумачення між браузером та сервером для уникнення цієї проблеми.
Якщо директива **base-uri** відсутня, ви можете використовувати її для виконання [**висячого впровадження розмітки**](../dangling-markup-html-scriptless-injection/).
Більше того, якщо **сторінка завантажує скрипт, використовуючи відносний шлях** (наприклад, `<script src="/js/app.js">`) за допомогою **Nonce**, ви можете використати **тег base** для того, щоб **завантажити** скрипт з **вашого власного сервера, досягнувши XSS.**\
Якщо уразлива сторінка завантажена з **httpS**, використовуйте URL-адресу httpS у базі.
Конкретна політика, відома як політика безпеки контенту (CSP), може обмежувати події JavaScript. Тем не менш, AngularJS вводить власні події як альтернативу. У межах події AngularJS надає унікальний об'єкт `$event`, який посилається на об'єкт події браузера. Цей об'єкт `$event` можна використовувати для обхіду CSP. Зокрема, в Chrome об'єкт `$event/event` має атрибут `path`, який містить масив об'єктів, що відображають ланцюг виконання події, з об'єктом `window` завжди розташованим в кінці. Ця структура є ключовою для тактик виходу з пісочниці.
Направляючи цей масив на фільтр `orderBy`, можна ітерувати його, використовуючи кінцевий елемент (об'єкт `window`), щоб викликати глобальну функцію, наприклад, `alert()`. Наведений нижче фрагмент коду демонструє цей процес:
Цей уривок підкреслює використання директиви `ng-focus` для спрацювання події, використання `$event.path|orderBy` для маніпулювання масивом `path` та використання об'єкта `window` для виклику функції `alert()`, що призводить до викриття `document.cookie`.
**Знайдіть інші обхідні шляхи Angular за посиланням** [**https://portswigger.net/web-security/cross-site-scripting/cheat-sheet**](https://portswigger.net/web-security/cross-site-scripting/cheat-sheet)
Політика CSP, яка дозволяє використання доменів для завантаження скриптів у додатку Angular JS, може бути обійдена за допомогою виклику функцій зворотнього виклику та певних вразливих класів. Додаткову інформацію про цей метод можна знайти у детальному посібнику, доступному на цьому [сховищі git](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh\*t,-it's-CSP!%22).
Що відбувається, коли CSP зіткнується з перенаправленням на сервері? Якщо перенаправлення призводить до іншого походження, яке не дозволено, воно все одно не вдасться.
Однак, згідно з описом у [CSP spec 4.2.2.3. Paths and Redirects](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects), якщо перенаправлення призводить до іншого шляху, воно може обійти початкові обмеження.
Однак кінцевий `http://localhost:5555/301` буде **перенаправлений на сервері на `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//`**. Оскільки це перенаправлення, **шлях не враховується**, і**скрипт може бути завантажений**, обхід обмеження шляху.
Отже, найкращим рішенням є переконатися, що на веб-сайті відсутні вразливості відкритого перенаправлення та що в правилах CSP немає доменів, які можна використовувати для атак.
`'unsafe-inline'` означає, що ви можете виконати будь-який скрипт всередині коду (XSS може виконати код), а`img-src *` означає, що ви можете використовувати на веб-сторінці будь-яке зображення з будь-якого ресурсу.
Ви можете обійти цей CSP, ексфільтруючи дані через зображення (у цьому випадку XSS зловживає CSRF, де сторінка, доступна боту, містить SQLi, і витягує прапорець через зображення):
За допомогою цієї конфігурації також можна зловживати, щоб **завантажити** вставлений **код JavaScript всередині зображення**. Наприклад, якщо сторінка дозволяє завантажувати зображення з Twitter. Ви можете **створити****спеціальне зображення**, **завантажити** його на Twitter і використати "**unsafe-inline**" для **виконання** коду JS (як звичайний XSS), який **завантажить****зображення**, **витягне** з нього **JS**і**виконає****його**: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
Якщо **параметр**, відправлений вами, **вставляється всередину****оголошення****політики**, то ви можете **змінити****політику** таким чином, що вона стане **некорисною**. Ви можете **дозволити виконання скриптів 'unsafe-inline'** за допомогою будь-якого з цих обхідних шляхів:
Оскільки ця директива **перезапише існуючі директиви script-src**.\
Ви можете знайти приклад тут: [http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E](http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=%3Bscript-src-elem+\*\&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E)
Зверніть увагу на відсутність директиви `'unsafe-inline'`\
Цього разу ви можете змусити жертву **завантажити** сторінку під **вашим контролем** через **XSS** з допомогою `<iframe`. Цього разу ви змусите жертву отримати доступ до сторінки, звідки ви хочете витягнути інформацію (**CSRF**). Ви не можете отримати доступ до вмісту сторінки, але якщо ви якось зможете **контролювати час, який потрібно для завантаження сторінки**, ви зможете витягнути необхідну інформацію.
Цього разу **прапорець** буде витягнутий, коли буде **правильно вгадано символ** через SQLi, **відповідь** займе **більше часу** через функцію затримки. Потім ви зможете витягнути прапорець:
Цей атака передбачає деякий соціальний інженерінг, де зловмисник **переконує користувача перетягнути посилання на закладку браузера**. Ця закладка міститиме **зловісний javascript** код, який при перетягуванні або кліку буде виконаний в контексті поточного веб-вікна, **обхід CSP та дозволить вкрасти чутливу інформацію** таку як файли cookie або токени.
У [**цьому описі CTF**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution), CSP обходиться шляхом впровадження в дозволену iframe більш обмеженого CSP, який забороняв завантаження певного JS файлу, який потім, через **забруднення прототипу**або**забруднення DOM**, дозволяв **зловживати іншим скриптом для завантаження довільного скрипту**.
У [**цьому звіті CTF**](https://github.com/aszx87410/ctf-writeups/issues/48), було можливо за допомогою **впровадження HTML****обмежити** більше **CSP**, щоб сценарій, який запобігає CSTI, був вимкнений, і, отже, **вразливість стала вразливою для використання.**\
CSP можна зробити більш обмеженим за допомогою **мета-тегів HTML**, а вбудовані сценарії можна вимкнути, **видаливши****запис**, що дозволяє їх **nonce** та **увімкнути конкретний вбудований сценарій через sha**:
Якщо ви зможете зробити так, щоб сервер відповів з заголовком **`Content-Security-Policy-Report-Only`** з **значенням, котре контролюється вами** (можливо, через CRLF), ви зможете зробити його вказувати на ваш сервер, і якщо ви **обгорнете****JS вміст**, який ви хочете ексфільтрувати з **`<script>`**, і оскільки ймовірно `unsafe-inline` не дозволяється CSP, це спричинить **помилку CSP**, і частина скрипта (що містить чутливу інформацію) буде відправлена на сервер з `Content-Security-Policy-Report-Only`.
* Створюється `iframe`, який вказує на URL (назвемо його `https://example.redirect.com`), який дозволений CSP.
* Цей URL потім перенаправляється на секретний URL (наприклад, `https://usersecret.example2.com`), який **не дозволений** CSP.
* Слухаючи подію `securitypolicyviolation`, можна захопити властивість `blockedURI`. Ця властивість розкриває домен заблокованого URI, витікаючи секретний домен, на який спочатку було перенаправлено.
Цікаво відзначити, що браузери, такі як Chrome та Firefox, мають різні поведінки у відношенні до обробки iframes у контексті CSP, що може призвести до потенційного витоку чутливої інформації через невизначене поведінку.
Ще одним методом є використання самого CSP для виведення секретного піддомену. Цей метод ґрунтується на алгоритмі бінарного пошуку та налаштуванні CSP для включення конкретних доменів, які намірено блокуються. Наприклад, якщо секретний піддомен складається з невідомих символів, можна ітеративно перевіряти різні піддомени, змінюючи директиву CSP для блокування або дозволу цих піддоменів. Ось уривок коду, який показує, як може бути налаштований CSP для полегшення цього методу:
Через моніторинг запитів, які блокуються або дозволяються CSP, можна скоротити можливі символи в секретному піддомені, в результаті розкриваючи повний URL.
Обидва методи використовують нюанси реалізації та поведінки CSP в браузерах, демонструючи, як, здавалося б, безпечні політики можуть ненавмисно витікати чутливу інформацію.
Приєднуйтесь до сервера [**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy), щоб спілкуватися з досвідченими хакерами та мисливцями за багами!
PHP відомий тим, що за замовчуванням **буферизує відповідь до 4096** байтів. Тому, якщо PHP показує попередження, надаючи **достатньо даних всередині попереджень**, **відповідь** буде **відправлена****перед****заголовком CSP**, що призводить до ігнорування заголовка.\
Отже, техніка полягає в основному в **заповненні буфера відповіді попередженнями**, щоб заголовок CSP не був відправлений.
З [**цього опису**](https://blog.ssrf.kr/69) здається, що було можливо обійти захист CSP, завантаживши сторінку помилки (потенційно без CSP) та переписавши її вміст.
SOME - це техніка, яка зловживає XSS (або дуже обмежений XSS) **в кінцевій точці сторінки**, щоб **зловживати****іншими кінцевими точками того ж походження.** Це робиться шляхом завантаження вразливої кінцевої точки зі сторінки зловмисника, а потім оновлення сторінки зловмисника до реальної кінцевої точки в тому ж походженні, яку ви хочете зловживати. Таким чином **вразлива кінцева точка** може використовувати об'єкт **`opener`** в **пейлоуді**, щоб **отримати доступ до DOM****реальної кінцевої точки для зловживання**. Для отримання додаткової інформації перегляньте:
Крім того, **wordpress** має **JSONP** кінцеву точку в `/wp-json/wp/v2/users/1?_jsonp=data`, яка буде **відображати****дані**, відправлені у виведенні (з обмеженням лише літер, цифр та крапок).
Зловмисник може зловживати цією кінцевою точкою, щоб **здійснити атаку SOME** проти WordPress та **вбудувати** її всередину `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>`, слід зазначити, що цей **скрипт** буде **завантажено**, оскільки він **дозволений 'self'**. Крім того, і через те, що WordPress встановлено, зловмисник може зловживати **атакою SOME** через **вразливу****колбек** кінцеву точку, яка **обхід CSP** для надання більш високих привілеїв користувачу, встановлення нового плагіна...\
Для отримання додаткової інформації про те, як виконати цю атаку, перегляньте [https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/](https://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/)
Якщо є строга CSP, яка не дозволяє вам **взаємодіяти з зовнішніми серверами**, є кілька речей, які ви завжди можете зробити для ексфільтрації інформації.
If the CSP header allows scripts from a specific domain, you can try to load a script from a subdomain of that domain. For example, if the CSP header allows scripts from `example.com`, you can try to load a script from `subdomain.example.com`.
<summary><strong>Вивчайте хакінг AWS від нуля до героя з</strong><ahref="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
* Якщо ви хочете побачити вашу **компанію в рекламі HackTricks**або**завантажити HackTricks у PDF**, перевірте [**ПЛАНИ ПІДПИСКИ**](https://github.com/sponsors/carlospolop)!
* Відкрийте для себе [**Сім'ю PEASS**](https://opensea.io/collection/the-peass-family), нашу колекцію ексклюзивних [**NFT**](https://opensea.io/collection/the-peass-family)
* **Приєднуйтесь до** 💬 [**групи Discord**](https://discord.gg/hRep4RUj7f) або [**групи telegram**](https://t.me/peass) або**слідкуйте** за нами в **Twitter** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**.**
* **Поділіться своїми хакерськими трюками, надсилайте PR до** [**HackTricks**](https://github.com/carlospolop/hacktricks) та [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github репозиторіїв.