CSRF 공격

[ CSRF 공격이란 ]

CSRF는 Cross Site Request Forgery의 약자로 사이트 간 요청위조라는 의미이다.

이 공격은 주로 피싱을 활용해 사용자 모르게 사이트의 어떤 기능을 실행하는 것이며 주로 패스워드를 변경하는데 사용한다.  CSRF 공격은 옥션 해킹 사건에서 사용된 공격 기법 중 하나이다.

사용자가 사이트에 로그인되어 있는 동안 해커가 이메일을 보내어 어떤 링크를 클릭하도록 피싱을 한다. 이 이미지에서 해커는 은행직원인 것처럼 가정하여 메일을 전송했다. 만약 사용자가 이 링크를 클릭하게 되면 클릭한 시점에 이미 로그인 되어있는 사이트의 패스워드를 해커가 지정한 패스워드로 변경하는 요청이 자동으로 전송되어 자신도 모르는 사이에 패스워드가 변경된다.

 

이처럼 CSRF는 피싱만 잘하면 난이도는 쉬운 공격에 속한다. 다만, CSRF의 필수 조건은 사용자가 피싱에 당하여 링크를 누르는 시점에 사이트에 로그인이 되어있어야 한다는 것이다. 최근, 웹 서핑의 경우를 생각해보면 탭을 여러개 열어서 사용하는 경우가 많으므로 이때, 여러 사이트가 한번에 CSRF 공격에 당할 수 있다.

 

[ CSRF 공격 실습 ]

 

로우 단계)

CSRF 실습과정을 자세히 보기 위해 버프스위트 Proxy의 HTTP History를 살펴보자 dvwa에서 패스워드를 입력하는 부분에 모두 normal을 입력해보고 history를 확인해볼 수 있었다.

 

다른 웹사이트에서 로그인 되어있는 상태가 유지되었을 경우 패스워드가 변경될 수 있는 상황이다. 이것이 CSRF가 성공하기 위한 조건이다. 만약 로그인이 되어있지 않는다면 적절한 쿠키가 보내지지 않아 공격에 실패한다.

 

강사님이 CSRF 공격 실습 예제를 만드시고 깃허브 주소를 올려주셨는데 내 리눅스에서는 사이트에 들어가지지 않아서 이번 실습 화면도 강사님 화면을 참고하여 진행하였다.

csrf.html 의 내용을 간단히 살펴보자. 자바스크립트의 에이젝스 기법을 이용해서 proxy history에서 본 것과 같이 url과 파라미터들을 똑같이 구성한다. 단, 패스워드 파라미터 값 두개는 normal 대신에 hacker로 설정되어 있다. 이 부분을 바꾸면 공격을 성공했을 때의 패스워드가 된다. 

 

일반적으로 CSRF 공격 시연 시, html 폼을 이용하는데 html 폼을 이용하면 공격 성공 이후 패스워드 변경 페이지로 전달되기 때문에 사용자가 무슨 일이 일어나는 지 알 수 있다.

 

다음으로 간단히 피싱을 위한 이메일을 하나 만든다. 수신자는 꼭 실습을 하는 자신의 메일 주소로 입력하고 간단히 메일 내용을 작성한다. '여기'라고 쓰인 부분에 csrf.html에서 복사해준 주소를 넣는다.

 

dvwa 서비스를 사용하다가 피싱 메일을 확인했다고 가정해보자. 메일에서 링크가 삽입된 여기 부분을 누르면 해커가 자기 사이트에 심어둔 페이지로 리다이렉트 되었다. 이 링크는 실습을 위한 예제이기 때문에 다시 링크를 누르도록 되어있지만, 실제 해킹을 당할때에는 페이지를 여는 순간 공격이 바로 실행될 수 있다.

 

다시 링크를 누른 경우, Done이라는 메시지와 함께 창이 하나 나타났다. 일반인들의 입장에서는 그냥 단순히 보안이 강화되었다고 생각할 것이다.

 

이 시점에서 CSRF 공격으로 인해 패스워드가 hacker로 변경되었다. DVWA에서 로그아웃 후 다시 로그인을 시도해봤을 때, 원래 패스워드였던 normal을 사용하면 로그인이 실패하였고, 패스워드를 hacker로 입력한 경우 로그인에 성공한 것을 확인할 수 있었다.

 

어떻게 진행된 것인지 자세히 살펴보기 위해 csrf.html에서 링크를 누르고 HTTP History를 살펴보자 버프스위트의 compare 기능을 이용하여 이전에 하이라이트 해두었던 요청과 비교해보았다. 

 

오른쪽에 있는것이 정상적인 요청이고, 왼쪽이 CSRF 공격을 받은 이후의 요청이다. 비교해보았을 때, 쿠키가 동일하기 때문에 웹사이트는 정상적인 페이지로 인식한다.

 

달라진 부분은 hacker 부분과 Referer, origin이라고 하는 헤더 부분이다. referer 부분을 보면 정상적인 요청일때는 localhost로 되어있지만 csrf 공격에서는 이메일에 작성했던 사이트의 주소가 들어가있는 것을 볼 수 있었다.

 

미디엄 단계)

로우 단계에서 진행한 실습을 단계를 미디엄으로 바꾸는 것을 제외하고 동일하게 설정한다.

HTTP History의 Response 부분 중 Render를 살펴보면 미디엄 단계에서는 요청이 이루어지지 않음을 알 수 있다.

 

소스코드를 살펴보면 REFERER 헤더를 검사하는 부분인 HTTP_REFERER가 있다. Referer 헤더는 어떤 요청이 전송될 때, 이전에 어떤 경로로부터 요청되었는지를 알려주기 위해 웹 브라우저가 자동으로 설정하는 헤더이다. 해커가 자기 사이트를 이용해서 CSRF 공격을 하게 되면, 해커 사이트 주소가 REFERER에 설정 된다.

 

개발자 입장에서는 Referer 주소가 서버 주소와 동일한지 비교함으로써 사용자가 정상적인 경로를 통해 요창한 것인지 알 수 있다. 만약, 이 값이 틀리다면 차단함으로써 CSRF 공격을 어느정도 대응할 수 있다.

 

미디엄 단계의 문제점을 확인하기 위해 소스코드를 확인해보자. 이때, 앞에 문자열이 뒤에 문자열에 포함되어 있는지를 검사하는 함수인 eregi 함수를 사용하는 것을 발견하였다. 이 경우에 서버 주소가 Referer 헤더 내에 포함되어 있는지를 검사하는 것이 루틴이다. 단순히 서버 주소가 포함되기만 한다면 우회될 수 있기 때문에 공격 파일 이름에 서버 주소를 넣어보았다.

 

공격자가 csrf_local.html을 통해 공격하면 링크를 클릭한 후, 버프스위트의 Request 부분을 확인하였을 때 csrf_local.html이 referer 헤더에 설정된 것을 볼 수 있었다. localhost 라는 웹 서버 주소가 referer 헤더에 포함되게 된다. 이러한 경우, 검사루틴을 무용지물로 만들 수 있다.

 

Response 테이블에 Render 부분을 보면 비밀번호가 변경되었다고 나온것을 확인할 수 있다.

이후 바뀐 비밀번호인 hacker로 로그인이 성공하는 모습을 볼 수 있었다.

 

따라서 referer 헤더를 비교할 경우에, 처음부터 꼼꼼히 referer에 있는 주소 부분이 서버 주소가 맞는지 확인해주어야 한다. 단순히 referer 주소에 서버 주소가 포함되었다는 식으로 검사를 할 경우에는 쉽게 우회할 수 있게 된다.

 

[ CSRF 공격대응 ]

우선 impossible 단계를 살펴보자. impossible 단계로 변경 후, csrf에 접속하니 현재 패스워드를 확인 차 한번 더 추가 입력을 요구하는 부분이 있다. 이렇게 되면 해커가 기존의 패스워드를 알고있지 않는 한, csrf 공격이 불가능하다.

 

CSRF 공격대응 방법 중 가장 좋은 것은 패스워드 변경과 같은 중요한 정보는 한번더 비밀번호를 확인하거나, CAPTCHA 같은 것을 이용하여 사용자가 직접 요청을 수행하는지 검사하는 방법이다. 또한 관리자 기능과 같은 해커에게 악용될 수 있는 기능의 경우 csrf에 대한 대비책이 마련되어야 한다.

 

다만 관리자가 기능을 수행할 때마다 일일히 비밀번호를 입력한다면 너무 귀찮아지기 때문에 이 경우, referer 헤더나 csrf 토큰을 이용해서 대응하는 것이 좋다. 반드시 주의할 점은 크로스 사이트 스크립팅 공격에 취약한 점이 있다면, 이러한 csrf 공격 대응 방법 역시 무용지물이 될 수 있기 때문에 XSS 공격에도 철저히 방어해야 한다.

 

 

[참고자료] 인프런_화이트해커가 되기 위한 8가지 웹 해킹 기술