< 문제 >
Lab: CSRF where token validation depends on request method | Web Security Academy
This lab's email change functionality is vulnerable to CSRF. It attempts to block CSRF attacks, but only applies defenses to certain types of requests. To ...
portswigger.net
< Write-Up >
해당 문제에서는 단순히 POST로 요청 시 CSRF 취약점을 이용할 수 없다. 그래서 CSRF 검증 우회 시도를 아래 그림 1, 2와 같이 해보았다.
그림 1의 시도는 서버단에서 CSRF 검증을 실시 하지만, 토큰의 존재만을 확인한다면 우회될 수 있게 , CSRF 토큰 값을 조작해 요청해 보았고, 서버 측에서 해당 부분에 대해 적절한 검증이 이뤄짐을 확인했다.
그림 2의 시도는 서버 측에서 CSRF 토큰의 존재를 확인하지 않고, 오로지 유효성만을 검증하는 로직으로 구성되어 있는지 확인할 수 있는 요청이다. 그림 1의 경우와 마찬가지로, 서버 측에서 해당 부분 적절한 보안조치를 취함을 알 수 있다.
사실 문제에서 이미 볼 수 있듯이 요청 Method를 변경해 CSRF 취약점을 유발시켜야 한다. 그래서 아래 그림 3과 같이 GET 요청으로 email 변경을 시도해 보았고, email이 변경되었다.
이제, 문제 내의 exploit 서버로 가서 Victim에게 아래 Payload를 전달한다.
<img src="https://0acc000d0418129581aec0c100a200c2.web-security-academy.net/my-account/change-email?email=White@test.com" />
<img> 태그는 소스를 외부에서 불러오기에, 해당 url로 요청을 보내게 되며, GET 요청을 통해 CSRF 취약함을 확인할 수 있었다.
한줄 평: CSRF 상당히 재밌다.
