앵하니의 더 나은 보안
CSRF 취약점과 대응방안 본문
CSRF 취약점이 XSS 취약점의 연장선이라 생각했던 과거를 반성하며 글을 작성한다.
CSRF 취약점의 시연을 보통 XSS 취약점과 연계하기 때문에 'CSRF는 XSS 취약점의 연장선이다.'라고 생각했다.
근데 XSS 취약점을 이용해서 CSRF가 가능하다는 것이지, XSS 취약점이 존재해야만 CSRF 취약점이 존재한다는 건 아니다.
CSRF (Cross Site Request Forgery)
CSRF는 victim이 해커의 스크립트 또는 링크한 URL에 노출된 경우, victim의 의사와는 무관하게 행위를 유발하는 공격을 뜻한다. 사소하게 해커 본인의 게시글 추천부터 타사용자의 게시글 등록 또는 패스워드 변경까지 시나리오로 다양하게 사용할 수 있다.
CSRF 발생 가능성
웹 진단을 수행하는 웹 서비스 A에서 XSS 취약점이 노출되지 않았다고 하더라도 CSRF는 존재할 수 있는 경우 두 가지가 있다.
하나는 XSS 취약점이 존재하는 다른 웹 서비스 B에서 A를 대상으로 CSRF를 수행하는 XSS 구문을 작성하는 것이다.
XSS가 존재하지 않는 웹 서버에서 다른 웹 서버의 XSS로 인해 CSRF가 발생하는 과정은 아래와 같다.
0. victim은 웹 서버 A에 로그인 돼 있는 상태로, 해당 서버의 로그인 세션을 가지고 있는 상태
1. 웹 서버 B에서 해커는 XSS 취약점 발견,
웹서버 A의 로그인 세션을 가지고 있는 임의의 사용자가 웹 서버 B의 악성 스크립트에 노출될 경우 해커가 의도한 행동을 수행하는 악성 스크립트 작성
2. victim은 웹 서버A의 로그인 세션을 가진 채 웹 서버 B의 XSS가 존재하는 페이지 접근
3. XSS에 노출된 victim은 자신의 의지와 무관하게 웹 서버 A의 로그인 세션으로 웹 서버 A에서 해커가 의도한 행동 수행
그리고 다른 하나는 웹서버 A의 취약점이 존재하는 페이지에 내용을 URL에 담아 URL 채로 victim에게 전달하는 것이다.
1. 해커가 웹 서버 A에서 GET메서드로 요청이 가능한 패스워드 변경 URL 확인
2. 불특정 다수 victim에게 노출
3. victim은 hacker가 전달한 패스워드 변경 URL로 접근, victim의 패스워드가 hack12!로 변경
위 두 가지 상황 때문에 웹 서버에 XSS 취약점이 존재하지 않더라도 CSRF 취약점을 확인해봐야 한다.
그리고 CSRF 취약점이 발생함에 따라 진단자가 가이드로 전달해주는 방안은 여러 가지가 있지만
보편적인 대응방안 세 가지를 소개한다.
대응방안
1. Referrer 검증
Referrer란 웹 사이트 접근 시 어떤 경로를 통해 접근했는지 알 수 있는 흔적 같은 것이다.
만약 네이버에서 카카오 검색으로 카카오 공식 홈페이지를 접근하게 될 경우 카카오 홈페이지에서의 referrer는
https://search.naver.com/search.naver?ie=UTF-8&query=카카오&sm=chr_hty가 된다.
이 referrer를 참조해 csrf를 대응할 수 있다.
게시글 등록, 패스워드 변경과 같은 프로세스 요청 시 서버사이드에서 클라이언트의 referrer 값을 참조해
해당 요청의 무결성, 유효성을 검증할 수 있다.
예로, 게시글 등록 시 test.com/write에서 요청을 해야 한다고 가정할 때
서버는 referrer 값으로 test.com/write가 수신되어야만 게시글 등록을 할 수 있도록 하고,
referrer값으로 뜬금없는 값(test.com/test123)이 수신될 경우
이상 요청이라 판단, 해당 Request를 드랍한다.
2. CSRF Token
사용자 세션에 임의의 토큰 값을 저장해 세션에 저장된 토큰 값과 사용자의 요청 패킷 내 토큰 값을 비교해
서로 일치하는지 검증한다.
구체적인 과정은 아래와 같다.
- 사용자가 로그인 시 서버는 세션을 생성하며 토큰 값도 함께 생성
- 사용자는 서버에서 만들어진 세션을 수신
- 중요 프로세스 마다 클라이언트에서 송신하는 csrf 토큰과 서버의 세션에 저장된 세션값을 비교해 유효성을 검증
3. 사용자 재인증
사용자 검증을 한번 더 진행한다.
서버에서 사용자에게 패스워드 인증이나 captcha 인증과 같은 사용자 재인증을 요구해 요청의 유효성을 확인한다.
모든 서비스에 대해 재인증을 요구하기엔 서비스 편의성이 떨어지기 때문에 회원정보 수정 정도에 재인증을 요구하는게 적절하다.
대응방안이라고 썼지만 사실 1번과 2번은 또 다시 우회가 가능하다.
구체적으로 어떻게 우회가 가능한지는 추후에 포스팅 하겠다.
'보안 기술 > WEB' 카테고리의 다른 글
| Session storage JWT token 탈취 시도 (0) | 2023.06.09 |
|---|---|
| JWT 검증 우회 +α (0) | 2023.06.09 |
| SSL strip과 HSTS (0) | 2022.08.12 |
| WEB Ahnlab Safe Transaction bypass (20) | 2022.08.12 |
| X-XSS-PROTECTION bypass(X-XSS-Nightmare, XXN) (0) | 2022.07.18 |
