CSRF(Cross-Site Request Forgery)란?
공격자가 사용자의 인증된 세션을 이용하여 의도하지 않은 요청을 서버로 보내는 공격입니다.
예를 들어, 사용자가 로그인된 상태에서 공격자가 사용자의 세션을 탈취하여,
악성 요청이 자동으로 전송되도록 유도하고 원하지 않는 행동(예: 비밀번호 변경, 송금 요청 등)을 수행하게 만듭니다.
CSRF 동작원리
- 정상 접속 및 로그인
- 사용자가 정상적으로 웹사이트(example.com)에 로그인합니다.
- 브라우저는 로그인 상태를 유지하기 위해 세션 쿠키를 저장합니다.
- 피싱(공격자가 악성 링크 또는 이메일 전송)
- 공격자는 사용자가 클릭하도록 악성 링크를 포함한 이메일 또는 웹사이트를 만듭니다.
- 예: "보안 문제 해결을 위해 클릭하세요!"라는 메시지로 유도
- 패스워드 변경 요청 (자동 실행)
- 사용자가 피싱 링크를 클릭하면, 브라우저는 브라우저가 자동으로 세션 쿠키를 포함한 요청을 전송
- 사용자는 이 요청이 발생하는 것을 인식하지 못한 채 자신의 패스워드가 변경됩니다.
- 공격자가 변경된 패스워드로 접속
- 공격자는 사용자의 계정이 새로운 패스워드로 변경된 것을 알고 있으며, 새로운 패스워드로 로그인하여 계정 탈취가 가능합니다.
(참고) CSRF와 XSS 차이
CSRF와 XSS 공격 둘 다, URL를 통해서 악의적인 행위를 유도하지만, 공격하는 목적이 다릅니다.
1. CSRF(Cross-Site Request Forgery, 사이트 간 요청 위조)
- 사용자의 세션을 이용하여 원하지 않는 요청을 실행하는 공격
- 공격자는 사용자의 인증된 세션을 이용해 악성 행위를 수행할 수 있음
- 주요 목표: 비밀번호 변경, 송금, 관리자 권한 변경 등 조작된 요청 실행
- 사용자는 공격을 인지하지 못한 채 피해를 입음
2. XSS(Cross-Site Scripting, 사이트 간 스크립트 실행)
- 공격자가 악성 스크립트를 삽입하여 실행하는 공격
- 브라우저에서 실행되므로 쿠키, 세션, 로그인 정보 등 민감한 데이터를 훔칠 수 있음
- 주요 목표: 사용자의 정보 탈취, 웹페이지 변조, 세션 하이재킹(쿠키 탈취) 등
- XSS가 성공하면 추가적으로 CSRF 공격을 수행하는 것도 가능
즉, CSRF는 사용자의 권한을 악용하여 요청(Request)을 조작(Forgery)하는 것이고, XSS는 악성 스크립트(Script)를 실행하여 민감한 정보를 훔치는 것에 중점을 둡니다.
CSRF 실습
Low로 설정하고 진행하겠습니다.
CSRF 페이지로 이동하니, admin의 패스워드를 변경하는 페이지인 것으로 보입니다.
시험삼아 test라고 입력하고, change 버튼을 누릅니다.
패스워드가 변경됐다는 문구가 나옵니다.
로그아웃후, 패스워드를 test로 입력 시 로그인이 성공한 것을 확인할 수 있습니다.
버프스위트를 통해 패스워드 변경 버튼을 클릭할때, 어떤 패킷을 주고받는지 확인해 보기 위해 Intercept를 켜줍니다.
Change버튼을 누릅시다.
패스워드를 변경하기전에 이러한 쿼리를 요청하는 것을 알 수 있습니다.
해당 쿼리를 통해 패스워드를 변경하는 악성 URL를 만들면 됩니다.
이런 식으로 패스워드를 hacked로 바꾸는 악성 URL를 만들었습니다.
http://127.0.0.1:42001/vulnerabilities/csrf/?password_new=hacked&password_conf=hacked&Change=Change
URL에 해당 부분을 입력하고, 어떻게 동작하는지 확인해 보겠습니다.
Change 버튼을 누른 것과 마찬가지로 Password Change라는 문구가 뜹니다.
로그아웃 후, hacked로 패스워드입력 시 로그인이 성공하는 것을 알 수 있습니다.
(참고) 해당 URL을 활용하여 사용자가 악성 링크를 클릭하도록 유도하는 피싱 이메일을 작성하는 실습도 진행해보면 좋습니다.
대응방안
1. CSRF 토큰 사용
- CSRF 방지를 위해 각 요청마다 랜덤 한 토큰을 생성하여 검증하는 방식
- 공격자는 피해자의 브라우저를 통해 요청을 보낼 수는 있어도, CSRF 토큰 값을 알지 못함
- 서버는 요청을 처리하기 전에 CSRF 토큰이 세션의 값과 일치하는지 검증하는 과정에서 막히게 됨
2. SameSite 쿠키 설정 (SameSite Cookie Attribute)
- SameSite 속성에 따라 다른 사이트에서의 요청에 자동으로 전송되지 않도록 설정 가능
- Strict, Lax 모드를 사용 시, CSRF에 방어 가능
3. Referrer 검증 (Referer Header Validation)
- Referrer 헤더는 현재 요청이 어디에서 왔는지를 나타내는 HTTP 헤더
- 이를 이용해 요청이 신뢰할 수 있는 사이트에서 온 것인지 확인할 수 있음
- 즉, 요청이 공식 웹사이트에서 발생한 것이 아닐 경우 CSRF 공격으로 간주하고 거부
