CSRF(Cross Site Request Forgery)

신상현·2021년 6월 16일
1


개요

CSRF(Cross Site Request Forgery)란 사이트 간 요청 위조이다.
해커가 사용자의 권한을 도용하여 사용자의 의지와는 무관하게 해커가 의도한 행위를 특정 웹사이트에 요청하게 만드는 공격이다. XSRF라고도 불린다.

대략적인 시나리오

  1. 공격자는 피싱 사이트에 공격 코드를 삽입한다.
  2. 사용자는 공격자가 구성한 피싱 사이트에 접속한다.
  3. 공격 코드가 실행되고, 사용자의 권한으로 제 3의 사이트에 요청을 보낸다.
  4. 정보를 받아서 공격자가 냠냠 OR 권한으로 할 수 있는 행동을 한다.

정리하면,

공격자가 사용자를 홀리고 (광고성 글),
사용자의 권한을 이용하여 공격자에게 이로운 일을 한다.

(다크 아칸이 떠오릅니다! )

다음의 상황을 가정해보자

  • 사용자는 공격을 시도하는, 제 3의 사이트에 로그인이 되어있다,
  • 공격자는 다음과 같은 코드를 피싱 사이트에 삽입했다.
    => widthheight가 0 이기때문에 사용자는 인지할 수 없다.
<img src="사용자 비밀번호 가져오기" width="0" height="0" />

기본적으로 <img> 태그는 GET 요청으로 수행된다.
만약 src의 값이 사용자 비밀번호를 가져오는 url 이었다면, 홀라당 개인정보를 털렸을 것이다.

CSRF를 방어하자!

1. Referer 검증

Request Header에 포함된 Referer는 현재 요청된 페이지의 링크 이전의 웹 페이지 주소를 포함한다.
(그리고 Referer는 실제로 단어 "Referrer"에서 철자를 빼먹은 것입니다ㅋㅋㅋㅋ)
요청을 받는 서버는 CSRF를 막기위해 정해준 Referer만 허용해주는 유효성 검사 로직을 추가하는 조치를 취한다.

이후에 피싱페이지에서 의도하지 않은 행위를 한다면,
이전에 작성한 Referer 값 유효성 검사에서 걸러질 것이다.
즉, 해당 요청이 요청될 수 있는 위치가 아닌 곳은 예외를 발생시켜서 막을 수 있다.

그러나, 오히려 내가 설정해준 위치에서 XSS 취약점이 발견된다면,
이를 통해서 CSRF가 수행될 수 있다는 단점이 있다.

2. CSRF Token 검증

  1. 로그인을 할 때, CSRF Token을 생성해서 세션에 저장한다.
  2. CSRF Token 을 페이지 요청 태그의 hidden 값에 넣어준다.
    => Ex) <input type="hidden" name="_csrf" value="${CSRF_TOKEN}" />
  3. 그리고 요청마다 CSRF Token 을 같이 보낸다.
  4. 서버에서는 요청이 들어오면, CSRF Token을 검증한다.

그러나 Referer 검증과 마찬가지로, XSS 공격을 통해서 수행될 수 있다.

(아니 선생님...)

---

[출처]

profile
개발자 싱상형

0개의 댓글