CSRF Defense

CSRF Defenses (server side)

CSRF 공격은 공격자가 사이트를 거쳐 "서버에 있는 데이터를 조작하거나 정보를 빼오는 등의 형태"라는 걸 알아보았다.

그렇다면 CSRF 공격을 막기 위해선 어떤 방법이 있을지 살펴보자.

 

(* server side = CSRF Defense는 서버에 의해 실행된다.)

 

 

---

:: CSRF Tokens

사용자가 로그인 페이지에 접근할 때마다 서버는 CSRF token을 만들어 응답과 같이 보낸다.

CSRF token을 받은 사용자는 자신의 로그인 정보를 입력한 form을 제출할 때 이 토큰을 함께 보내야 한다.

 

 

만약 CSRF token이 서버가 만든 값과 일치하지 않으면 사용자의 요청을 처리해주지 않으며
Session token과 달리 CSRF token은 request마다 달라진다. 

 

* sesstion token = login & logout까지 동일한 값으로 유지된다.

 

 

---

 

1. 사용자가 비밀번호 변경 페이지를 달라고 서버에 요청하면

2. 서버는 페이지와 함께 CSRF Token을 만들어 답장한다. 

3. 사용자의 브라우저는 받은 응답을 토대로 웹 페이지를 만들어 화면에 출력한다.

4. 사용자가 비밀번호 변경 내용을 입력하고 제출 버튼을 누르면 서버로 이 결과가 날아간다. 

5. 서버는 자신이 받은 요청의 Token을 보고 자신이 갖고 있는 Token과 비교해 일치하면 요청 내용을 처리해 준다.

---

CSRF Token이 적용되면 공격자가 사용자를 속여 대상 서버에 요청을 보낸다고 해도 토큰이 없기도 하고,

공격자가 토큰을 만든다고 하더라도 이 토큰 값은 정상 서버가 만든 토큰이 아니기 때문에 서버는 이 요청을 처리해주지 않는다!

 

---

 

1. 사용자가 속아 공격자의 서버로 요청을 보내게 되면 

 

2. 공격자의 서버는 정상 서버의 응답과 똑같이 생긴 페이지를 응답으로 보낸다.

다만 이 응답은 유효한 Token을 갖고 있지 않고, 공격자가 Token을 만든다고 하더라도 정상 서버가 만든 Token이 아니다.

 

3. 아무것도 모르는 사용자가 자신의 정보를 입력하고 제출 버튼을 누르면 이 요청은 공격자 서버가 아닌 

정상 서버로 날아간다. (공격자의 목표가 사용자의 인증 권한을 이용해 대상 서버에 접근하는 것이기 때문에)

 

4. 사용자의 요청을 받은 정상 서버는 Token을 확인해 보지만 Token이 없거나 자신이 갖고 있는 Token이 아니기 때문에

해당 요청을 폐기하는 것

---

 

:: Referer validation

referer : 요청메시지를 보내기 전에 사용자가 방문했던 페이지

웹 브라우저의 방문 기록을 가지고 확인하는 방법으로 Same site cookie attribute 보다 좀 더 폭넓게 수용하는 방어 기술이다. 

referer에 해당하는 도메인이 whitelist에 있는 도메인이면 okay!

 

* issue) private information이 노출될 수 있어 모든 웹 브라우저에서 사용하진 않는다.

 

 

:: Same site cookie attribute

referer validation과 비슷하지만 더 깐깐한 기준을 적용하는 방법이라 보면 된다. 

 

사용자가 방문했던 페이지의 도메인과 접근하고자 하는 페이지의 도메인을 비교하여 처리 여부를 판단한다.

만약 사용자가 evil.com이라는 페이지를 통해 naver 로그인 페이지로 접근해 요청을 보냈다면 도메인이 다르기 때문에 

사용자의 요청을 처리하지 않는다.