[Web] CSRF(Cross Site Request Forgery) 공격 기법

1. CSRF(Cross-site request forgery)

1.1 정의

 

사이트 간 요청 위조(또는 크로스 사이트 요청 위조, 영어: Cross-site request forgery, CSRF, XSRF)는 웹사이트 취약점 공격의 하나로, 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 특정 웹사이트에 요청하게 하는 공격을 말한다.

 

유명 경매 사이트인 옥션에서 발생한 개인정보 유출 사건에서 사용된 공격 방식 중 하나다.

 

사이트 간 스크립팅(XSS)을 이용한 공격이 사용자가 특정 웹사이트를 신용하는 점을 노린 것이라면, 사이트간 요청 위조는 특정 웹사이트가 사용자의 웹 브라우저를 신용하는 상태를 노린 것이다. 일단 사용자가 웹사이트에 로그인한 상태에서 사이트간 요청 위조 공격 코드가 삽입된 페이지를 열면, 공격 대상이 되는 웹사이트는 위조된 공격 명령이 믿을 수 있는 사용자로부터 발송된 것으로 판단하게 되어 공격에 노출된다.

 

1.2 위험성

 

CSRF(Cross-site request forgery)는 웹사이트 취약점 공격방법중 하나로, 사용자가 자신의 의지와는 상관없이 공격자가 의도한 수정, 삭제, 등록 행위 등 특정 웹사이트에 요청하게 하는 공격이다.

유명 경매 사이트인 옥션에서 발생한 개인정보 유출 사건에서 사용된 공격 방식 중 하나이기도 하며, 일단 사용자가 웹사이트에 로그인한 상태에서 사이트간 요청 위조 공격 코드가 삽입된 페이지를 열면 이후에는 사용자의 행동과 관계 없이 사용자의 웹 브라우저와 공격 대상 웹사이트 간의 상호작용이 이루어져 다양한 공격이 가능하게 된다. 따라서 해당 공격 가능성이 존재한다는 것은 위험한 상태로 신속한 보안조치가 필요한 상황이다.

 

1.3 공격법

CSRF(Cross-site request forgery) Script

 

1. 공격자는 게시판에 관리자가 관심을 가질 수 있는 제목으로 CSRF 스크립트가 포함된 게시물을 등록한다.

2. 관리자는 확인이 필요한 게시물로 파악하여, CSRF 스크립트가 포함된 게시물을 확인한다.

3. 게시물을 읽은 관리자는 CSRF 스크립트가 포함된 것을 알지 못한 채 게시물을 확인한다. 하지만, 관리자의 권한으로 공격자가 원하는 CSRF 스크립트 요청이 발생한다.

4. 공격자가 원하는 CSRF 스크립트 결과가 발생하여, 관리자 및 사용자의 피해가 발생한다.

 

1.4 방어법

서버에서 쿠키 이외의 다른 파라미터 값으로 추가 인증을 처리

중요 action을 처리할 때, 추가 인증 수단을 사용한다면 공격이 불가능하다.

 

XSS(Cross Site Script) 스크립트의 실행 방지

XSS 취약점이 존재하지 않더라도 스크립트를 실행시킬 수 있기 때문에 XSS만 막았다고 해서 CSRF를 막았다고는 할 수 없다.

 

값이 매번 바뀌는 one TIME 값 사용

인증 값을 알아내는 것이 힘들고, 사용자마다 매번 인증 값이 바뀐다. 쿠키가 아닌 다른 형태의 매번 바뀌는 인증 값을 사용한다.

 

 

IPS나 웹 방화벽을 사용

CSRF 스크립트는 정상적인 HTML 스크립트이기 때문에 보안 솔루션으로는 방어를 할 수 없고 중요 공격 로직을 파악하고 분석하여 안전한 웹 어플리케이션을 개발한다.

 

Referer 체크

Referer는 HTTP 헤더에 있는 정보로 해당 요청이 요청된 페이지의 정보를 가지고 있는데 해당 정보는 Paros나 Zap, fiddler같은 프로그램으로 조작이 가능하지만 방법이 간단하여 소규모 웹사이트에 주로 이용되는 방법이다.

 

GET/POST 구분

img 태그 등을 이용할 경우 GET 요청으로 들어오게 될 것이고, 반면 흔히 하듯 form을 이용해 값을 받을 경우 POST를 이용하게 되는 경우가 많기 때문이다.

2. 실습

2.1 CSRF(Cross-site request forgery) 공격

모의해킹 사이트에 접속합니다.

그리고 웹 사이트 url을 확인합니다.

글쓰기 페이지입니다.

url을 확인합니다.

그리고 제목과 내용을 입력하고

제목과 내용을 기억합니다.

게시글을 등록합니다.

Wireshark를 이용하여 글쓰기가 어떠한 방식으로 작성이 되었는지 스니핑을 합니다.

-> POST 방식으로 작성을 완료하고

GET 방식으로 게시판으로 다시 돌아왔습니다.

GET 방식으로 요청된 패킷을 확인합니다.

패킷 분석을 위하여 TCP Stream을 확인합니다.

Stream을 확인해보니

다음과 같이 쿠키 정보를 확인할 수 있습니다.

talkType를 확인하고 url에 포함되어 있는 내용을 확인합니다.

-> 해당 계정이 어떠한 파라미터로 넘어가는지 확인하여 사이트 간에 요청을 위조할 것입니다.

확인된 stream의 Host 정보와 talkType를 확인하여

오른쪽과 같이 게시글을 등록하는 jsp에 injection할 것입니다.

해당 정보를 다른 곳에 옮겨서 작성해둡니다.

-> 저의 경우는 vscode에 작성하였습니다.

코드를 보면 각 파라미터 변수에 다른 정보들을 할당한 것을 알 수 있습니다.

-> asdasd를 abc로 수정하였습니다.

이전에 게시글로 등록하였던 글을 확인하고

웹 사이트 url에 vscode로 옮겨 두었던 소스코드를 작성합니다.

스니핑을 통하여 알아낸 url에 injection을 성공하였습니다.

다음과 같이 악성 스크립트를 작성한 게시글을 등록합니다.

또한 이 코드를 이용하여 CSRF 스크립트를 게시글에 심을 것입니다.

이전에 vscode에 옮겨 두었던 소스코드를 악성스크립트에 다음과 같이 작성합니다.

그리고 다른 사용자가 이 게시글을 등록하면 이전과 똑같은 방식으로 게시글이 등록될 것입니다.

이번엔 fool로 등록되도록 파라미터 변수에 injection할 것입니다.

게시글을 등록합니다.

게시글이 등록된 것을 확인합니다.

새로운 계정을 생성하였습니다.

로그인합니다.

topgun5가 작성한 게시글을 클릭합니다.

topgun5의 게시글을 클릭했더니 topgun7이 fool이라는 게시글을 작성하게 되었습니다.

-> 사이트간 요청 위조를 하였기 때문에 내가 작성한 글이 아님에도 해커에 의해서

의도치 않은 글을 작성하게 됩니다.

게시글의 게시자, 제목, 내용을 확인해보니 topgun7이 쓴 게시글인 것처럼 요청이 위조가 되었습니다.

소스코드