CSRF(cross site request forgery)

CSRF란?

 CSRF(Cross site request forgery, 사이트간 요청 위조)란 웹 사이트의 취약점을 이용하여 사용자가 의도하지 않는 요청을 송신하도록 하는 공격의 의미합니다. 이는 http프로토콜의 상태없음(stateless) 특성에 기인한 특정 웹 어플리케이션에 대한 일련의 요청들의 상관관계를 특정할 수 없기 때문에 세션 유지등에 일반적으로 사용되는 쿠키 정보 등이 조건만 만족한다면 자동적으로 송신되기 때문에 가능합니다. 여기서 상관관계를 특정할 수 없다는 의미는 예를 들어 카트화면 -> 주문정보 입력 -> 주문완료로 이어지는 주문 프로세스를 가진 웹 어플리케이션에서 각각의 페이지에대한 요청이 연속적으로 이어지는지에 대한 제어를 할 수 없다는 것을 의미합니다. 이 공격수법은 결과적으로 피해자가 의도한 요청과 동일한 과정으로 진행되므로 공격자에 대한 추적이 어려울 수 있으며 피해자에게 인가된 범위안에서만 공격이 이루어진다는 특징이 있습니다.(피해자가 특정 웹 어플리케이션의 관리자 계정으로 인증&인가된 상태라면 피해범위가 커질 수 있습니다.)

대략적인 공격 시나리오

1. 공격자가 공격코드를 가진 웹페이지를 제작하여 공개하거나 특정 웹 사이트에 공격용 코드를 삽입
2. 피해자가 공격자가 준비해둔 페이지에 접속
3. 피해자(피해자의 브라우저)는 공격자가 준비해둔 요청을 서버로 송신

공격방법

 CSRF공격방법에는 정형화된 수법이 있다기 보다는 웹에 요청을 보낼수 있는 모든 방법이 공격방법이 된다고 할 수 있다. javascript와 ajax를 이용한 방법, 전통적인 form방법, img태그를 이용한 방법 등등 요청을 보낼수 있는 방법이라면 그 어떤 것이라도 가능하다.

대책

 일반적으로 가장 널리 이용되는 방법에는 Synchronizer token pattern(동기화된 토큰 패턴)이 있다. 이 패턴은 서버 사이드(세션 스코프 등)에 보관된 토큰을 CSRF방어가 필요한 요청마다 포함(요청할 form에 hidden필드를 이용하여 토큰을 추가)시켜서 요청하고 서버에서 비교하는 방식으로 CSRF를 방어하는 방법이다. 가장 간단한 방식으로 사용자 경험에 영향을 주지 않는 방식으로 방어할 수 있으므로 널리 사용된다. 이 경우 토큰은 세션ID와 동일한 수준의 보호 수단이 필요하다.(SSL이용, URL노출 금지, 출력대상 페이지 캐시 컨트롤, xss취약점 방어 등등) 토큰의 유출이 염려스러운 경우 토큰 갱신 혹은 세션 파기 등등 즉각적인 조치가 필요하다.

 이외에 제한적인 환경에서 이용가능한 방법으로 Referer Header 참조하여 사이트 외부에서의 요청을 배제하는 방법등이 있겠다. 물론 Header영역의 데이터는 기본적으로 조작가능한 데이터 이기는 하지만 일반적인 브라우징 환경에서는 조작하기 힘들기 때문에(불가능하다는 의미는 아님) 폐쇄적인 환경등에서는 유효한 해결책이 될수도 있다. 물론 위와같은 방법으로는 사이트 내부에서의 공격에 취약하다. 게다가 http/https이동간, 최근의 브라우저등에 탑재된 private browsing 옵션에 의해서 Referer헤더가 송신 안되는 제약이 있으므로 제한적으로 이용해야 할 듯하다.

 가장 강력한 대책으로는 CAPCHA라든이 재인증등의 방법이 있겠지만 사용자 경험에 영향을 미치므로 신중하게 생각해서 도입해야 할 듯 하다.

참조

Open Web Application Security Project (OWASP). Cross-Site Request Forgery (CSRF).https://www.owasp.org/index.php/CSRF

※본 포스트의 내용은 해킹을 조장하기위해 쓰여진 글이 아닙니다. 위의 내용을 악용할 경우 처벌받을 수도 있으므로 내용을 이해하고 방어할 목적으로만 이용하시길 당부합니다.