➰ CSRF?(Cross Site Request Forger)
CSRF는 사이트 간 요청 위조의 줄임말로, 공격자가 타 이용자의 권한을 도용하여 특정 웹 사이트의 기능을 실행하게 할 수 있다.
🌱CSRF 성공하기 위한 조건?
- 사용자는 보안이 취약한 서버로부터 이미 로그인되어 있는 상태
- 쿠키 기반의 서버 세션 정보를 획득할 수 있어야 함
두가지 조건이 모두 충족해서 CSRF 공격이 성공할 수 있다.
➿ CSRF 공격 시나리오
-
사용자는 보안이 취약한 A 웹사이트에 로그인하여 인증 쿠키를 브라우저에 저장한다.
-
공격자는 자신의 웹사이트 (예: attacker.com)를 만들고, 이 웹사이트에 CSRF 공격을 위한 악성 스크립트나 HTML 폼을 삽입한다.
-
사용자가 악성 요청을 자동으로 전송하는 스크립트가 포함되어 있는 공격자의 웹사이트를 방문한다.
-
악성 요청 전송
사용자가 악성 스크립트가 작성된 페이지 접근시 웹 브라우저에 의해 쿠키에 저장된 session ID와 함께 서버로 요청된다. -
서버는 요청을 수신하고, 요청에 포함된 쿠키를 사용하여 사용자가 인증된 요청으로 처리한다.
⚠️이때 서버는 쿠키에 담긴 session ID를 통해 해당 요청이 인증된 사용자로부터 온 것으로 판단하고 처리한다. 그리고 사용자는 공격자의 웹사이트에서 의도하지 않은 작업이 실행되는 것을 알지 못한다.
❓ 의도하지 않은 작업?
- 은행 계좌 이체
- 비밀번호 변경
- 계정 설정 정보 변경
- 회원정보 수정
위와 같은 작업들이 나도 모르게 실행된다면 정말 위험하다.
➰ 취약점 내용
o 공격자가 업로드 한 악의적 행위 구문으로 인해 타 이용자의 권한 도용이 가능한지에 대해 점검한다.
- 타 이용자의 권한으로 실행하고자 하는 구문을 업로드 후 해당 이용자 권한으로 구문이 실행되는지 가능 여부 점검
※ 일반적으로는 스크립트 구문이 많이 사용되나, 다른 방식 사용 가능
➰ 점검기준
🌱 양호
사용자의 입력 값에 대한 검증 및 필터링이 이루어지는 경우
💊 취약
사용자의 입력 값에 대한 검증 및 필터링이 이루어지지 않아 스크립트 실행이 가능한 경우
➰ 점검 절차
- 사용자가 웹 사이트에 로그인을 한다.
- 로그인 후, 웹 브라우저에 인증 쿠키(PHPSESSID)가 저장된다.
- 사용자가 로그인 상태에서 공격자가 보낸 피싱 이메일을 열고, 악성 링크를 클릭하도록 피싱한다.
- 기업의 경우 실제 담당자의 업무 범위에 해당하는 내용의 메일을 발신하여 피싱한다.
출처 : 보안 뉴스
- Burp로 실제로 비밀번호를 변경할 때, 요청 패킷을 가로채고 분석한다.
- 요청 메시지를 살펴보면, password_new, password_conf 파라미터에 새 비밀번호가 전달되며, change 파라미터는 고정된 값으로 change를 가지고 있다.
- 인증을 위해 PHPSESSID 쿠키만 랜덤한 값을 가지고 있고, 이 값이 매우 중요하다.
- 공격자는 사용자의 랜덤한 PHPSESSID 쿠키를 알거나 전달할 수 있으면 파라미터 값을 변조하여 패스워드를 변경할 수 있게 되므로 이를 참고하여 공격을 수행하는 html 코드를 작성한다.
<!DOCTYPE html>
<html>
<body>
<script>
var xhr = new XMLHttpRequest();
xhr.open("POST", "http://target-website.com/change-password", true);
xhr.withCredentials = true; // 쿠키를 함께 전송하기 위해 설정
// 폼 데이터 구성
var params = "password_new=hacker1234&password_conf=hacker1234&change=change";
// 요청 헤더 설정
xhr.setRequestHeader("Content-type", "application/x-www-form-urlencoded");
// 요청 전송
xhr.send(params);
</script>
</body>
</html>
- 이때, withCredentials 속성을 사용하여 인증 쿠키를 함께 전송한다.
- 사용자가 웹 사이트에 접속한 상태에서 http://localhost/csrf.html 에 접속하게 한다.
- 사용자가 링크를 클릭하면, 공격자가 지정한 패스워드로 변경하는 요청이 이전에 로그인되어 있는 웹 페이지로 자동으로 전송된다. 사용자는 이를 인지하지 못한 채 비밀번호가 변경된다.
- 공격자는 변경된 패스워드를 이용하여 사용자 계정으로 로그인할 수 있다.
-> 변경한 패스워드를 이용하여 admin 계정으로 로그인을 시도한 결과, 패스워드가 변경되어 로그인에 성공하였다.
➰ 대응 방안
- Referer 헤더를 검사하여 요청을 전송시킨 출처 페이지를 확인하고 정상 요청인지를 판별한다.
- Referer 헤더는 해당 요청을 링크하고 있던 이전 웹 페이지의 주소를 알려주는 헤더
- CSRF 토큰 사용
- 쿠키 외에 공격자가 추측할 수 없는 값이 요청 메시지의 파라미터 등에 포함되어 있다면, 공격자는 csrf 공격을 성공시키기 어려움
- 패스워드 변경과 같은 중요한 기능을 수행할 때, 기존의 패스워드를 다시 한 번 입력받도록 하여 사용자 본인이 직접 기능을 실행하는지 확인
1️⃣ CSRF 공격와 XSS 공격의 공통점
XSS와 CSRF 모두 공격자가 사용자의 권한을 빼앗아 악의적인 작업을 수행하다는 점과 사용자의 웹 브라우저를 이용하여 공격이 수행된다는 공통점이 있다.
그래서 결론적으로 말하면 XSS가 실행되면 스크립트 구문이 동작하기 때문에 CSRF도 당연히 실행된다.
CSRF는 XSS가 선행되어야 한다!
어찌보면 비슷한 취약점인데 다르게 취급하는 이유와 정확한 차이점이 무엇일까? 이 차이점을 구분하지 못한다면 스크립트 구문을 실행시킨다고 해도 현업에서 엉뚱한 취약점으로 분류하는 대참사가 발생할 수 있다. 제대로 이해하고 가자.
2️⃣ CSRF 공격와 XSS 공격의 차이점
-
공격 과정에서 피싱을 이용하는 특성만 같고, 피싱 이후 진행되는 과정이 완전히 다르다.
-
공격대상 : XSS – Client, CSRF – Server
-
악성 스크립트를 클라이언트에서 실행시키고, CSRF는 웹 서버로 유도해 서버에서 동작하게 한다.
-
XSS는 사용자가 방문한 웹 페이지에 몰래 설치된 스파이가 사용자의 정보를 훔치거나 잘못된 행동을 유도하는 것, CSRF는 사용자가 신뢰하는 웹사이트로부터 허락 없이 명령(예: 비밀번호 변경)을 받아 대신 실행하게 만드는 것이다.
➰ 참고
