CORS(교차 출처 리소스 공유)란 ?

CORS(교차 출처 리소스 공유)는 주어진 도메인 외부에 있는 리소스에 대한 제어된 액세스를 가능하게 하는 브라우저 메커니즘입니다. 동일 출처 정책( SOP ) 을 확장하고 유연성을 추가합니다 . 그러나 웹 사이트의 CORS 정책이 제대로 구성 및 구현되지 않은 경우 도메인 간 공격의 가능성도 있습니다. CORS는 CSRF( 교차 사이트 요청 위조 ) 와 같은 교차 출처 공격에 대한 보호가 아닙니다 .

 

동일 출처 정책

동일 출처 정책은 웹사이트가 소스 도메인 외부의 리소스와 상호 작용할 수 있는 기능을 제한하는 제한된 출처 간 사양입니다. 동일 출처 정책은 한 웹사이트에서 다른 웹사이트의 개인 데이터를 훔치는 것과 같은 잠재적으로 악의적인 도메인 간 상호 작용에 대한 대응으로 여러 해 전에 정의되었습니다. 일반적으로 도메인이 다른 도메인에 요청을 발행하도록 허용하지만 응답에 액세스할 수는 없습니다.

 

동일 출처 정책 완화

동일 출처 정책은 매우 제한적이며 결과적으로 이러한 제약을 피하기 위해 다양한 접근 방식이 고안되었습니다. 많은 웹 사이트는 원본 교차 액세스가 필요한 방식으로 하위 도메인 또는 타사 사이트와 상호 작용합니다. CORS(교차 출처 자원 공유)를 사용하여 동일 출처 정책의 제어된 완화가 가능합니다.

교차 출처 리소스 공유 프로토콜은 신뢰할 수 있는 웹 출처 및 인증된 액세스 허용 여부와 같은 관련 속성을 정의하는 HTTP 헤더 제품군을 사용합니다. 이들은 브라우저와 브라우저가 액세스하려는 교차 출처 웹 사이트 간의 헤더 교환에서 결합됩니다.

 

CORS 구성 문제로 인한 취약점

많은 최신 웹 사이트는 CORS를 사용하여 하위 도메인 및 신뢰할 수 있는 제3자의 액세스를 허용합니다. CORS의 구현은 실수를 포함하거나 모든 것이 제대로 작동하도록 지나치게 관대할 수 있으며, 이는 악용 가능한 취약성을 초래할 수 있습니다.

클라이언트 지정 Origin 헤더에서 서버 생성 ACAO 헤더

일부 응용 프로그램은 다른 여러 도메인에 대한 액세스를 제공해야 합니다. 허용된 도메인 목록을 유지 관리하려면 지속적인 노력이 필요하며 실수로 인해 기능이 중단될 위험이 있습니다. 따라서 일부 응용 프로그램은 다른 도메인에서 액세스를 효과적으로 허용하는 쉬운 경로를 사용합니다.

이를 수행하는 한 가지 방법은 요청에서 Origin 헤더를 읽고 요청하는 출처가 허용된다는 응답 헤더를 포함하는 것입니다. 예를 들어, 다음 요청을 수신하는 애플리케이션을 고려하십시오.

 

그러면 다음과 같이 응답합니다.

이러한 헤더는 요청 도메인( )에서 액세스가 허용되고 malicious-website.com교차 출처 요청에 쿠키( Access-Control-Allow-Credentials: true)가 포함될 수 있으므로 세션 내에서 처리될 것임을 나타냅니다.

애플리케이션이 헤더에 임의의 출처를 반영하기 때문에 Access-Control-Allow-Origin이는 절대적으로 모든 도메인이 취약한 도메인의 리소스에 액세스할 수 있음을 의미합니다. 응답에 API 키 또는 CSRF 토큰 과 같은 민감한 정보가 포함된 경우 웹사이트에 다음 스크립트를 배치하여 이를 검색할 수 있습니다.

 

Origin 헤더 구문 분석 오류

여러 출처로부터의 액세스를 지원하는 일부 애플리케이션은 허용된 출처의 화이트리스트를 사용하여 그렇게 합니다. CORS 요청이 수신되면 제공된 출처를 화이트리스트와 비교합니다. 원본이 허용 목록에 나타나면 Access-Control-Allow-Origin헤더에 반영되어 액세스 권한이 부여됩니다. 예를 들어 애플리케이션은 다음과 같은 일반 요청을 수신합니다.

 

애플리케이션은 허용된 원산지 목록에 대해 제공된 원산지를 확인하고 목록에 있는 경우 다음과 같이 원산지를 반영합니다.

 

CORS 원본 화이트리스트를 구현할 때 종종 실수가 발생합니다. 일부 조직은 모든 ​​하위 도메인(아직 존재하지 않는 미래의 하위 도메인 포함)에서 액세스를 허용하기로 결정합니다. 그리고 일부 애플리케이션은 하위 도메인을 포함하여 다양한 다른 조직의 도메인에서 액세스를 허용합니다. 이러한 규칙은 종종 URL 접두사 또는 접미사를 일치시키거나 정규식을 사용하여 구현됩니다. 구현에 실수가 있으면 의도하지 않은 외부 도메인에 대한 액세스 권한이 부여될 수 있습니다.

예를 들어 애플리케이션이 다음으로 끝나는 모든 도메인에 대한 액세스 권한을 부여한다고 가정합니다.

 

공격자는 도메인을 등록하여 액세스 권한을 얻을 수 있습니다.

또는 응용 프로그램이 다음으로 시작하는 모든 도메인에 대한 액세스 권한을 부여한다고 가정합니다.

공격자는 도메인을 사용하여 액세스 권한을 얻을 수 있습니다.

 

허용 목록에 있는 원본 값

Origin 헤더의 사양은 값을 지원합니다.

• 교차 출처 리디렉션.
• 직렬화된 데이터의 요청입니다.
• file:프로토콜 을 사용하여 요청 합니다.
• 샌드박스 처리된 교차 출처 요청.

일부 애플리케이션은 애플리케이션 null의 로컬 개발을 지원하기 위해 출처를 화이트리스트에 추가할 수 있습니다. 예를 들어 애플리케이션이 다음 교차 출처 요청을 수신한다고 가정합니다.

 

이 상황에서 공격자는 다양한 트릭을 사용하여 Origin 헤더의 값을 포함하는 교차 출처 요청을 생성할 수 있습니다. 이는 허용 목록을 충족하여 도메인 간 액세스로 이어집니다. 예를 들어 다음 형식의 샌드박스 교차 출처 요청을 사용하여 수행할 수 있습니다.

CORS 기반 공격을 방지하는 방법

CORS 취약점은 주로 잘못된 구성으로 발생합니다. 따라서 예방은 구성 문제입니다. 다음 섹션에서는 CORS 공격에 대한 몇 가지 효과적인 방어에 대해 설명합니다.

교차 출처 요청의 적절한 구성

Access-Control-Allow-Origin웹 리소스에 민감한 정보가 포함된 경우 헤더 에 출처를 올바르게 지정해야 합니다 .

신뢰할 수 있는 사이트만 허용

당연해 보이지만 Access-Control-Allow-Origin헤더에 지정된 출처는 신뢰할 수 있는 사이트여야 합니다. 특히, 유효성 검사 없이 교차 출처 요청의 출처를 동적으로 반영하는 것은 쉽게 악용될 수 있으므로 피해야 합니다.