CSRF(Cross-Site Request Forgery)

CSRF는 Victim의 의지 및 의도와는 무관하게 Attacker가 의도한 특정 행위를 웹 사이트에 요청하는 공격 기법이다.

 

원리는 사용자가 웹 사이트에 로그인한 상태에서 CSRF 공격 소스가 삽입 된 페이지를 열면 웹 사이트를 공격 하게 된다.

웹 사이트는 신뢰하는 사용자의 요청이기에 이를 수행함으로써 공격에 노출되게 되는 것이다.

 

[그림 1]

굉장히 많은 종류의 CSRF 모식도가 그려져 있는데 그중 하나를 퍼왔다. 이를 이용하여 설명 하고자 한다.

 

1.공격자가 사용자에게 공격소스가 삽입된 페이지를 보낸다.

2.로그인 되어 있는 사용자는 이를 실행하고 소스 대로 여러가지 행위를 요청한다.

3.웹은 소스대로 행위에 대한 결과 값을 공격자에게 송신한다.

 

이 모식도는 사용자의 정상적인 Session값을 탈취하여 공격자가 사용자를 대신하려는 것으로 보인다.

 

CSRF는 위 그림과 같은 일련의 방식으로 일어난다.

사용자가 어떻게든 공격 소스를 실행 하게끔 만드는게 이 공격 기법의 핵심이며 이를 위해 여러 방법이 사용된다.

(방법에 따라 모식도가 조금씩 달라진다.)

 

대응 방안

-Referrer 검증

Back-end에서 requet의 referer를 확인하여 전에 들어온 주소와 도메인이 일치하는지를 검증 하는 방법이다.

쉬운 보안이지만 CSRF의 전반적인 공격의 방어가 가능하다. XSS취약점이 존재할 경우 방어가 무의미하며 리퍼의경우 값이 변조 될수 있다. 그러면 어떻게 해야되는가?

 

X-CSRF 커스텀 헤더를 사용하는것이다.

웹 브라우저는 커스텀 헤더를 다른 도메인으로 전달하지 않는다.

따라서 공격자가 공격 페이지를 만들더라도 X-CSRF 헤더가 포함되지 않음을 알수 있다.

그렇다면 만들면 되지 않느냐? 아니다 XHR객체를 사용하더라도 정상적인 요청은 생성할 수 없다.

 

-CSRF Token 사용

사용자 세션에 임의의 값을 저장하여 모든 요청에 대하여 서버단에서 검증하는 방법이다.

XSS 취약점이 있을경우 무용지물

 

-Double-Submit Cookie Pattern

웹 브라우저의 Same Origin 정책으로 공격자가 쿠키값에는 접근 할수 없다는 점을 이용하여 브라우저는 토큰 값과 시크릿키값을 서버로 부터 받는다.

브라우저에서 write 요청시 header에 토큰 값을 주고 쿠키 값에 시크릿키를 부여하여 서버의 미들웨어에서 토큰값을 decode해 decode한 시크릿 쿠키 값과 일치하는지 체크한다.

XSS나 메타태그를 이용하여 쿠키값을 조작 할 수 있어 완벽하지는 않다.

 

 

 

사진 참조: https://stackhoarder.com/2019/08/19/laravel-%EA%B8%B0%EB%B3%B8-10-csrf-protection/