CSRF (Cross-Site Request Forgery)

CSRF (Cross-Site Request Forgery)

- 피해자가 자신의 의지와는 무관하게 공격자가 의도한 행위를 애플리케이션에 요청하게 만드는 형태의 공격

- CSRF는 피해자의 권한을 도용하여 특정 행위를 수행하는 형태이기 때문에 피해자의 권한이 높을수록 할 수 있는 행위가 많아져 피해 규모가 커지는 특징이 존재

 

Step1. 관리자가 갤러리 페이지에 공지사항 작성.

그림(1) CSRF

 

Step2. 공격자가 갤러리 페이지에 공격 Payload 삽입하여 작성

그림(2) CSRF

 

Step3. 갤러리에 작성한 글을 관리자가 클릭 후 qna 에 새로운 글이 작성되는 것을 확인.

그림(3) CSRF

 

 

CSRF 공격과 전제 조건

- 피해자(사용자)는 보안이 취약한 (CSRF 공격이 가능한) 애플리케이션으로부터 이미 인증을 받은 상태여야한다.

- 인증을 받지 않은 사용자를 대상으로 공격을 진행할 경우 비인증 사용자가 접근 가능한 페이지 및 기능만 공격이 가능하다.

- 공격자는 공격 대상(애플리케이션)의 요청 방법에 대해 사전에 미리 알고 있어야한다.

- Path, Reqeust Method, Parameter 등

 

CSRF 공격 대응

referrer 검증

- 서버에서 Reqeust Header에 존재하는 referrer 값을 검증하는 방법

- 대부분의 CSRF 공격은 referrer 값 내에 Domain의 일치 여부만 검사해도 대응이 가능

- referrer 값에서 상세 페이지(Path)까지 검증을 실시하면 같은 도메인 내에 발생하는 CSRF 공격도 대응이 가능

 

CSRF Token 사용

- 사용자의 세션에 임의의 난수 값을 설정하고 요청이 발생할 때 마다 해당 난수 값을 포함시켜 전달

- 서버에서 요청을 받을 때 마다 세션에 저장된 CSRF 토큰 값과 요청 파라미터에 전달되는 토큰 값이 일치하는지 검증하는방법

 

Double Submit Cookie 검증

- Security Token 검증의 한 종류로 세션을 사용할 수 없는 환경에서 사용이 가능

- 웹 브라우저의 Same origin 정책으로 자바스크립트에서 다른 도메인의 쿠키 값을 조회하거나 수정하지 못하는 것을 이용하는 방법

- 요청 발생 시 난수 값을 생성하여 쿠키에 저장하고 동일한 값을 서버에 전달한 이후 서버에서 해당 값이 일치하는 지 여부를 확인하고 이후에 재사용이 불가능하도록 만료 처리하는 방법

 

 

결론

CSRF도 XSS처럼 웹 브라우저에서 사용한다. 취약한 서버를 실제로 구현하여 취약점 확인하여 포스팅을 해보았다.

주요정보통신기반시설 관련하여 전체적으로 설명할 수 있도록 포스팅도 한 번 해봐야할 것 같다. 시간이 꽤 오래 걸릴 것 같지만~