230122 항해99 77일차 CSRF

요니링 컴터 공부즁·2023년 2월 13일
0
post-custom-banner
  • CSRF 공격(Cross Site Request Forgery)은 웹 어플리케이션 취약점 중 하나로 인터넷 사용자(희생자)가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 만드는 공격이다.
  • CSRF를 통해 해커는 희생자의 권한을 도용하여 중요 기능을 실행하는 것이 가능하다. 예를 들어, 페이스북에 희생자의 계정으로 광고성 글을 올리는 것이 가능해진다.
  • CSRF는 해커가 사용자의 컴퓨터를 감염시키거나 페이스북 서버를 해킹해서 이뤄지는 공격은 아니다. CSRF 공격이 이뤄지려면 다음 조건이 만족되어야한다.
    • 위조 요청을 전송하는 서비스(페이스북)에 희생자가 로그인한 상태
    • 희생자가 해커가 만든 피싱 사이트에 접속
  • 언뜻 보면 이 두 조건을 다 만족하기가 어려울 것 같지만 생각처럼 드문 일은 아니다. 예를 들어 페이스북, 네이버, 구글 등의 유명 사이트는 보통 PC에서 자동 로그인을 해놓은 경우가 많고 피싱 사이트는 피싱 메일, 음란 사이트(?) 등을 통해 접속될 수 있다. 또한 희생자가 해커가 만든 피싱 사이트를 접속하지 않더라도 해커가 XSS 공격을 성공한 정상 사이트를 통해 CSRF 공격이 수행될 수도 있다.

방어 기법

대표적으로 다음 2가지 방어기법이 있다.

  • Referrer 검증
  • Security Token 사용 (A.K.A CSRF Token)
  • 일반적으로 CSRF 공격 방어는 조회성(HTTP GET Method) 데이터는 방어 대상으로 두지 않고, 쓰기/변경이 가능한 POST, PATCH, DELETE Method에만 적용하면 된다. 물론 정말 중요한 데이터를 조회하거나 GET을 통해 쓰기/변경 등의 동작을 한다면 GET Method에도 방어를 해야할 수도 있다.

Referrer 검증

  • Back-end 단에서 requestreferrer를 확인해 domain (ex. *.facebook.com) 이 일치하는 지 검증하는 방법이다. 일반적으로 referrer 검증만으로 대부분의 CSRF 공격을 방어할 수 있다. 하지만 같은 도메인 내의 페이지에 XSS 취약점이 있는 경우 CSRF 공격에 취약해질 수 있다. domain 단위 검증에서 좀 더 세밀하게 페이지 단위까지 일치하는지 검증하면 도메인 내의 타 페이지에서의 XSS 취약점에 의한 CSRF 공격을 방어할 수 있다.

Security Token 사용 (A.K.A CSRF Token)

  • Referrer 검증이 불가한 환경이라면, Security Token를 활용할 수 있다. 우선 사용자의 세션에 임의의 난수 값을 저장하고 사용자의 요청마다 해당 난수 값을 포함 시켜 전송시킨다. 이후 Back-end 단에서 요청을 받을 때마다 세션에 저장된 토큰 값과 요청 파라미터에 전달되는 토큰 값이 일치하는 지 검증하는 방법이다. 이 방법도 결국 같은 도메인 내에 XSS 취약점이 있다면 CSRF 공격에 취약진다.
  • Double Submit Cookie 검증은 Security Token 검증의 한 종류로 세션을 사용할 수 없는 환경에서 사용할 수 있는 방법이다. 웹브라우저의 Same Origin 정책으로 인해 자바스크립트에서 타 도메인의 쿠키 값을 확인/수정하지 못한다는 것을 이용한 방어 기법이다. 스크립트 단에서 요청 시 난수 값을 생성하여 쿠키에 저장하고 동일한 난수 값을 요청 파라미터(혹은 헤더)에도 저장하여 서버로 전송한다. 서버단에서는 쿠키의 토큰 값와 파라미터의 토큰 값이 일치하는 지만 검사하면 된다. 서버에 따로 토큰 값을 저장할 필요가 없어 위에서 살펴본 세션을 이용한 검증보다 개발 공수가 적은 편이다. 피싱 사이트에서는 도메인이 달라 facebook.com 쿠키에 값을 저장하지 못하므로 (Same Origin 정책) 가능한 방어 기법이다.

참조: CSRF 공격이란? 그리고 CSRF 방어 방법

post-custom-banner

0개의 댓글