TigerDemon
CSRF 정의 및 공격 기법 본문
CSRF(Cross-site request forgery) 정의 //사이트 간 요청 위조
- 공격자가 사용자가 의도하지 않은 작업을 수행하도록 유도할 수 있는 웹 보안 취약점
- 공격자는 피해자의 브라우저를 이용해 인증된 세션 쿠키를 자동으로 전송하게 만들어서 피해자 대신 요청을 실행시킨다.
- 공격자의 링크를 피해자가 클릭하면 로그인된 상태의 세션이 이용되어 이메일 주소가 공격자 계정으로 변경될 수 있다.
CSRF가 작동하는 조건
중요한 행동
- 공격자가 유도할만한 행동이 있어야함
ex) 비밀번호/이메일 변경
피해자가 애플리케이션 내에서 특권 역할을 가지고 있다면 공격자가 데이터와 기능을 제어할 수 있게됨
쿠키 기반 세션
- 사용자 식별 정보(인증)를 *쿠키에 담긴 **세션ID 하나에만 의존하는 방식
*쿠키 : 서버가 사용자의 브라우저에 저장시킨 작은 데이터(ex) session_id).
브라우저는 같은 사이트로 요청할 때 자동으로 이 쿠키를 함께 보낸다.
**세션 : 서버가 로그인 상태 등 사용자 상태를 기억하기 위한 서버측 저장소.
보통 쿠키에 담긴 session_id로 사용자를 식별
예측 가능한 요청
- 요청에 무작위 토큰이나 값이 없음 -> 공격자가 쉽게 요청 생성 가능
작업을 수행하는 요청에 공격자가 결정하거나 추측할 수 없는 값이 있는 매개변수가 포함되어 있지 않음
정상 사용자 요청
POST /email/change HTTP/1.1
Host:vulnerable-website.com
Content-type: application/x-www-form-urlencoded
Conent-Length: 30
Cookie: session=ythwsztyeQkAPzeQ5gHgTvLyxHfsAfE
email=wiener@normal-user.com- 사용자가 웹사이트에서 이메일 변경 버튼을 눌렀을 때 서버로 보내는 실제 HTTP 요청
- 서버는 Cookie: session=... 값을 보고 누가 보낸 요청인지(어떤 계정인지)판단
- 즉, 쿠키(session id)는 사용자의 로그인 상태 식별자 역할을 한다.
공격자 요청
<html>
<body>
<form action="https://vulnerable-website.com/email/change" method="POST">
<input type="hidden" name="email" value="pwned@evil-user.net" />
</form>
<script>
document.forms[0].submit();
</script>
</body>
</html>공격자는 이 HTML을 자기 사이트(혹은 이메일등)에 올려 피해자가 방문하게 한다.
폼은 보통 눈에 보이지 않게(hidden) 만들어져 있고, 스크립트가 즉시 submit()을 호출해 자동으로 POST 요청을 보낸다.
표면상 요청 내용을 정상 요청과 동일(같은 URL, 같은 파라미터 구조)이다. - 단지 email 값이 공격자가 원하는 값으로 바뀌었을 뿐.
과정
- 피해자가 로그인된 상태(브라우저에 로그인 쿠키를 가지고 있음)로 공격자 페이지를 방문
- 공격자 페이지의 스크립트/폼이 취약 사이트로 요청을 보냄
- 브라우저는 같은 도메인으로의 요청에 대해 자동으로 쿠키를 포함 (사용자가 수동으로 첨부한 게 아님)
- 서버는 요청에 포함된 세션 쿠키를 보고 정상 사용자가 보낸 요청으로 판단하여 이메일을 변경
-> 결과 : 피해자의 이메일이 공격자 주소로 바뀌고, 계정 탈취(비밀번호 재설정 등)로 이어질 수 있음
브라우저가 쿠키를 자동으로 포함시키는 특성 때문에, 공격자는 사용자가 모르는 사이에 '인증된' 요청을 위조할 수 있다.
CSRF 방어 방법
1. CSRF Token(CSRF 토큰)
가장 효과적인 방법
서버가 매 요청마다 랜덤하고 예측 불가능한 토큰(문자열)을 생성해서 폼이나 요청에 포함시킴
사용자가 폼을 제출할 때, 같은 토큰을 함께 보내야 서버가 요청을 인정함
공격자는 이 토큰 값을 알 수 없기 때문에, 피해자 대신 올바른 요청을 만들 수 없음
2. SameSite Cookie
브라우저 측 방어 가능
쿠키가 다른 사이트에서 오는 요청에 포함되지 않도록 제한하는 설정(즉, 외부 페이지에서 자동으로 요청을 보낼 수 없음 -> CSRF 차단)
3. Referer-based Validation(리퍼러 검증)
요청의 출처(Referer 헤더)를 확인해서 같은 도메인에서 보낸 요청만 허용하는 방법
공격자 사이트(evil.com)에서 온 요청이면 Referer 값이 다르기 때문에 차단 가능
하지만 일부 브라이저나 프록시가 Referer를 제거할 수 있어 신뢰도가 낮음
XSS vs CSRF
XSS
공격자가 악성 스크립트(JavaScript)를 웹페이지에 삽입해 브라우저 내에서 실행시킴
사용자가 악성 스크리트가 삽입된 페이지를 열면 공격 발생
정보를 훔치거나 브라우저 내부 조작
공격자가 '피해자의 브리우저 안'에서 직접 행동함
-> '브라우저 내부 해킹'
양방향(two-way)
공격자가 브라우저 안에서 코드를 실행하므로, 요청-응답 모두 제어 가능
CSRF
공격자가 사용자 대신 요청을 보내도록 속임(피해자의 브라우저 이용)
사용자가 로그인된 상태로 공격자 사이트에 접속하면 공격 발생
서버에 잘못된 요청을 보내게 만듦
공격자가 '피해자의 브라우저를 이용해서 서버에 요청을 보냄'
-> '피해자 대신 요청 보내기'
단방향(one - way)
공격자는 요청을 보내게 할 수는 있지만, 응답을 볼 수 없음
-> '요청만 유도'
'2025-SWLUG > 웹해킹' 카테고리의 다른 글
| burp suite로 CSRF 실습 2 (0) | 2025.11.18 |
|---|---|
| burp suite로 CSRF 실습 1 (0) | 2025.11.18 |
| burp suite로 Authentication vulnerabilities 실습 2 (0) | 2025.11.10 |
| burp suite로 Authentication vulnerabilities 실습 1 (0) | 2025.11.10 |
| Authentication vulnerabilities 정의 및 공격 기법 (0) | 2025.11.10 |
