CSRF (Client Side Request Forgery) 란

정의

Client Side Request Forgery

피해자가 자신의 의도와는 다르게, 자신도 모르게 서버로 임의의 요청을 하게 만드는 공격

Server Side: 서버에서 실행되는 코드

Client Side: 클라이언트(웹 브라우져) 측에서 실행되는 코드

취약점 발생 지점 리스트

• 변경을 요청하는 모든 페이지
• 관리자 계정 등록
• 비밀번호, 이메일주소, 아이디 변경 등
• 이메일 주소 변경
• 웹 애플리케이션에서 세션을 사용하여 인증된 사용자를 식별하는 경우
• 웹 애플리케이션이 출처 확인 메커니즘을 제대로 구현하지 않은 경우

취약점 검증 방법

• 피라미터를 가진 get방식의 요청이 가능한지 확인, 이를 이용해서 비밀번호 변경이 가능한지 확인
• post방식을 get방식으로 변경해도 되는지 확인.

공격 순서

1. 웹싸이트에서 비밀번호변경과 같은 회원정보 수정처리를 어떤 방식으로 하는지 확인합니다.
2. 회원정보 수정을 http GET방식으로 가능한지 확인합니다.
3. burp suite의 리피터를 사용할 경우, 세션이 만료되서 확인이 안될수도 있습니다. 이럴떄는, 인터셉터 기능을 사용하거나, 링크로 만들어서 가능한지 테스트해볼수 있습니다.
4. GET방식으로 회원정보 요청이 허가된다는 뜻은 세션(CSRF 토큰)을 웹사이트에서 체크하지 않는다는 뜻입니다.
5. get방식으로 수정이 가능하다면, 사용자가 링크 혹은 게시글을 여는 순간 실행되어, 사용자가 모르는 사이에 비밀번호 변경이 가능하도록 유도가 가능합니다.
   1. Stored CSRF: 게시글에 악성코드를 심어넣어서 사용자가 게시글을 클릭하도록 유도합니다.
   2. Reflected CSRF: 이메일 같은곳에 악성 코드가 들어있는 링크를 보내서 클릭하도록 유도합니다.
   3. DOM based CSRF: 서버의 프래그먼트에 악성코드를 심어놓아서 사용자가 로그인하자마자 실행되도록 유도합니다.
6. GET방식이 불가능하다면 POST방식을 사용해야 합니다.즉, XSS와 연계하여, 사용자의 인증정보(=세션)을 탈취하고, 이를 이용해서 사용자의 비밀번호 변경이 가능합니다.

발생 과정

1. 사용자가 웹 애플리케이션에 인증 요청을 보냅니다.
2. 웹 애플리케이션은 인증 요청을 받고, 사용자에게 인증 응답을 보냅니다.
3. 사용자는 악성 요청을 웹 애플리케이션에 보내지만, 사용자는 악성 요청이 발생한 사실을 인지하지 못합니다.
4. 웹 애플리케이션은 악성 요청을 처리하고, 사용자에게 악성 요청 처리 결과를 반환합니다.

공격 예제

CSRF 공격기법 리스트

대응방법

CSRF(Cross-Site Request Forgery)에 대한 궁극적인 대응 방안은 CSRF 토큰을 사용하는 것입니다. CSRF 토큰은 웹 애플리케이션에서 사용자의 세션과 연결된 임의의 값을 포함하는 보안 토큰입니다. 이 토큰은 모든 중요한 요청에 추가되어 서버가 요청의 유효성을 검증할 수 있도록 합니다.

일반적으로 CSRF 토큰은 다음과 같은 방식으로 구현됩니다.

1. 서버는 사용자가 로그인할 때마다 고유한 CSRF 토큰을 생성합니다.
2. 서버는 이 CSRF 토큰을 쿠키 또는 세션에 저장하거나, 웹 페이지의 숨겨진 필드(hidden field)에 포함시킵니다.
3. 사용자의 브라우저는 서버로부터 받은 CSRF 토큰을 자동으로 요청에 포함시킵니다.
4. 서버는 모든 중요한 요청을 처리하기 전에, 요청에 포함된 CSRF 토큰과 세션에 저장된 토큰을 비교하여 유효성을 검증합니다