[웹 해킹] CSRF 공격 총정리!

dreamhack.io 의 웹 해킹 코스를 공부중입니다.

저는 간략하게 저의 언어로 정리해놓은 것이므로, dreamhack.io를 이용하여 공부하시기 바랍니다^^!

 

CSRF(Cross Site Request Forgery) : 비 정상적으로 사용자의 의도와 무관하게 다른 사이트에 HTTP 요청을 보내는 것

 - CSRF가 가능한 이유 : 웹 브라우저가 크로스 사이트, 즉 다른 사이트로부터 시작된 요청에 쿠키를 함께 전송하기 때문

 

ㅇ CSRF 공격 조건

    1) 해당 웹 사이트가 쿠키를 이용한 인증 방식을 사용해야 함

        - 모든 HTTP 전송엔 쿠키가 함께 전송되기 때문에 쿠키에 저장된 세션 아이디도 전송

    2) 공격자가 사전에 알 수 없는 파라미터가 존재해서는 안됨

        - 자동입력 방지 문자를 넣어야 하는 요청은 공격자가 미리 알 수 없음

        - 패스워드 변경 기능에서 기존 패스워드를 입력 받는 다면 이 또한 공격자가 미리 알 수 없음

 

예시))

 *웹 구조

 

웹구조가 위와 같은경우,

<img src="/sendmoney?to=dreamhack&amount=1337">
<img src=1 onerror="fetch('/sendmoney?to=dreamhack&amount=1337');">
<link rel="stylesheet" href="/sendmoney?to=dreamhack&amount=1337">
...

와 같은 코드를 사용할 수 있다.

 

게시판과 같은 글에 위 코드를 올리면, 그 글에 접속하는 사람이 본인의 쿠키 권한으로 위 코드를 실행하여 돈을 입금하게 되는 구조!

 

 

ㅇ Mitigation

    1) 세션 쿠키 대신 커스텀 헤더를 사용하여 사용자 인증

        - 사용자 인증만을 위한 헤더를 추가(e.g. Authorization)

    2) 공격자가 예측할 수 없는 파라미터 추가 및 검증

        - Same Origin에서만 접근 가능한 데이터를 삽입(CSRF Tocken)

        - CAPTCHA

        - 정상적인 사용자만 아는 기존의 값을 검증(ex: 현재 비밀번호)

  >> 위 두가지 방법은 서버 사이드에서 추가적인 검증을 통해 CSRF를 방어하는 방법임.

       이는 서버코드에 검증 로직이 추가되는 방식이라 어쩔 수 없이 오버헤드가 발생함

 

* SameSite Cookie

  - 웹 브라우저가 쿠키를 다른 사이트로 부터 시작된 요청에 삽입할지를 SameSite 쿠키 설정을 보고 결정

    (새롭게 추가된 사항)

  - SameSite : 크로스 사이트에서 출발한 요청에 제한적으로 쿠키를 포하시키게 하는 옵션

     1) Strict : 모든 크로스 사이트에서 출발한 요청에 해당 쿠키를 삽입하지 않음

     2) Lax : Link, Prerender, Form GET을 제외한 요청에는 삽입하지 않음

     3) Normal : 기존과 같이 모든 요청에 삽입

     * 크롬 브라우저는 2020년 개발자가 강제로 SameSite=None; Secure;을 넣지 않는 이상 웹 브라우저에서 모든 쿠키에 SameSite=Lax를 강제함