CSRF : LAB [5]
DATE : 2024/1/29
Last updated
DATE : 2024/1/29
Last updated
CSRF 공격을 수행하기 위해 이번에도 숨겨진 취약점을 찾아보도록 하자.
일단 LAB에서 제공하는 wiener:peter 계정으로 로그인 한다.
로그인 한 사용자에게는 메일을 수정하는 기능이 제공되는 데
수정할 메일을 입력하고 엔터를 누르면 아래와 같이 request가 날아가게 된다.
메일을 수정하기 위해선 사용자가 입력한 메일과 csrf token이 필요한 걸 볼 수 있는데
과연 이 토큰에 대한 처리가 온전하게 이루어져 있는 지 확인해 봐야겠다.
우선, csrf token을 지운 경우에는 Missing parameter 'csrf' 문구가 나오는 걸 봐서
반드시 csrf token을 보내야 하는 듯하다.
그렇다면 csrf token을 보내되, 임의의 값이면 괜찮을까??
token을 수정해봤지만 이번엔 유효하지 않은 token이라고 거절 당했다.
그렇다면,, 요청 method를 바꿔 보자..!
Post method -> Get method로 요청을 변경한 뒤, csrf token을 제거해 보내봤다.
결과는 위와 같이 성공!
Get method로 메일 수정 요청을 보내는 경우에는 csrf token이 없어도 프로세스가 문제 없이
처리되는 상황이다.
그렇다면 우리는 Get method로 스크립트를 짜서 사용자에게 보내주면 끝이다.
csrf token은 따로 필요 없기 때문에 수정할 메일만 <input> tag로 삽입하고
자동으로 form을 제출하도록 <script>를 작성했다.
모든 요청이 Get & Post method로 전달할 수 있는 건 아니다.
상황에 따라 특정 method를 제한해두는 경우도 있는데, CSRF 공격에서는
개인적으로 Get method가 Post method보다 편리하다.
링크 형태(Get method)로 CSRF 공격이 이루어지는 걸 막기 위해 "Get method를 차단하자!"는
대안을 내놓기도 하는데 사실 CSRF는 XSS 취약점이 존재하는 한 POST method로 공격이 가능하다.
그렇다 보니 이번 LAB처럼 method가 제한되지 않는 경우,
method에 따라 적절한 처리를 하지 않은 게 취약점으로 작용할 수도 있지만 반대로
method를 제한한다고 해서 CSRF 공격을 막을 수 있는 100점 짜리 대안이 되는 건 아니라는 걸
알 필요가 있다!!
준비한 스크립트를 피해자에게 보내주기만 하면 이번 LAB도 어렵지 않게 해결할 수 있다.
