[4달 1주차 주제 : CSRF : 대응, 추가내용: DoS]

---

1. 대응방안 : Referer 체크

이전 포스트에서 CSRF의 대응 방안 중 하나로 CSRF Token을 정리하였다.
그러나, CSRF Token 또한 iframe을 활용하여 우회가 가능하였다.
이번에는 CSRF의 다른 대응 방안으로 Referer 체크를 정리하고자 한다.

1) Referer 헤더란?

Referer 헤더 : 웹 페이지 요청 시 해당 요청이 어디서 발생하였는지를 나타내는 정보

HTTP 요청 패킷 안에 Referer 헤더가 존재

2) Referer 체크를 통한 CSRF 대응

• Referer을 통해 요청을 보낸 페이지를 검증하는 방식
  ▶ 예를 들어, 비밀번호 변경 요청의 Referer 경로가 마이페이지가 아닌 게시판으로부터 온 것이라면 이는 비정상적인 요청으로 간주
  
  

• Referer을 제대로 체크한다면, 우회가 불가능하다
  ▶ iframe을 사용한다고 하더라도, 해당 iframe의 referer 조작은 불가능하다.

3) Referer 체크의 한계
① 요청 / 응답 과정에서 에러가 발생하였을때 처리 방안으로 서비스를 중단하거나, 그냥 넘어가는 방법이 있다.

② 개발자들은 내가 작성한 코드가 예상치 못한 다른 곳에서 어떤 문제를 일으킬지 모르기 때문에 대부분 그냥 넘어가는 방법을 선택한다.

③ 또한 페이지 내에 예상치 못한 다른 정상 경로로 요청이 가능할 수도 있다.

④ 이러한 예상치 못한 경우까지 전부 서비스 장애로 지정하기도 어려운 부분이다.

이러한 이유로, Referer 헤더가 없는 경우 Referer 검증을 하지 않는 형태의 잘못된 예외처리가 되어있는 경우가 존재한다.

이는 CSRF Token에서도 마찬가지로, CSRF Token이 없다면 Token 검사를 하지 않는 방식으로 작성되기도 한다.

따라서, Referer 헤더를 지우거나 CSRF Token 파라미터를 없애고 요청을 보냄으로써 우회가 가능한 경우들이 존재한다.

4) Referer 체크 우회
referer 헤더를 전달하지 않는 방법은 다음과 같다.

<meta name="referrer" content="no-referrer">

(1) 게시글에서 CSRF 공격 시도
○ 게시판에서 이메일 변경 요청을 보내는 CSRF 스크립트 작성

(2) Referer 체크에 의해 요청 거부

(3) meta 태그 추가 : no-refferer

(4) referer 체크 우회 성공

---