CSRF란?
CSRF(Cross-Site Request Forgery)는 one-click attack 또는 session riding이라고도 불리는 악성 웹 사이트 공격 유형이며, 어떤 웹 사이트가 신뢰하는 사용자로부터 승인되지 않은 요청을 보내는 공격입니다.
쉽게 말해, 실제 유저가 의도하지 않은 요청을 서버에 보내는 행위를 통한 공격을 말합니다.
유저는 A라는 작업을 수행하기 위해 버튼을 눌렀는데, 공격자가 심어놓은 자바스크립트(AJAX)에 의해 B라는 요청이 서버에 보내지는 것입니다. 따라서 유저는 자신도 모르게 서버를 공격하게 됩니다.
CSRF 공격 방식
CSRF 공격이 어떤 방식으로 일어나는지 살펴보겠습니다.
- 보안이 취약한 사이트에 사용자가 로그인합니다.
- 로그인 이후 서버에 세션 정보가 저장되고 브라우저 쿠키에
session_id가 저장됩니다.- 미리 공격 스크립트를 심어놓고 서버에 인증된 브라우저의 사용자를 악성 스크립트로 유도합니다.
- 사용자가 악성 스크립트를 실행 시 쿠키에 저장된 session_id가 브라우저에 의해 함께 서버로 요청되게 됩니다.
서버는 session_id를 보고 해당 악성 요청이 인증된 사용자로부터 온 것이라 판단 후 처리합니다.
간단한 예시를 보면 다음과 같습니다.
1. 사용자가 보안이 취약한 사이트 b.com에 로그인합니다.
2. 로그인 후 서버에는 사용자의 세션 정보가 저장되고 이를 사용할 수 있는 session_Id가 브라우저의 쿠키에 저장됩니다.
3. a.com에 클릭하면 "user1"이라는 글자를 "user2"라는 글자로 바꾸는 Button이 있습니다.
4. 공격자는 이 Button을 클릭하면, "a.com/user/delete" API를 호출하도록 하는 스크립트를 심어놓습니다.
5. 사용자가 이 Button을 클릭하면 공격자가 심어놓은 스크립트에 의해 user 삭제 요청 + session_id를 서버에 보내게 됩니다.
6. 서버는 session_id를 보고 인가된 사용자라 판단해 요청을 수행합니다.
CSRF 피해
CSRF는 주로 데이터의 값을 변경하는 요청을 대상으로 합니다. 다시 말해 서버의 상태를 변경하는 POST와 같은 요청이 됩니다. 예를 들어 제품을 구입하고 어떤 기록을 삭제하거나 변경하는 등의 요청이 CSRF의 대상입니다.
일반 사용자가 CSRF에 당한다면 개인 데이터 변경 또는 자금 전송등의 악위적 행위에 이용되고, 관리자 계정이 당한다면 공격자가 관리서버에 대한 접근 권한을 탈취해 서비스 전체를 통제하게 될 수 있습니다.
따라서 CSRF에 대한 대비를 하는 것이 중요합니다.
CSRF 방지
CSRF를 방지하기 위한 방법에는 여러가지가 있습니다.
- Referer 체크
- CAPTCHA 도입
- CSRF 토큰 사용
- CORS
- Same-Site Cookie
Referer 체크
클라이언트가 웹 요청을 하면 요청이 발생한 페이지의 URL을 Referer 헤더에 담아서 보냅니다. 외부 사이트에서 이 요청에 대해 CSRF 공격을 하면 Referer 헤더가 변경됩니다. 웹 서버에서는 Referer 헤더를 검사해서 지정된 페이지에서 온 요청이 아닌 경우 드랍시킵니다. 하지만 공격 스크립트가 서버에서 허용한 위치에서 실행되면 CSRF가 발생할 수 있는 문제점이 있습니다.
CAPCHA 도입
웹을 사용하면서 흔히 볼 수 있는 "신호등이 포함된 그림을 고르시오"등의 검증을 통해 봇에 의한 요청방지법입니다. 공격자가 요청 인자를 모두 파악하지 못하게 하는 효과가 있어 CSRF 보안에도 도움이 됩니다.
CSRF 토큰 검증
로그인 시 CSRF 토큰을 생성해 세션에 저장한다. CSRF 토큰을 페이지의 요청 태그에 넣어두고 요청마다 같이 전송합니다. 서버에서는 이를 검증해 CSRF 여부를 판단하는 방법입니다.
<input type="hidden" name="csrf-token" value="${CSRF_Token}"/>CORS (Cross-Origin Resource Sharing)
서버의 상태를 변경할 수 있는 요청이더라도, CORS 정책에 맞는다면 조건부 허용을 하는 것입니다. 이때 서버에서 브라우저로부터 어떤 요청을 받을 지 설정하고, 브라우저는 이를 통해 요청을 검증합니다.
- 허용된 Origin (예, https://www.example.com:443)
- 허용된 Method (예, GET, HEAD만 허용하고 POST는 제외하겠다)
- 허용된 Header - 자격증명 Header 허용
서버에서 검증을 하는 Referer 헤더와 달리, CORS는 브라우저에서 서버에서 보낸 내용을 토대로 검증을 한다는 차이가 있습니다.
SOP (Same-Origin Policy)
동일 출처 정책은 어떤 Origin에서 불러온 문서나 스크립트가 다른 Origin에서 가져온 리소스와 상호작용하는 것을 제한하는 보안 방식입니다. Origin이 다르다면 요청을 허용하지 않아 공격을 방지할 수 있습니다.
출처
- https://minjung-jeon.github.io/same-site-same-origin
- https://junhyunny.github.io/information/security/spring-boot/spring-security/cross-site-reqeust-forgery/
- https://www.ibm.com/docs/ko/sva/10.0.4?topic=configuration-prevention-cross-site-request-forgery-csrf-attacks
- https://nordvpn.com/ko/blog/csrf
