크로스 사이트 리퀘스트 포저리
개요
CSRF(Cross-site request forgery)는 웹 어플리케이션 취약점 중 하나로 사용자가 자신의 의지와 무관하게 공격자가 의도한 행동을 하여 특정 웹페이지를 보안에 취약하게 한다거나 수정, 삭제 등의 작업을 하게 만드는 공격방법을 의미한다. 지난 2008년에 발생한 옥션#s-2의 개인정보 유출사건도 이 방법을 통한 관리자 계정 탈취 방법에도 사용된 기법이다. 공격의 난이도가 높지 않아 널리 사용되는 방법 중 하나이다.
크로스 사이트 리퀘스트 포저리 또는 사이트 간 요청 위조(또는 크로스 사이트 요청 위조, Cross-site request forgery, CSRF, XSRF)는 웹사이트 취약점 공격의 하나로, 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격을 말한다.
유명 경매 사이트인 옥션에서 발생한 개인정보 유출 사건에서 사용된 공격 방식 중 하나다.
사이트 간 스크립팅(XSS)을 이용한 공격이 사용자가 특정 웹사이트를 신용하는 점을 노린 것이라면, 사이트간 요청 위조는 특정 웹사이트가 사용자의 웹 브라우저를 신용하는 상태를 노린 것이다. 일단 사용자가 웹사이트에 로그인한 상태에서 사이트간 요청 위조 공격 코드가 삽입된 페이지를 열면, 공격 대상이 되는 웹사이트는 위조된 공격 명령이 믿을 수 있는 사용자로부터 발송된 것으로 판단하게 되어 공격에 노출된다.
공격 방법
이러한 공격을 하기 위하여 악의적 공격자는 우선 공격을 할 사이트를 먼저 분석한다. 예를 들어서, 나무위키의 경우에 토론은 namu.wiki/topic/ 이라고 시작하며, 뒤에 숫자가 붙는 형식인데 이 뒤에 숫자에 패턴이 있다. 그러면 이 패턴을 이용하여 일반적인 방법으로 접근할 수 없는 페이지를 오픈 한다든지, 개발에 사용되고 실제로 사용하지 않는 샘플 페이지를 찾아낸다든지 이러한 방법이 가능하다. 그것이 아니라 웹페이지가 독자적 개발이 아닌 외부에서 이미 개발된 웹 어플리케이션을 사서 조금 수정한 것이라면 공격자는 경우에 따라서 해당 웹 어플리케이션을 구매하여 개인 서버에 설치를 한다. 그 다음에 공격 가능 패턴을 분석한다. 주로 공격자들이 찾는 것은 사용자 패스워드 변경페이지나 타 시스템과 로그인 연동 주소 패턴같은 인증 관련된 취약점을 찾는다. 그 다음에 여기서 나온 취약점을 이용하여 공개된 게시판이나 메일을 이용하여 사용자가 해당 링크를 열게 만들면 공격이 완료된다.
공격 과정
- 이용자는 웹사이트에 로그인하여 정상적인 쿠키를 발급받는다
- 공격자는 다음과 같은 링크를 이메일이나 게시판 등의 경로를 통해 이용자에게 전달한다.
- https://www.geocities.com/attacker
- 공격용 HTML 페이지는 다음과 같은 이미지태그를 가진다.
- <source lang="html4strict"><img src= "https://travel.service.com/travel_update?.src=Korea&.dst=Hell"></source>
- 해당 링크는 클릭시 정상적인 경우 출발지와 도착지를 등록하기위한 링크이다. 위의 경우 도착지를 변조하였다.
- 이용자가 공격용 페이지를 열면, 브라우저는 이미지 파일을 받아오기 위해 공격용 URL을 연다.
- 이용자의 승인이나 인지 없이 출발지와 도착지가 등록됨으로써 공격이 완료된다. 해당 서비스 페이지는 등록 과정에 대해 단순히 쿠키를 통한 본인확인 밖에 하지 않으므로 공격자가 정상적인 이용자의 수정이 가능하게 된다.
예시
만일, A라는 사이트의 사용자 개인 비밀번호 변경을 하는 주소 패턴이 abc.com/user.do?cmd=user_passwd_change&user=admin&newPwd=1234 라고 한다면 이러한 링크를 사용자의 메일로 XSS 형태로 보내고 메일을 읽게되면 해당 사용자의 패스워드가 1234로 초기화 된다. 이를 관리자에게 보내서 일반계정을 관리자 계정으로 바꾸도록 한다든지, 아니면 관리자 계정 패스워드를 바꾸는데 이용한다면 해당 사이트의 모든 정보가 해킹당하는데는 오랜 시간이 걸리지 않는다. 참고로, img 태그도 GET 메소드를 사용해서 보내는 것이기 때문에 img를 이용할 수도 있다! 대부분의 사이트는 img를 필터링하지 않으므로, 혹은 필터링하지 못하므로 유용한(...) 방법이 될 수 있다. 예를 들면 나무위키의 경우 {{{<img src="https://namu.wiki/logout">}}} 와 같은 코드를 넣어주면 해당 문서를 볼 경우 로그아웃이 된다. 이는 나무위키뿐만이 아닌 대부분의 사이트의 문제.
방어 방법
방어 방법 중 가장 기초적인 방법은 Referer 체크를 하는 방법이 있다. Referer는 HTTP 헤더에 있는 정보로 해당 요청이 요청된 페이지의 정보를 가지고 있는데 해당 정보는 Paros나 Zap, fiddler같은 프로그램으로 조작이 가능하지만 방법이 간단하여 소규모 웹사이트에 주로 이용되는 방법이다. 그 외에는 패스워드 변경 같은 민감한 정보를 다룰 때에는 세션에 임의난수(토큰)를 발급하여, 해당 난수가 없는 상황에서 해당 동작들이 이루어지면 요청을 거부하는 방법을 통하여 사용자가 정말로 변경을 의도하는 경우에만 변경을 시켜주는 방법, 변경 시에 CAPTCHA를 이용하여 캡챠 인증코드가 없거나 틀리면 거부하도록 하는 방법 등이 이용되고 있다. 또한 GET/POST 등을 구분하여 주는 것 역시 유용하다. img 태그 등을 이용할 경우 GET 요청으로 들어오게 될 것이고, 반면 흔히 하듯 form을 이용해 값을 받을 경우 경우 POST를 이용하게 되는 경우가 많기 때문이다. 위의 방법들을 일일이 적용하기 귀찮다면, 대개 프레임워크에서 위의 방법들을 통합한 플러그인 등을 제공하는 경우들이 많으니 찾아보도록 하자.
바깥 고리
- https://www.virtualforge.de/vmovie/xsrf/xsrf_attacked.html
- gmail hijack : https://www.gnucitizen.org/blog/google-gmail-e-mail-hijack-technique/
- xsrf in adsl router : https://www.webappsec.org/projects/whid/byid_id_2008-05.shtml
- cracking simple anti-xsrf (in zeroboard 4.1 bbs)
- xsrf in web services (in zeroboard 4.1 bbs admin)
- https://x82.inetcop.org/h0me/papers/web2.0-csrf.pdf
Template:토막글/그림 | {{#if:보안 | 이 글은 {{#if:보안|보안에 관한}} 토막글입니다. 서로의 지식을 모아 알차게 문서를 완성해 갑시다.|이 토막글 틀의 변수는 잘못 사용되었습니다. 알맞은 변수를 토막글 모음에서 골라 사용해 주세요.}} | 이 글은 토막글입니다. 서로의 지식을 모아 알차게 문서를 완성해 갑시다.
}} |
{{#if:||Template:토막글/분류}} {{#ifexpr:7036>5000|분류:큰 토막글 문서}}