2-2. 취약한 CORS 유형 (2) - 잘못 설정된 정규표현식(regex misconfiguration)

유형 (2) 설명

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

이전 글에서는 응답 Access-Control-Allow-Origin 헤더에 허용할 Origin만 화이트리스트로 관리해야 한다고 했다.

그렇다면 이 ACAO 헤더는 정규표현식을 활용해 example.com의 서브 도메인만 허용할 수 있을 것이다.

 

 

취약점 확인

Java에서 다음과 같은 정규표현식으로 화이트리스트를 관리한다고 해보자. 

private static final String ORIGIN_WHITELIST_REGEX = "[a-z]+.example.com";

얼핏 보면 www.example.com과   api.example.com과 같은 Origin을 허용하는 것 같다.

하지만 attackerexample.com과 같은 Origin도 포함되게 된다.

 

regex101을 통해 포함여부 확인

https://regex101.com/에서 위 정규표현식을 검증해본다.

(Case 1) attackerexample.com은 포함된다.

(Case 2) attacker.example.com도 당연히 포함된다.

(Case 3) attackerexamplecom은 포함되지 않았다.

(Case 4) attackerexampleXcom은 포함된다.

 

사실상 위 정규표현식은 *.example.com을 검증하는 것이 아닌 것이다.

.은 어떤 임의의 한 문자로 정의되어 있기 때문에 (Case 1)이나 (Case 4)가 포함되는 잘못된 결과가 나타나며,

(Case 3)의 경우는 example과 com 사이에 문자가 없기 때문에 제외되었다.

 

 

대응방안

정규표현식의 충분한 검증

이것도 간단하다.

위 소개된 정규표현식 검증 사이트 등을 활용해서,

화이트리스트로 관리할 도메인들을 테스트 케이스에 넣어보고,

예외되거나 의도치 않게 포함되는 Origin이 있는지 충분히 검증해야 한다.

위처럼 *.example.com만 허용하고 싶다면 다음과 같이

.이 문자열 그 자체로 표현될 수 있도록 \.으로 정규표현식을 작성하면 된다.

 

서브 도메인 허용마저 위험할까?

(Case 2)처럼 attacker.example.com이 허용되는 것에 대해서는,

기업이 메인 도메인을 선점한 후 DNS 레코드 편집을 통해 서브 도메인을 부여하기 때문에

공격자가 서브 도메인까지 사용해 공격을 할 가능성은 낮을 것 같다.

CORS와는 논외로 정상적인 도메인으로 접속 유도한 뒤,

DNS 스푸핑을 통해 공격자의 서버에 접근하도록 할 수는 있지만

침입탐지시스템이나 VPN, HTTPS, DNSSEC 등을 사용해 악성 트래픽 관리를 잘 하고 있다면 가능성은 거의 없다.

 

정규표현식을 잘 이해하지 못한 채로

운영서버에 배포까지 해버리는 경우는 드물지 않을까? 👽