[normaltic 취업반 5기] 2024-01-17 12주차 내용 정리(+13주차 내용 추가)

 

CSRF(Cross Site Request Forgery)

 

  CSRF란 사이트 간 요청 위조란 뜻을 가지고 있으며 웹 어플리케이션 취약점 중 하나로 피해자의 의도와는 달리 서버에 공격자가 원하는 임의의 요청(데이터 수정, 삭제, 등록 등)을 하게 만드는 공격이다. 예를 들어 CSRF 공격으로 피해자의 계정 비밀번호를 변경시키거나 자금을 송금시키는 등의 동작을 수행하게 만들 수 있다.

 

 

CSRF vs XSS

 

  CSRF 취약점에 대해서 설명할 때 항상 등장하는 취약점이 바로 XSS 취약점이다. 두 취약점은 결이 비슷하며 연계하여 공격을 수행할 시 효과가 극대화될 정도로 시너지가 좋다. 그렇다면 CSRF 취약점은 XSS 취약점이 존재하지 않으면 공격이 불가능한가? 아니다, CSRF 취약점은 XSS 취약점이 존재하지 않아도 단독적인 공격이 가능하다. 다만, 단독적인 공격의 성공률은 현저히 낮기에 XSS 취약점과 연계하여 공격하는 것이 좋다.

 

  CSRF와 XSS 취약점의 다른점은 다음과 같다.

 

1) 정의

 

• CSRF : 피해자의 의도와 상관없이 서버에 임의의 요청을 하게 만드는 공격
• XSS : 피해자의 웹 브라우저에서 스크립트가 작동하게 만드는 공격

 

2) 공격 대상

 

• CSRF : 서버 측 공격 (근본적인 공격 대상은 클라이언트)
• XSS : 클라이언트 측 공격

 

3) 공격 수행 장소

 

• CSRF : 웹 서버
• XSS : 피해자 웹 브라우저

 

 

CSRF 취약점 공격과 대응 방안의 발전 과정

 

  CSRF 취약점을 이용한 공격과 대응 방안이 발전하는 과정에 대해서 사고의 흐름에 따라 설명한다.

 

 

1) CSRF 취약점을 이용한 단독 공격 상황(with GET Method)

 

  CSRF 취약점은 주로 중요한 정보의 수정, 삭제, 등록 등에 대한 요청이 가능한 웹 페이지에서 발견된다. 예로 사용자 계정의 비밀번호를 변경할 수 있는 웹 페이지를 들 수 있다. 또한 해당 웹 페이지가 GET 메서드로 파라미터를 전달 가능하다면 CSRF 취약점만을 이용한 단독적인 공격이 가능한 상황이 만들어지며 이는 다음과 같은 확인 과정을 거치게 된다.

 

1. 중요한 정보의 수정, 삭제, 등록 등에 대한 요청이 가능한 웹 페이지를 확인한다.
2. 공격자가 원하는 요청을 직접 작성할 수 있는지를 확인한다.
3. 작성한 요청이 GET 메서드로 전달한 경우 성공적으로 응답하는지 확인한다.

 

  위 확인 과정들이 성공적으로 완료된 경우에는 공격자는 임의의 요청을 URL 형태로 작성하여 피해자에게 노출시켜 클릭하도록 유도하는 방식의 공격이 가능하다.

 

 

2) POST 메서드로 전달하는 웹 페이지에서의 CSRF 취약점 공격(with XSS)

 

  1)의 내용에 따르면 데이터를 전달하는 방식이 GET 메서드일 경우 CSRF 공격이 가능하다는 것을 알 수 있다. 그렇다면 이에 대한 대응 방안으로 POST 메서드로만 데이터를 전달하도록 하면 CSRF 공격을 방지할 수 있는가? 이에 대한 물음으로 알 수 있는 것은 CSRF의 단독적인 공격은 방지할 수 있다는 것이다. 그러나 여기에 XSS 취약점이 연계된다면 이는 임시방편일 뿐인 대응 방안으로 전락한다.

 

<iframe sandbox id = "stealthframe" width="0" height="0" border="0" style="display:none;" name="stealthframe"></iframe>
 
<form method="POST" name="csrf_form" action="../mypage_update.php" target="stealthframe" id="myForm">
    <input type="hidden" name="pw" value="1234">
</form>
 
<script>
    fuction exploit() {
        var ch_pass = '1234';
        var formTag = document.getElementById('myForm')
        
        formTag.submit();
    }
</script>

 

  POST 메서드로 전달하는 웹 페이지에서의 CSRF 취약점 공격은 XSS 취약점과 연계하여 수행이 가능하다. 이는 form 태그를 스크립트에 삽입하여 데이터를 전달하게 만들면 되기 때문이다. 결국에는 POST 메서드와 GET 메서드는 데이터를 전달하는 방식에만 차이가 있을 뿐 전달하는 데이터의 내용에는 차이가 없기 때문에 상황에 맞춰 데이터를 전달하기만 한다면 CSRF 공격이 가능하다. 위 코드는 해당 공격의 예시 코드이다.  

 

 

3) CSRF Token이 적용된 웹 페이지에서의 CSRF 취약점 공격(with Iframe tag)

 

  2)의 내용에 따르면 GET 메서드와 POST 메서드는 데이터를 전달하는 방식에만 차이가 있지 전달하는 데이터의 내용은 차이가 없기 때문에 XSS 취약점과 연계하여 공격이 가능하다는 것을 알 수 있다. 그렇다면 이에 대한 대응 방안으로 전달하는 데이터의 내용에 변화가 있다면 CSRF 공격을 방지할 수 있는가? 이에 대한 물음의 답으로 대표적인 예가 바로 CSRF Token이다.

 

  CSRF Token은 서버로 들어온 요청이 정상적인 경로로 들어온 요청이 맞는지 확인하기 위해 사용하는 방법이다. CSRF Token은 서버로 요청하는 웹 페이지에서 랜덤으로 생성된 Token을 발행 후 사용자 세션에 저장한다. 그리고 사용자가 서버에 요청할 때 웹 페이지에 숨겨진 Token 값을 같이 서버로 전송한다. 이때 서버에서는 사용자 세션에 저장된 Token 값과 같이 전송되는 Token 값이 일치하는지 확인하여 해당 요청이 위조된게 아니라는 것을 확인한다. 일치 여부가 끝나면 사용된 Token은 폐기되고 새로운 웹 페이지를 요청할 때마다 Token을 새로 발행한다.

 

<iframe id = "getCSRFToken" src="../mypage.php" width="0" height="0" border="0" style="display:none;" onload="exploit()"></iframe>
<iframe sandbox id = "stealthframe" width="0" height="0" border="0" style="display:none;" name="stealthframe"></iframe>
 
<form method="POST" name="csrf_form" action="../mypage_update.php" target="stealthframe" id="myForm">
    <input type="hidden" name="pw" value="1234">
    <input type="hidden" name="csrf_token" value="" id="token_input">
</form>
 
<script>
    fuction exploit() {
        var token = document.getElementById("getCSRFToken").contentDocument.forms[0].csrf_token.value;
        var ch_pass = '1234';
        
        var formTag = document.getElementById('myForm')
        document.getElementById('token_input').value = token;
        
        formTag.submit();
    }
</script>

 

  그러나 이러한 대응 방법에 대한 파훼법도 존재한다. 바로 CSRF Token 자체를 탈취하여 요청 시 포함하면 위조 확인 여부 과정을 넘길 수 있다. CSRF Token을 탈취하는 방법으로는 대표적으로 iframe을 이용하는 방법이 존재한다. iframe 태그로 요청 웹 페이지를 가져와 Javascript로 Token을 가져온다. 이후 form 태그로 서버에 전달하면 CSRF 공격이 가능하다. 위 코드는 해당 공격의 예시 코드이다.

 

 

4) CSRF 취약점의 근본적인 문제

 

  1), 2), 3)의 내용에 따르면 CSRF 공격에 대한 대응 방안을 구성해도 파훼가 되는 것을 알 수 있다. 이는 CSRF 취약점의 근본적인 문제를 해결하지 않았기에 발생한다. 근본적인 문제란 바로 서버로 요청 시 요청 당사자가 사용자인지를 인증 정보를 통해 확인하는 것이다. 요즈음에는 웹 사이트 계정의 비밀번호를 변경할 때 사용자의 현재 비밀번호를 같이 입력하게 구성하여 요청 당사자가 사용자 본인인지를 인증 정보를 통해 확인 가능하다. 이로 인해 공격자는 사용자 계정의 비밀번호를 모른다면 CSRF 공격을 가할 수 없게 된다.

 

쿠팡 웹 사이트의 회원 정보 웹 페이지

 

 

CSRF 취약점 대응 방안

 

 

1) CSRF Token

 

  CSRF Token은 CSRF 취약점의 대표적인 대응 방안 중 하나로 이에 대한 설명은 위에서 했기에 생략한다.

 

 

2) Referrer 검증

 

  CSRF Token과 마찬가지로 CSRF 취약점의 대표적인 대응 방안 중 하나로 해당 방안을 적용하면 대부분의 CSRF 공격은 방어 가능하다. Referrer 검증이란 서버로 요청이 들어온 경로가 미리 설정한 웹 페이지가 아닌 경우 해당 요청을 처리해주지 않는 것이다. 요청 헤더(Request Header) 정보에서 Referrer 헤더를 확인할 수 있다.