**CSRF (Cross-Site Request Forgery)**는 웹 애플리케이션에서 발견되는 보안 취약점 유형입니다. 이 취약점을 이용하여 공격자는 인증된 세션을 이용해 의심스러운 사용자 대신 동작을 수행할 수 있습니다. 공격은 피해자의 플랫폼에 로그인한 사용자가 악성 사이트를 방문할 때 실행됩니다. 이 사이트는 자바스크립트 실행, 폼 제출 또는 이미지 가져오기와 같은 방법을 통해 피해자의 계정으로 요청을 트리거합니다.
* [**SameSite 쿠키**](hacking-with-cookies/#samesite): 이 속성은 브라우저가 교차 사이트 요청과 함께 쿠키를 보내지 못하도록 막습니다. [SameSite 쿠키에 대해 더 알아보기](hacking-with-cookies/#samesite).
* [**Cross-origin resource sharing**](cors-bypass.md): 피해 사이트의 CORS 정책은 공격의 실현 가능성에 영향을 줄 수 있습니다. 특히, 공격이 피해 사이트의 응답을 읽는 것을 요구하는 경우입니다. [CORS 우회에 대해 알아보기](cors-bypass.md).
* **사용자 확인**: 사용자의 의도를 확인하기 위해 비밀번호를 요구하거나 captcha를 풀도록 할 수 있습니다.
* **Referrer 또는 Origin 헤더 확인**: 이러한 헤더를 확인하여 요청이 신뢰할 수 있는 출처에서 오는지 확인할 수 있습니다. 그러나 URL의 조작을 통해 잘못 구현된 검사를 우회할 수 있으므로 주의해야 합니다:
-`http://mal.net?orig=http://example.com` (URL이 신뢰할 수 있는 URL로 끝남)
-`http://example.com.mal.net` (URL이 신뢰할 수 있는 URL로 시작함)
* **매개변수 이름 수정**: POST 또는 GET 요청의 매개변수 이름을 변경하여 자동화된 공격을 방지할 수 있습니다.
* **CSRF 토큰**: 각 세션마다 고유한 CSRF 토큰을 포함하고 이 토큰을 후속 요청에서 요구함으로써 CSRF의 위험을 크게 줄일 수 있습니다. CORS를 강제로 적용함으로써 토큰의 효과를 향상시킬 수 있습니다.
응용 프로그램은 토큰이 존재할 때만 토큰을 **검증**하는 메커니즘을 구현할 수 있습니다. 그러나 토큰이 없을 때 검증이 완전히 생략되는 경우 취약점이 발생합니다. 공격자는 토큰을 전달하는 매개변수뿐만 아니라 매개변수 자체를 **제거**함으로써 이를 악용할 수 있습니다. 이를 통해 검증 프로세스를 우회하고 CSRF 공격을 효과적으로 수행할 수 있습니다.
[**여기**](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple\_requests)에 따르면, **POST** 메소드를 사용하여 **preflight 요청을 피하기 위해** 허용되는 Content-Type 값은 다음과 같습니다:
`Content-Type: application/json`을 사용하여 POST 요청을 통해 JSON 데이터를 보내려고 할 때, HTML 폼에서는 직접적으로 사용할 수 없습니다. 마찬가지로, `XMLHttpRequest`를 사용하여 이 콘텐츠 유형을 보내면 프리플라이트 요청이 시작됩니다. 그러나 Content-Type과 관계없이 서버가 JSON 데이터를 처리하는지 확인하기 위해 이 제한을 우회할 수 있는 전략이 있습니다:
1.**대체 콘텐츠 유형 사용**: 폼에서 `enctype="text/plain"`을 설정하여 `Content-Type: text/plain` 또는 `Content-Type: application/x-www-form-urlencoded`를 사용합니다. 이 접근 방식은 백엔드가 Content-Type과 관계없이 데이터를 사용하는지 테스트합니다.
2.**콘텐츠 유형 수정**: 프리플라이트 요청을 피하면서 서버가 콘텐츠를 JSON으로 인식하도록 하려면, `Content-Type: text/plain; application/json`으로 데이터를 보낼 수 있습니다. 이는 프리플라이트 요청을 트리거하지 않지만, 서버가 `application/json`을 수락하도록 구성되어 있다면 올바르게 처리될 수 있습니다.
3.**SWF 플래시 파일 활용**: 덜 일반적이지만 실행 가능한 방법으로, SWF 플래시 파일을 사용하여 이러한 제한을 우회할 수 있습니다. 이 기술에 대한 자세한 이해를 위해 [이 게시물](https://anonymousyogi.medium.com/json-csrf-csrf-that-none-talks-about-c2bf9a480937)을 참조하십시오.
[**이 CTF writeup**](https://github.com/google/google-ctf/tree/master/2023/web-vegsoda/solution)의 첫 번째 부분에서는 [Oak의 소스 코드](https://github.com/oakserver/oak/blob/main/router.ts#L281)에서 라우터가 **응답 본문이 없는 GET 요청으로 HEAD 요청을 처리**하도록 설정되어 있다고 설명합니다. 이는 Oak에만 해당되는 독특한 해결책은 아니며, HEAD 요청을 처리하는 특정 핸들러 대신 GET 핸들러에게 전달되지만 응용 프로그램에서는 응답 본문을 제거합니다.
**CSRF 토큰**이 **방어**로 사용되는 경우, [**XSS**](xss-cross-site-scripting/#xss-stealing-csrf-tokens) 취약점이나 [**Dangling Markup**](dangling-markup-html-scriptless-injection/) 취약점을 악용하여 **유출**을 시도할 수 있습니다.
When a form uses the GET method, the form data is appended to the URL as query parameters. This means that the data is visible in the URL and can be easily manipulated by an attacker.
GET requests are typically used for retrieving data from the server and should not have any side effects. However, if a vulnerable application performs sensitive actions based on GET requests, it can be susceptible to CSRF attacks.
To exploit a CSRF vulnerability in a form GET request, an attacker can create a malicious webpage that includes an HTML form with the target URL as the form's action. The attacker can then trick the victim into visiting the malicious webpage, causing the victim's browser to automatically submit the form and perform the undesired action.
To prevent CSRF attacks in form GET requests, it is recommended to use the POST method instead. Additionally, implementing anti-CSRF tokens can provide an extra layer of protection by validating that the request originated from a trusted source.
폼이 GET 메서드를 사용하는 경우, 폼 데이터는 쿼리 매개변수로 URL에 추가됩니다. 이는 데이터가 URL에 표시되어 공격자가 쉽게 조작할 수 있다는 것을 의미합니다.
GET 요청은 일반적으로 서버에서 데이터를 검색하는 데 사용되며 부작용이 없어야 합니다. 그러나 취약한 애플리케이션은 GET 요청을 기반으로 민감한 작업을 수행할 수 있으므로 CSRF 공격에 취약할 수 있습니다.
폼 GET 요청에서 CSRF 취약점을 악용하기 위해 공격자는 대상 URL을 폼의 액션으로 포함하는 악성 웹 페이지를 생성할 수 있습니다. 그런 다음 공격자는 피해자를 속여 악성 웹 페이지를 방문하게 하여 피해자의 브라우저가 자동으로 폼을 제출하고 원하지 않는 작업을 수행하도록 할 수 있습니다.
폼 GET 요청에서 CSRF 공격을 방지하기 위해 POST 메서드를 사용하는 것이 좋습니다. 또한, 안티 CSRF 토큰을 구현하여 요청이 신뢰할 수 있는 출처에서 유래되었는지를 확인함으로써 추가적인 보호 기능을 제공할 수 있습니다.
When a user submits a form on a website, the data is typically sent to the server using a POST request. This is done by specifying the `method` attribute of the HTML form element as `POST`. The form data is then included in the body of the request.
사용자가 웹 사이트에서 양식을 제출하면, 데이터는 일반적으로 POST 요청을 사용하여 서버로 전송됩니다. 이는 HTML 양식 요소의 `method` 속성을 `POST`로 지정함으로써 수행됩니다. 양식 데이터는 요청의 본문에 포함됩니다.
In the example above, when the user clicks the "Submit" button, a POST request will be sent to the `/submit-form` endpoint with the form data as the request body. The server can then process this data and perform the necessary actions.
An attacker can exploit Cross-Site Request Forgery (CSRF) vulnerabilities by tricking a user into submitting a form without their knowledge or consent. One way to achieve this is by using an iframe to load a malicious website that contains a form with the desired action and method.
공격자는 사용자를 속여 동의 없이 폼을 제출하도록 유도하여 Cross-Site Request Forgery (CSRF) 취약점을 악용할 수 있습니다. 이를 위해 iframe을 사용하여 원하는 동작과 방법을 가진 악성 웹사이트를 로드하는 방법을 사용할 수 있습니다.
In the above example, the attacker creates an invisible iframe and a form that targets the iframe as the submission target. The form contains hidden input fields with the desired values for the username and email. When the user visits the attacker's website, the form is automatically submitted without their knowledge, sending the forged request to the target website's `/update-profile` endpoint.
위의 예시에서 공격자는 보이지 않는 iframe과 iframe을 제출 대상으로 하는 폼을 생성합니다. 폼에는 사용자 이름과 이메일에 대한 원하는 값이 숨겨진 입력 필드로 포함되어 있습니다. 사용자가 공격자의 웹사이트를 방문하면 폼이 사용자의 동의 없이 자동으로 제출되어 위조된 요청이 대상 웹사이트의 `/update-profile` 엔드포인트로 전송됩니다.
Ajax POST 요청은 웹 애플리케이션에서 데이터를 서버로 전송하는 방법 중 하나입니다. 이러한 요청은 사용자가 웹 페이지를 새로 고치지 않고도 서버와 상호 작용할 수 있도록 해줍니다. CSRF(Cross-Site Request Forgery) 공격은 이러한 Ajax POST 요청을 악용하여 사용자의 권한으로 악의적인 동작을 수행하는 것입니다.
일반적으로, 웹 애플리케이션은 사용자의 세션을 확인하기 위해 쿠키를 사용합니다. 이 쿠키는 사용자가 로그인한 후에 생성되며, 사용자의 세션을 식별하는 데 사용됩니다. CSRF 공격자는 이러한 쿠키를 이용하여 사용자의 권한으로 악의적인 Ajax POST 요청을 보낼 수 있습니다.
CSRF 공격을 방지하기 위해 웹 애플리케이션은 보안 토큰을 사용합니다. 이 토큰은 사용자의 세션과 연결되어 있으며, 모든 Ajax POST 요청에 포함되어야 합니다. 서버는 이 토큰을 검증하여 요청이 유효한지 확인합니다. 이를 통해 CSRF 공격을 방지할 수 있습니다.
따라서, 웹 애플리케이션을 개발할 때는 Ajax POST 요청에 대한 보안 토큰을 구현하여 CSRF 공격으로부터 안전하게 보호해야 합니다.
xh.setRequestHeader('Content-type', 'application/x-www-form-urlencoded'); //to send proper header info (optional, but good to have as it may sometimes not work without this)
When submitting a form with file uploads, the `multipart/form-data` content type is used. This type of request is commonly used when uploading files or submitting forms that contain binary data.
To perform a `multipart/form-data` POST request, the following steps can be followed:
1. Set the `Content-Type` header to `multipart/form-data`.
2. Create a boundary string that will be used to separate different parts of the request.
3. Construct the request body by appending each part of the request, including the file data, with the appropriate headers and the boundary string.
4. Send the request to the server.
Here is an example of a `multipart/form-data` POST request:
In this example, the request body consists of two parts: one for the file upload and another for the form field `name`. Each part is separated by the boundary string `---------------------------1234567890`. The `Content-Disposition` header specifies the name and type of each part.
By understanding how `multipart/form-data` POST requests work, you can effectively interact with web applications that require file uploads or handle binary data.
In this type of POST request, the data is sent as a series of parts, each containing a set of key-value pairs. This is commonly used when uploading files or submitting forms with complex data.
To perform a CSRF attack on a multipart/form-data POST request, you need to understand the structure of the request and manipulate the values of the key-value pairs.
Here's an example of a multipart/form-data POST request:
To perform a CSRF attack, you would need to change the value of the `csrf_token` field to the attacker's CSRF token. This can be done by intercepting the request and modifying the value before it is sent.
Keep in mind that some websites implement additional security measures to prevent CSRF attacks, such as checking the `Referer` header or using anti-CSRF tokens that are tied to the user's session.
In some cases, you may encounter a web application that uses an iframe to display content from another domain. This can be a security risk, as an attacker could potentially use this iframe to perform Cross-Site Request Forgery (CSRF) attacks.
일부 경우에는 웹 애플리케이션이 다른 도메인에서 내용을 표시하기 위해 iframe을 사용할 수 있습니다. 이 경우, 공격자는 이 iframe을 이용하여 Cross-Site Request Forgery (CSRF) 공격을 수행할 수 있습니다.
To exploit this vulnerability, the attacker can create a form within the iframe and submit it automatically using JavaScript. This form can be designed to perform any action on the target website, such as changing the user's password or making a purchase.
이 취약점을 악용하기 위해, 공격자는 iframe 내에서 폼을 생성하고 JavaScript를 사용하여 자동으로 제출할 수 있습니다. 이 폼은 사용자의 비밀번호 변경이나 구매 등 타겟 웹사이트에서 원하는 동작을 수행할 수 있도록 설계될 수 있습니다.
To prevent this type of attack, web developers should implement measures such as using anti-CSRF tokens or implementing the SameSite attribute for cookies. Additionally, it is important to ensure that the iframe content is trustworthy and originates from a trusted source.
이러한 유형의 공격을 방지하기 위해, 웹 개발자는 anti-CSRF 토큰을 사용하거나 SameSite 속성을 쿠키에 구현하는 등의 조치를 취해야 합니다. 또한, iframe 내용이 신뢰할 수 있고 신뢰할 수 있는 출처에서 비롯되었는지 확인하는 것이 중요합니다.
To perform a CSRF attack, you need to steal the CSRF token from the target website and then use it to craft a malicious POST request. Here's how you can do it:
1.**Stealing the CSRF Token**: The CSRF token is typically embedded in the HTML source code of the target website. You can use various techniques like cross-site scripting (XSS) or social engineering to trick the victim into executing a script that extracts the CSRF token. Once you have the token, store it for later use.
2.**Crafting the Malicious POST Request**: With the stolen CSRF token, you can now craft a POST request to perform the desired action on behalf of the victim. Make sure to include all the necessary parameters and values required by the target website. You can use tools like cURL or Burp Suite to send the POST request.
3.**Sending the POST Request**: Once you have crafted the malicious POST request, you need to send it to the target website. This can be done by either submitting a form or by making an AJAX request. The target website will process the request, assuming it is legitimate because it contains the stolen CSRF token.
By successfully executing this attack, you can trick the target website into performing actions on behalf of the victim without their consent. This can lead to various security vulnerabilities, such as changing account settings, making unauthorized transactions, or even gaining administrative access. It is important for web developers to implement proper CSRF protection mechanisms to prevent such attacks.
### **CSRF 토큰을 도용하고 iframe, form 및 Ajax를 사용하여 POST 요청 보내기**
In this technique, we will steal the CSRF token from the target website and use it to send a malicious POST request. We will accomplish this by utilizing an iframe, a form, and Ajax.
이 기술에서는 대상 웹 사이트에서 CSRF 토큰을 도용하여 악성 POST 요청을 보냅니다. 이를 위해 iframe, form 및 Ajax를 활용합니다.
#### **1. Stealing the CSRF Token**
#### **1. CSRF 토큰 도용하기**
To steal the CSRF token, we can use an iframe to load a page from the target website that contains the token. We can then access the token using JavaScript and store it in a variable.
CSRF 토큰을 도용하기 위해 iframe을 사용하여 토큰을 포함하는 대상 웹 사이트의 페이지를 로드할 수 있습니다. 그런 다음 JavaScript를 사용하여 토큰에 액세스하고 변수에 저장할 수 있습니다.
var csrfToken = document.getElementById('csrfFrame').contentWindow.document.getElementById('csrfToken').value;
</script>
```
#### **2. Sending the POST Request**
#### **2. POST 요청 보내기**
Next, we will use a form to construct the malicious POST request. We will set the action attribute of the form to the target URL and include any necessary input fields.
다음으로, 악성 POST 요청을 구성하기 위해 form을 사용합니다. form의 action 속성을 대상 URL로 설정하고 필요한 입력 필드를 포함합니다.
To perform a Cross-Site Request Forgery (CSRF) attack, you need to steal the CSRF token from the target website and then use it to send a malicious POST request. One way to achieve this is by using an iframe and a form.
CSRF 토큰을 도용하여 악성 POST 요청을 보내기 위해 크로스 사이트 요청 위조 (CSRF) 공격을 수행하려면 대상 웹 사이트에서 CSRF 토큰을 도용한 다음 사용해야 합니다. 이를 위해 iframe과 폼을 사용하는 방법이 있습니다.
First, you need to create an iframe element in your malicious website. Set the source of the iframe to the target website's URL. This will load the target website inside the iframe.
먼저, 악성 웹 사이트에서 iframe 요소를 생성해야 합니다. iframe의 소스를 대상 웹 사이트의 URL로 설정합니다. 이렇게 하면 iframe 내에서 대상 웹 사이트가 로드됩니다.
```html
<iframesrc="https://target-website.com"></iframe>
```
Next, you need to create a form element inside the iframe. Set the action attribute of the form to the URL where the POST request should be sent. Include any necessary input fields in the form, such as the target website's login credentials or any other data required for the request.
다음으로, iframe 내부에 폼 요소를 생성해야 합니다. 폼의 action 속성을 POST 요청을 보내야 할 URL로 설정합니다. 폼에는 대상 웹 사이트의 로그인 자격 증명 또는 요청에 필요한 기타 데이터와 같은 필요한 입력 필드를 포함해야 합니다.
Make sure to include a hidden input field named "csrf_token" and set its value to the stolen CSRF token. This will ensure that the POST request includes the valid CSRF token.
"csrf_token"이라는 숨겨진 입력 필드를 포함하고 그 값을 도용한 CSRF 토큰으로 설정하는 것을 잊지 마세요. 이렇게 하면 POST 요청에 유효한 CSRF 토큰이 포함됩니다.
When the malicious website is loaded, the iframe will automatically load the target website and submit the form, sending the POST request with the stolen CSRF token.
One way to perform a CSRF attack is by stealing the victim's authentication token and sending it using two iframes. This attack can be executed in the following steps:
1. The attacker creates a malicious website that contains two iframes.
2. The first iframe is loaded with the target website's login page.
3. The second iframe is loaded with a page on the attacker's website that contains a form to perform a specific action on the target website.
4. When the victim visits the malicious website, the first iframe automatically submits the login form using the victim's credentials.
5. Once the victim is logged in, the second iframe automatically submits the form on the attacker's website, which includes the stolen authentication token.
6. The target website receives the request with the stolen token, considering it as a legitimate request from the victim.
7. The action specified in the form on the attacker's website is performed on the target website, potentially leading to unauthorized actions or data leakage.
To prevent this type of attack, web developers should implement measures such as using anti-CSRF tokens, validating the origin of requests, and implementing strict access controls.
### **Ajax를 사용하여 CSRF 토큰을 도용하고 폼을 통해 POST 요청 보내기**
To perform a Cross-Site Request Forgery (CSRF) attack, you can use Ajax to steal the CSRF token and then send a POST request using a form.
CSRF attacks exploit the trust that a website has in a user's browser. By tricking the browser into making a request on behalf of the user, an attacker can perform actions without the user's knowledge or consent.
To steal the CSRF token, you can use Ajax to make a GET request to the target website's endpoint that returns the token. Once you have the token, you can then use it to craft a POST request.
// Step 2: Craft the POST request with the stolen CSRF token
var form = document.createElement('form');
form.method = 'POST';
form.action = '/endpoint-to-submit-form';
var input = document.createElement('input');
input.type = 'hidden';
input.name = 'csrf_token';
input.value = csrfToken;
form.appendChild(input);
document.body.appendChild(form);
form.submit();
}
};
xhr.send();
```
In this example, the Ajax request is made to the `/endpoint-that-returns-csrf-token` endpoint, which should return the CSRF token as a response. Once the token is obtained, a new form is created with the necessary input fields, including the stolen CSRF token. Finally, the form is submitted, triggering the POST request with the stolen token.
It's important to note that CSRF attacks can be prevented by implementing proper CSRF protection mechanisms, such as using anti-CSRF tokens, checking the origin of requests, and implementing SameSite cookies.
