Bypass referer check logic for CSRF

Referer header check is probably the most frequently used CSRF countermeasure. It’s easier to implement and less performance issues than the token approach, so it’s the preferred approach, and that’s the some risk for bypass.

CSRF 대응방안 중 아마 가장 많은 형태로 사용되고 있는게 Referer 헤더 체크 일 것 같습니다. 토큰 운영 방식에 비해 구현도 쉽고 성능적인 이슈도 덜하다 보니 선호되는 방식인데요, 그만큼 우회에 대한 리스크도 동일하게 가져갑니다.

Today I’m going to sort out some ways to bypass the referrer check in case of CSRF.

오늘은 CSRF 시 Referer 체크를 우회하는 방법들을 좀 정리해둘까 합니다. (매번 익숙함과 감으로 하니, 가끔씩 놓치는게 생기더군요..)

TL;DR

Pattern

- https://hahwul.com
- https://hahwul.com?white_domain_com
- https://hahwul.com;white_domain_com
- https://white_domain_com.hahwul.com
- https://hahwulwhite_domain_com

Payloads

https://hahwul.com/csrf.html
https://hahwul.com/csrf.html?white_domain_com
https://hahwul.com/csrf.html;white_domain_com
https://white_domain_com.hahwul.com/csrf.html
https://hahwulwhite_domain_com/csrf.html

If there’s anything missing, please leave a comment or tweet. 혹시나 제가 빼먹은 방식이 있다면 댓글주세요.

Detilas..

This is similar to Bypass Host (URL) Valid Check except for non-protection. However, there are cases that can not be actual attacks, so please refer to the following.

우선 검증 안하는 케이스와 검증하는데 우회되는 케이스로 나눌 수 있고, 우회 패턴은 보통 도메인, 페이지 기반 검증을 우회하게 되는데, 이는 SSRF, CustomS Scheme, Open Redirect 등에서 쓰이는 Host(URL) 검증 우회 방식과 유사합니다. 그렇지만, Referer 헤더가 무조건적으로 전 도메인 주소를 따라가는건 아니라서, 가능한 케이스도 있고 안되는 케이스도 있으니 아래 내용 참고하셔서 보시면 좋을 것 같습니다.

Changed Referer Header in Bypass HOST(URL) Valid Check Case

- https://hahwul.com (O)
- https://hahwul.com?white_domain_com (O)
- https://hahwul.com;white_domain_com (O)
- https://hahwul.com/white_domain_com/../target.file (O)
- https://white_domain_com.hahwul.com (O)
- https://hahwulwhite_domain_com (O)
- file://123.white_domain_com (X) 
- https://white_domain_com@hahwul.com (X)
- https://hahwul.com#white_domain_com (X)
- https://hahwul.com\.white_domain_com (X)
- https://hahwul.com/.white_domain_com (X)

redirect

- 301 (X) 
- 302 (X)
- 307 (X)
- 308 (X)

In common, Redirect types cannot use these pages to trick the referrer because the page that became the source is the reference.

공통적으로 Redirect 종류들은 가장 source가 된 페이지가 referer가 되기 때문에 이런 페이지들을 이용해서 referer를 속일 수 없습니다 ㅜㅜ

Why?

https://hahwul.com (O)

Not protection logic, it’s run any 검증 안하면 당연히 됩니다.

https://hahwul.com?white_domain_com (O)

The referrer header contains parameters. 인자값의 경우 referer 헤더에 남아있습니다.

https://hahwul.com;white_domain_com (O)

The referrer header contains semi colon and behind string. ;(semi colon) 또한 referer 헤더에 남아있습니다.

https://hahwul.com/white_domain_com/../target.file (X)

In the Browsing step, processed ../ do not contain the referrer. 안되는게 맞지만, 아주 예외적으로 브라우저에서 ../ 를 처리해주지 않는 경우엔 가능합니다.

https://white_domain_com.hahwul.com (O)

Use subdomain 서브 도메인을 이용한 방법

https://hahwulwhite_domain_com (O)

Check only string pattern(Only hosts must be filtered correctly) 도메인 끝쪽만 구별한 경우(.까지 구별하지 않은 경우)

file://123.white_domain_com (X)

file:// scheme etc. does not generate referer headers. file:// 에서 발생한 요청은 Referer 헤더가 생기지 않습니다.

https://white_domain_com@hahwul.com (X)

In the Browsing step, processed ../ do not contain the referrer. @로 호스트를 분리하는 경우 실제 호스트 이름이 referer에 남게됩니다. => hahwul.com

https://hahwul.com#white_domain_com (X)

The referrer header not contains hash parameter. hash 문자는 referer에 남지 않습니다.

https://hahwul.com\.white_domain_com (X)

(%5c)가 path 처리(%2f)되서 당연히 안남습니다.

https://hahwul.com/.white_domain_com (O)

단순 문자열 검증의 경우 우회가 가능합니다.