CSRF(Cross Site Request Forgery) 총정리

1. CSRF의 개념

사이트 간 요청 위조(CSRF)는 사용자가 모르는 사이에 사용자의 정보를 변경하는 것부터 사용자의 계정에 완전히 액세스하는 것까지 다양한 방식으로 악용될 수 있는 가장 심각한 취약성 중 하나이다.

현시대에 거의 모든 웹사이트는 사용자의 세션을 유지하기 위해 쿠키를 사용한다. 컴퓨터에 잘 몰라도 쿠키에 대해서는 들어봤을 정도로 유명하니 말 다한 셈이다. HTTP는 사실 "상태 없는" 프로토콜이기 때문에, 일련의 요청에 대해 사용자가 인증된 상태를 유지할 수 있는 내장된 방법이 없다고 할 수 있다. 매 작업마다 사용자에게 자격 증명을 묻는 것은 사용자 경험 측면에서 불편한, 정말이지 불편하기 짝이 없는 아이디어이기 때문에 쿠키가 사용되는 것이다. 쿠키는 이 목적을 위해 매우 효율적이고 충분한 암호화 강도를 가지고 있고 보안 채널을 통해 전송되면(HTTPS 사용) 일반적으로는 안전하다고 볼 수 있다.

하지만 문제는 브라우저가 요청이 있을 때마다 요청의 출처를 확인하지 않고 쿠키를 웹사이트에 제출한다는 것이다. 바로 여기서 CSRF가 나타나는 것이다.

공격자는 자신의 웹사이트에 진짜처럼 보이는 요청을 하는 일부 코드를 자신의 웹사이트에 배치한다. 브라우저는 요청에 따라 대상 웹사이트의 쿠키를 추가한다. 이렇게 하면 위조된 요청이 합법적인 요청이 될 수 있으며, 이 작업은 성공적으로 수행되는 것이다.

 

CSRF의 공격 표면은 대부분 이름, 이메일 주소, 웹 사이트 및 암호와 같은 피해자와 관련된 것을 변경하는 HTTP 요청이다. 인증 상태를 변경하는 데에도 사용되기도 한다. (로그인 CSRF, 로그아웃 CSRF 등) 심각도는 낮은 편이기야 하다만, 경우에 따라 문제가 될 수 있을 것이다.

 

2. CSRF의 활용(?)

선량한 웹사이트 arsenal.com과 공격자의 웹사이트 tottenham.com이 있다고 가정하자. 또한 피해자가 로그인되어 있고, 그의 세션이 쿠키에 의해 유지되고 있다고 가정해 보자. 공격자는 다음과 같이 행동하는 것이다.

① 피해자를 대신하여 그가 수행해야 할 작업이 무엇인지 확인하고 피해자의 엔드포인트를 찾는다. (예: target.com에서 암호를 변경하려면 매개 변수로 새 암호를 포함하는 웹 사이트에 POST 요청이 이루어진다.)

② target.com에 대한 법적 요청(예: 메서드를 게시물로 사용하고 새 암호를 포함하는 숨겨진 입력 필드)을 모방하는 HTML 코드를 그의 웹사이트 tottenham.com에 놓는다. 이때 "자동 제출"을 사용하거나 피해자가 제출 버튼을 클릭하도록 유도하여 양식을 제출해야 한다.

③ 피해자가 tottenham.com에 방문하고 그 양식이 제출되면 피해자의 브라우저는 target.com에 비밀번호 변경을 요청한다. 또한 브라우저는 쿠키에 요청을 추가한다. 서버는 이를 진정한 요청으로 취급하고, 피해자의 비밀번호를 공격자가 제공한 값으로 재설정하는 것이다. 이러한 방식으로 공격자가 피해자의 계정을 넘겨받는다.

 

3. CSRF의 예방

① 사용자 측면
사용자 측 예방은 브라우징 경험 측면에서 매우 비효율적이기는 하다. 한 번에 하나의 탭만 브라우징하고 "remember-me" 기능을 사용하지 않는 것으로 예방이 가능하다.

② 서버 측
서버 측에서 CSRF 보호를 구현하기 위해 제안된 여러 가지 방법이 있는데, 그 중 CSRF 토큰의 사용이 가장 일반적이다. CSRF 토큰은 사용자 세션에 연결되어 있지만 자동으로 제출되지 않는 문자열이다. 웹 사이트는 쿠키와 함께 유효한 CSRF 토큰을 받아야만 진행되는데, 공격자가 사용자 특정 토큰을 알 수 있는 방법이 없기 때문에 공격자가 사용자를 대신하여 작업을 수행할 수 없다.

 

그밖에 이전 패스워드 입력 받기, 전송되는 메시지는 GET 방식이 아닌 POST 방식으로 인증 등이 있겠다.