웹해킹 #6 크로스 사이트 요청 변조(CSRF) 공격

1. CSRF 공격 개요

- 공격자가 피싱을 이용하여 공격 대상이 되는 사용자에게 악성 링크를 누르게 하고, 링크를 클릭하면 사용자 모르게

  사용자가 로그인되어 있는 웹사이트의 어떤 기능을 실행하는 것

- 예 : 공격자가 사용자의 패스워드를 본인이 모르는 사이에 변경 후, 변경된 패스워드를 이용하여 웹사이트 접속

 

* CSRF 공격와 XSS 공격의 차이점

- 공격 과정에서 피싱을 이용하는 특성만 같고, 피싱 이후 진행되는 과정이 완전히 다름!

- 공격대상 : XSS – Client, CSRF – Server

- 악성 스크립트를 클라이언트에서 실행시키고, CSRF는 웹 서버로 유도해 서버에서 동작하게 함

 

<CSRF 공격 예시 - 사용자의 패스워드 변경>

CSRF 공격 예

① 사용자가 웹사이트에 정상적으로 접속하여 로그인

② 사용자가 웹사이트에 로그인되어 있는 동안, 공격자가 이메일을 보내 악성코드를 포함하고 있는 페이지를 여는 링크를 클릭하도록 유도

③ 사용자가 링크를 클릭 -> 공격자가 지정한 패스워드로 변경하는 요청이 자신이 이전에 로그인되어 있던 웹사이트로 자동으로 전송됨 -> 사용자가 모르는 사이에 자신의 패스워드가 변경됨

④ 공격자는 이제 변경된 패스워드를 이용하여 해당 사용자의 계정으로 로그인 가능

 

* 1번이 무조건 선행되어야 3번에서, 로그인 된 세션 정보가 쿠키 등으로 전달되어 웹사이트가 요청된 기능을

  실행할 수 있음!

 

2. CSRF 공격 실습

<DVWA(Low) - CSRF>

 

* proxy를 킨 상태로 진행하여 버프스위트를 통해 패스워드 변경 요청 메시지를 관찰한다!

 

- 비밀번호를 임의로 변경하여 버프스위트의 HTTP history 탭에서 패스워드 변경 요청 메시지를 확인

패스워드 변경 요청

- GET 메소드로 요청이 전송됨

- password_new, password_conf 파라미터 : 입력한 파라미터가 전달됨

- Chanage 파라미터 : Change 값이 전달됨

- 쿠키 헤더에는 PHPSESSID 쿠키와 다른 몇몇 보안 레벨과 관련된 쿠키가 전달됨

 

* 요청 메시지에서 PHPSESSID만 랜덤한 값을 가지고, 나머지 파라미터와 헤더 정보 등은 모두 지정된 값을 가짐

  -> 공격자가 사용자의 랜덤한 PHPSESSID 쿠키 값만 알아내거나 전달시킬 수 있으면, 위의 파라미터 값들을 포함한

      요청 메시지를 생성하여 패스워드를 변경할 수 있게 됨 (쿠키 전달을 위한 방법으로 CSRF 공격 사용!)

 

<사용자가 로그인 되어 있을 때>

- 웹 페이지를 요청할 때마다 쿠키가 웹 브라우저에 의해 자동으로 전달됨

- 공격자가 피싱 등의 기법을 이용하여 사용자가 로그인된 웹사이트의 링크를 누르게 만들면 쿠키를 전달시킬 수 있음

  -> 사용자가 로그인되어 있는 CSRF 공격의 필수 조건인 이유! (로그인되어 있지 않으면 쿠키가 전달되지 않음)

 

<csrf.html - DVWA 실습 페이지 대상으로 CSRF 공격 수행하는 HTML 파일>

csrf.html

- 위의 코드를 정리하면, 공격자가 피싱을 하여 사용자가 위 html 파일 안의 링크를 누르면, , 그 순간 패스워드를

  자동으로 변경하는 CSRF 공격 요청이 웹 애플리케이션으로 전달됨

- 사용자가 DVWA에 로그인되어 있는 경우 쿠키도 자동으로 포함되어 전송되기 때문에, 웹 애플리케이션은 사용자가

  로그인되어 있는 것으로 판단하고 요청을 처리 -> 패스워드가 변경됨!

 

① 위에서 언급했듯이 VI 등의 에디터를 이용하여 위의 var host를 부분을 DVWA의 IP 주소를 변경해야함!!!

② csrf.html 파일을 웹 디렉터리인 '/var/www/html/' 로 이동

③ 아파치 웹 서버를 실행하여 csrf.html을 웹으로 접근할 수 있도록 만든다.

④ 사용자가 피싱 당해 csrf.html 파일을 열게 되었다고 가정하고 새로운 탭에 아래 주소를 입력하여 csrf.html 파일 열기 

    http://localhost/csrf.html

⑤ Click!을 눌러 공격을 실행 후 버프스위트의 HTTP history를 본다

패스워드를 hacker로 변경하는 요청

- 패스워드를 hacker로 변경하는 요청과 PHPSESSID가 함께 전송되는 것 확인 가능

- 응답 코드(status 칼럼)이 200으로 표시되었따면 패스워드가 정상적으로 변경된 것!

 

3. CSRF 공격 대응

① 요청 메시지의 Referer 헤더(해당 요청을 링크하고 있던 이전 웹페이지의 주소를 알려주는 헤더)를 검사하여,

    웹 메일이나 타 사이트에서 피싱을 당해 전송되는 요청을 실행하지 않는다.

- 실습에서 요청의 Referer 헤더의 값이 http://localhost/csrf.html 이라고 되어있음

  (실습할 때 해당 경로의 파일로부터 링크를 클릭했기 때문에)

  그러나 정상적인 경로로 패스워드 변경요청이 되었다면 레퍼러 헤더에는 DVWA 사이트 내부의 URL이 표시되어야함

 

=> 따라서 레퍼러 헤더를 확인하여 요청을 전송시킨 출처 페이지를 확인하고 정상요청인지를 판별할 수 있음

 

② CSRF 토큰 사용

- CSRF 토큰 : CSRF 공격 대응을 위해 포함시키는 랜덤한 값

- 쿠키 외에 공격자가 추측할 수 없는 값이 요청 메시지의 파라미터 등에 포함되어 있다면,

  공격자는 csrf  공격을 성공시키기 어려워짐

 

- 먼저 웹 애플리케이션이 CSRF 토큰을 매 응답마다 랜덤하게 생성하여 히든 폼 필드를 통해 클라이언트로 보낸다

- 클라이언트는 이전 응답메시지에 포함된 토큰 값을 다음 요청 시 포함시켜 전송

- 웹 애플리케이션이 csrf 토큰 값을 검사 -> 정상적인 과정인지 확인 가능

 

ex) 

- 위와 같이 user_token의 value로 지정된 문자열이 웹 애플리케이션이 랜덤하게 생성한 CSRF 토큰 역할을 함

  -> 패스워드 변경 요청을 보내면 CSRF 토큰이 user_token 파라미터를 통해 전달됨