주의사항 : 이 포스팅은 개인 학습 및 교육적 목적으로 작성되었으며, 제공하는 정보를 악용하여 불법적인 행위를 하는 것은 엄격히 금지되어 있습니다. 웹 취약점 진단은 해당 웹사이트의 소유자의 명시적인 허가 없이는 수행해서는 안되며, 웹 취약점을 발견하였을 경우 즉시 해당 웹사이트의 소유자나 관리자에게 알려야 합니다.
CSRF
: Cross-site Request Forgery(사이트 간 요청 위조)로, 사용자가 자신의 의지와는 무관하게 공격자가 의도한 행위(수정, 삭제, 등록 등)를 사용자의 웹 브라우저를 통해 특정 웹사이트에 요청하게 하는 웹 취약점 공격이다.
사용자가 특정 서버에 로그인하면 일반적으로 다음과 같은 작업들이 수행된다.
- 서버는 로그인 시 인증된 사용자의 정보를 세션에 저장하고, 이를 찾을 수 있는 sessionID을 만든다.
- 서버는 저장된 세션 정보를 클라이언트(브라우저)가 사용할 수 있도록 sessionID를 Set-Cookie 헤더에 담아서 전달한다.
- 클라이언트(브라우저)는 전달된 sessionID를 쿠키에 저장한다.
- 클라이언트(브라우저)는 해당 도메인을 가진 서버로 요청 시 쿠키에 저장된 sessionID를 자동으로 전달한다.
- 서버는 쿠키에 담긴 sessionID를 통해 인증된 사용자인지 여부를 확인한다.
CSRF 전제 조건
- 사용자가 보안이 취약한 서버로부터 이미 인증을 받은(로그인 된) 상태여야 한다.
- 쿠키를 기반으로 서버 세션 정보를 획득할 수 있어야 한다.
- 공격자는 서버를 공격하기 위한 요청 방법에 대해 미리 파악하고 있어야 한다. 예상치 못한 파라미터가 있으면 불가능하다.
CSRF 공격 과정
- 사용자는 보안이 취약한 서버에 로그인한다.
- 로그인 이후 서버에 저장된 세션 정보를 사용할 수 있는 sessionID가 사용자 브라우저 쿠키에 저장된다.
- 공격자는 서버에 인증된 브라우저의 사용자가 악성 스크립트 페이지를 누르도록 유도한다.
3_1. 게시판에 악성 스크립트를 게시글로 작성하여 관리자 혹은 다른 사용자들이 게시글을 클릭하도록 유도한다.
3_2. 메일 등으로 악성 스크립트를 직접 전달하거나, 악성 스크립트가 적힌 페이지 링크를 전달한다.
- 사용자가 악성 스크립트가 작성된 페이지 접근시 쿠키에 저장된 sessionID는 브라우저에 의해 자동적으로 함께 서버로 요청된다.
- 서버는 쿠키에 담긴 sessionID를 통해 해당 요청이 인증된 사용자로부터 온 것으로 판단하고 처리한다.
점검 절차
- XSS는 CSRF 공격에 영향을 줄 수 있으므로, 웹 애플리케이션에 XSS취약점이 있는지 확인한다.
- 웹 애플리케이션에 등록 또는 변경과 같은 데이터 수정 기능이 있는지 확인한다.
- 데이터 수정 페이지에서 전송되는 요청 정보를 분석하여 임의의 명령을 수행하는 스크립트를 삽입한다. 이후 해당 게시글을 타 사용자가 열람했을 때 스크립트가 실행되는지 확인한다.
보안 대책
- 백엔드에서 요청의 referrer를 확인하여 현재 도메인과 일치하는지 검증한다. 같은 도메인 상에서 요청이 들어오지 않는다면 차단하도록 하는 것이 일반적이다.
- Referrer 검증이 불가능한 경우, 보안 토큰(CSRF Token)을 이용할 수 있다. 사용자의 세션에 임의 난수 값을 저장하고 요청 시 해당 토큰 값을 포함하여 전송한다. 서버에서 요청을 받을 때 세션에 저장된 토큰 값과 요청 파라미터에 전달되는 토큰 값이 일치하는지 검증한다.
- CAPTCHA를 사용하여 검증을 통해 이용할 수 있도록 지정한다.
- Double-Submit Cookie Pattern : 웹 브라우저의 Same Origin 정책을 이용하여 공격자가 쿠키값에 접근할 수 없도록 한다.
출처
https://junhyunny.github.io/information/security/spring-boot/spring-security/cross-site-reqeust-forgery/
https://m.blog.naver.com/PostView.naver?blogId=lstarrlodyl&logNo=221943397270&navType=by
https://it.jjanglab.com/309