[웹해킹] CSRF 실습

CSRF란?

공격자가 사용자가 의도하지 않은 작업을 수행하도록 유도할 수 있는 웹 취약점.

 

작동 조건

1. 공격자가 유도할만한 행동이 있어야 한다.

-> 비밀번호/ 이메일 변경.

 

2. 사용자 식별 정보(인증)를 쿠키에 담긴 세션ID 하나에만 의존하는 방식

 

3. 요청에 무작위 토큰이나 값이 없음 -> 공격자가 쉽게 요청 생성 가능.

 

예시)

1. 피해자가 로그인된 상태(브라우저에 로그인 쿠키를 가지고 있음)로 공격자 페이지를 방문
2. 공격자 페이지의 스크립트/폼이 취약 사이트로 요청을 보냄
3. 브라우저는 같은 도메인으로의 요청에 대해 자동으로 쿠키를 포함사용자가 수동으로 첨부한 게 아님.
4. 서버는 요청에 포함된 세션 쿠키를 보고 정상 사용자가 보낸 요청으로 판단하여 이메일을 변경
→ 결과: 피해자의 이메일이 공격자 주소로 바뀌고, 계정 탈취(비밀번호 재설정 등)로 이어질 수 있음.

브라우저가 쿠키를 자동으로 포함시키는 특성 때문에, 공격자는 사용자가 모르는 사이에 "인증된" 요청을 위조할 수 있다.

 

XSS와 CSRF의 차이점

XSS

• 공격자가 악성 스크립트(JavaScript)를 웹페이지에 삽입해 브라우저 내에서 실행시킴
• 사용자가 악성 스크립트가 삽입된 페이지를 열면 공격 발생
• 정보를 훔치거나 브라우저 내부 조작
• 공격자가 "피해자의 브라우저 안"에서 직접 행동함.
→ "브라우저 내부 해킹"

양방향(two-way)
• 공격자가 브라우저 안에서 코드를 실행하므로, 요청·응답 모두 제어 가능.

 

CSRF

• 공격자가 사용자 대신 요청을 보내도록 속임 (피해자의 브라우저 이용)
• 사용자가 로그인된 상태로 공격자 사이트에 접속하면 공격 발생
• 서버에 잘못된 요청을 보내게 만듦
• 공격자가 "피해자의 브라우저를 이용해서 서버에 요청을 보냄."
→ "피해자 대신 요청 보내기"

• CSRF = 단방향(one-way)
• 공격자는 요청을 보내게 할 수는 있지만, 응답을 볼 수 없음.
•  -> "요청만 유도".

 

CSRF 방어 방법

1. CSRF Token (CSRF 토큰)

• 가장 효과적인 방법.
• 서버가 매 요청마다 랜덤하고 예측 불가능한 토큰(문자열)을 생성해서 폼이나 요청에 포함시킴.
• 사용자가 폼을 제출할 때, 같은 토큰을 함께 보내야 서버가 요청을 인정함.
• 공격자는 이 토큰 값을 알 수 없기 때문에, 피해자 대신 올바른 요청을 만들 수 없음.

 

2. SameSite Cookie
• 브라우저 측 방어 기능.
• 쿠키가 다른 사이트에서 오는 요청에 포함되지 않도록 제한하는 설정. (즉, 외부 페이지에서 자동으로 요청을 보낼 수 없음 → CSRF 차단)

3. Referer-based Validation (리퍼러 검증)
• 요청의 출처(Referer 헤더)를 확인해서 같은 도메인에서 보낸 요청만 허용하는 방법.
• 공격자 사이트(evil.com)에서 온 요청이면 Referer 값이 다르기 때문에 차단 가능.
• 하지만 일부 브라우저나 프록시가 Referer를 제거할 수 있어 신뢰도가 낮음.

 

실습

https://portswigger.net/web-security/csrf/bypassing-token-validation/lab-token-validation-depends-on-request-method

Web Application Security, Testing, & Scanning - PortSwigger

 

이런 블로그 사이트가 나온다.

My account 버튼을 눌러 문제에서 제공된 정보로 로그인을 해준다.

아무 계정이나 넣고 update email을 해준다.

그러면 이렇게 Email이 업데이트 된다.

버프스위트로 해당 패킷을 잡고

request method를 변경해준다.

이메일도 변경해주고 send 해준다.

그러면 사이트에서도 이메일 주소가 변경된 걸 확인할 수 있다.

상단에 있는 Go to exploit sever 버튼을 눌러준다.

Body에 위와 같이 코드를 넣고 View exploit 버튼 눌러준다.

이메일이 변경되는걸 확인할 수 있다.

 

다른 문제도 풀어보자.

https://portswigger.net/web-security/csrf/bypassing-token-validation/lab-token-validation-depends-on-token-being-present

Web Application Security, Testing, & Scanning - PortSwigger

 

이런 블로그 사이트가 나온다.

문제에서 제공된 정보로 로그인을 해준다.

Email이 업데이트 된 걸 확인하고 상단에 있는 Go to exploit sever 버튼을 눌러준다.

exploit html을 저렇게 입력하고 View exploit 버튼을 눌러준다.

 

Email이 바뀐걸 확인할 수 있다.