[기록일지] 📚 12주차 (CSRF)

CSRF

CSRF란 Cross Site Request Forgery의 약자로서 피해자(이용자)가 서버로 임의의(공격자가 원하는) 요청을 보내도록 만드는 공격을 말한다.

여기서 Request Forgery 는 요청을 위조 · 변조 한다는 것을 의미한다.

이용자의 입장에서 '나는 서버에 그런 요청을 한 적이 없지만, 나도 모르게 「서버로」 특정 요청을 하게 만드는 것'이다.

ex ) 공격 예시(비밀번호 변경, 게시판 글 작성)

1. 피해자가(자기도 모르게) 자기 계정의 비밀번호를 1234로 변경하는 요청을 서버에 보내게 만든다.
2. 피해자가(자기도 모르게) 게시판에 어떤 게시글을 작성하는 요청을 서버에게 보내게 만든다.

즉 피해자가 피해자의 의도와 무관하게 공격자가 원하는 요청을 하도록 만드는 것인데, 그렇다면 어떻게 하면 우리가 특정 요청을 하도록 유도할 수 있을까?

전화해서 최면이라도 걸어서 말을 듣게 하는 것일까?

📞 (지금부터 당신은 제 말대로 합니다.~)
비밀번호를 1234로 입력하고 변경하기를 누르세요.

비밀번호를 입력하고, 변경하기 버튼을 누르는 요청을 보내게 만드는 것이 핵심이다.

하지만 현실에서 누가 저런것에 당하겠는가... 

그래서 우리는 CSRF 공격을 이용하여 요청을 유도하되, 이용자가 인지하지 못하도록하는 것을 목적으로 한다.

CSRF 공격 Step

1. 확인할 요청에 인증 정보가 포함되는지 확인
2. 인증 정보가 없이 변경 요청이 가능하다면? CSRF 취약점!
3. CSRF URL 전달
공격 요청 주소/vuln/csrf/?params=
(URL Short 사용으로 요청 경로와 파라미터를 감추고 보낼 수 있다.)
위의 URL은 너무 티가 나서 누르기 꺼려진다는 것

---

XSS vs CSRF

그런데 여기서 잠깐. CSRF 공격이 이용자가 서버에 요청을 하도록 하는 것이니까? 이것은 서버측 공격인가? 라고 생각할 수 있다. 하지만 CSRF 공격은 XSS와 마찬가지로 클라이언트 측 공격이라는 사실을 인지해야 한다.

XSS : 클라이언트 측 공격
피해자의 단말기에서 클라이언트 측 스크립트를 삽입해 실행하는 공격
(결과 : 악성 스크립트가 실행된다.)

CSRF : 서버측 공격?! 클라이언트 측 공격
피해자가 서버로 공격자가 원하는 임의의 요청을 하게 만드는 공격
(결과 : 피해자가 서버로 자기 의지와 상관없이 어떤 요청을 보낸다.)

XSS와 CSRF 두 가지 모두 클라이언트 측 공격이다.

CSRF의 경우 서버에 요청하도록 유도한다고 생각하여 서버측 공격이라고 생각할 수 있지만, 중요한건 누구를 공격하냐! 하는 것이다. CSRF 서버를 공격하는게 아니고, 이용자(클라이언트)를 공격하는 것이다. 다만 CSRF는 서버에 요청을 하도록한다는 점이 있을 뿐이다.

CSRF 를 XSS 와 연계하여 이용하는 경우가 많아서 서로 헷갈릴 수 있지만 둘은 엄연히 다르므로, 면접에서 차이를 물어보는 경우가 많다고 한다. XSS와 달리 CSRF는 스크립트를 삽입하지 않아도 특정 요청을 하도록 유도할 수 있다는 점이 다르다.

 

CSRF (feat. XSS)

CSRF는 이용자가 특정 URL을 클릭하도록 유도해야만 한다.

이때 CSRF 공격을 XSS와 연동하면 공격 성공률을 높일 수 있다.

XSS : 임의의 스크립트를 실행한다.
임의의 스크립트 : 서버로 어떤 요청을 보내게 만드는 것

이렇게 XSS를 이용하면 Zero Click이 가능해진다. 

 

GET Method를 이용한 Zero Click

Javascript Img
<script>
var i = new Image();
i.src = "Bad Request Link";
</script>

Image Tag
<img src="Bad Reqeust Link">

즉 요청을 클릭하지 않아도 된다는 것이다.

 

XSS를 CSRF에 이용하면(연계를 하면) 엄청난 공격이 되어버린다는 것이다.

해당 게시글을 읽는 모든 유저의 비밀번호를 변경하는 것도 가능해지는 등, 날개를 단다.🪁

다만 서로 다른 취약점이지만 서로의 시너지가 좋아서 같이 쓰이는 것일 뿐이라는 사실은 잊어서는 안된다.

XSS가 없다면? -> CSRF는 없는가?
NO!!
서로 별개의 취약점이기 때문에 그렇지 않다는 것이다.
다만 XSS를 활용할 수 없을 뿐인 것!!

---

CSRF 의 발생 위치

그렇다면 CSRF는 어디에서 일어나는가?

CSRF는 요청을 위조하는 공격이자, 요청을 하게 만드는 공격이다.

즉 모든 요청에서 일어날 수 있다.

다만 여기서 중요한 점은 CSRF의 경우 컨설턴트의 주관이 들어간다는 것이다.

 

컨설턴트의 주관?

해당 요청을 확인해보니, 특정 요청을 임의로 만들 수 있다면? CSRF 취약점으로 판단할 수 있다.

하지만 모든 요청에 대하여 CSRF 취약점으로 판단할 수는 없는 노릇이다.

보호해야할 대상인지에 대한 여부의 판단이 필요하다는 것이다.

누가봐도 위험한 것들이 존재한다.

비밀번호 / 개인정보 등의 민감정보들.

이런 것들 이외의 게시판 글 수정 과 같은 민감정보에는 해당하지 않는 것들에 대한 CSRF 의 경우, 컨설턴트의 주관이 들어가게 된다는 것이다.

여기서 중요한 것은 '왜 위험한지 설명할 수 있다면?!' 이것은 취약점으로 판단할 수 있다는 것이다.

 

CSRF 대응 및 우회

가장 좋은 대응법은 인증정보를 추가하는 것이다.

비밀번호를 변경하는 경우 '기존 비밀번호 확인', '휴대폰 인증' 과 같은 2차 인증(인증 정보)이 필요하다면 공격이 불가능해진다.

예측할 수 없는 정보는 입력할 수 없기 때문이다.

요청을 했는데? 인증정보가 없다?! 그렇다면 CSRF 취약점으로 이용할 수 있다는 것이다.

ex)
1. 게시판 글 쓰기 유도
2. 관리자가 보도록 유도
- > 관리자 계정으로 가짜 공지를 작성
(그렇다면 취약점이라고 할 수 있다.)

즉 CSRF 취약점은 요청을 위조하는 것이다.

그럼 다음과 같이 생각할 수도 있다. (의식의 흐름)

1. 요청을 위조할 수 있다는 것이라면?
2. LINK를 못 만들면 되는게 아닌가? 
3. LINK는 GET 방식을 사용하니까 POST Method를 이용하면 되겠다.!

하지만 이 생각은 반만 맞는 말이라는 것이 문제이다.

CSRF 취약점은 GET방식이어서가 아니라 해당 요청에 인증정보가 없어서 요청을 위조할 수 있었던 것이 문제였다는 것이다. 그런데 Method를 바꾸면? 공격 방식이 달라질 뿐 그대로 취약점인 것에는 변함이 없다는 것이다.

POST Method의 경우, Burp Suite를 통해 Change Method를 해본 후 해당 요청이 성공적으로 동작되는 경우, GET 방식으로서 링크(Link)를 생성하면 된다.

GET방식이 동작되지 않는 경우 링크(Link)를 생성하는 것이 아닌 폼 태그(<from></form>)를 활용하여 POST Method에 대한 공격이 가능해진다.

하지만 form Tag를 활용하려면 XSS가 존재해야한다.

그러므로 만약 POST Method로만 바꾸므로서 완전무결하려면 XSS가 아예 존재하지 않아야하지만... 그것이 거의 불가능에 가깝기 때문이다. (그래서 POST 방식으로 바꿔서 해결하는 방법은 반만 맞는 방법이라는 것)

 

POST Method에 대한 공격

CSRF와 XSS 취약점이 확인 및 이용

CSRF 취약점이 있는지 확인하는 방법

1. Burp를 키고 해당 요청을 눌러본다.
2. 어떤 요청이 나가는지 확인해본다.
3. 해당 요청에 인증 정보가 있는지 확인해본다.
4. (인증 정보가 없다면?) XSS 취약점이 있다면?!
5. CSRF & XSS 연계 (form 태그를 추가하면된다.)

<h1>Click This!!<h1>
<form method="POST" action="CSRF 요청 주소">
<input type="hidden" name=" " value=" ">
<input buttion>
</form>

type을 hiiden으로 지정하지 않는다면? 해당 요청하는 값이 보이게 된다. 그러므로 hidden 을 이용하여 값은 보여주지 않고 버튼 클릭만 유도한다.

그런데? 요즘 누가 함부로 링크를 누르고, 함부로 버튼을 누르는가?

그러므로 이 동작도 필요없도록(버튼 클릭을 유도하지 않고) 자동화를 해버리면 된다.

버튼을 지워버리고!
<form method="POST" action="CSRF 요청 주소" id="tempForm">
<input type="hidden" name=" " value=" ">
</form>
<script>
document.getElementById('tempForm').submit();
</script>

위와 같이 script를 이용하여 submit으로 버튼을 누르지 않아도 요청이 가도록 할 수 있다.

한가지 아쉬움 점이 있다면?!

저렇게 쓰는 경우 누른 페이지와 다른 페이지(redirect)가 뜨거나 or 변경을 알리는 특정 알림/경고창(alert) 이 뜨는 경우가 있을 수 있다.

리디렉션을 하는 경우 다른 페이지로 넘어가는 순간 스크립트는 효력을 잃기 때문에 다시 리디렉션 해주는 것은 불가능하다. 그러므로 해당 요청 이후 다른 페이지로 리디렉션 되는 것으로 설정되어 있는 경우 무언가 의심을 살 수 있다. 경고창도 마찬가지 이다.

의심에 의해 무언가 바뀐것을 인지하고 다시 바꿔버린다면? CSRF 공격을 한 의미가 없어질 것이다.

이를 방지하기 위해 우리는 위의 행위를 iframe 에서 처리하도록 한다.

 

 iframe 이용

<iframe name="stealthFrame"></iframe>
(id 가 아니라 name property를 이용해야한다.!)
<form method="POST" action="CSRF 요청 주소" id="tempForm" target="stealthFrame">
<input type="hidden" name=" " value=" ">
</form>
<script>
document.getElementById('tempForm').submit();
</script>

위와 같이 iframe에 name을 지정해주고 해당 iframe을 target으로 하는 form을 작성하여 보내는 것이다.

여기서 한가지 찜찜한 점이 남는다.

(여기부터는 해커들의 iframe 이용에 대한 develop 과정이다.)

iframe이 눈에 보인다는 문제가 생긴다. 누가봐도 이상할 것이다.

그럼 iframe의 경계를 조절하여 0으로 줄여보자!

<iframe width="0" height="0" border="0" name="stealthFrame"></iframe>

음... 여기서 또 다시 살짝 frame이 남아 있는 것이 보인다.

그럼 아예 안보이게 해보자!

<iframe name="stealthFrame" style='display:none;'></iframe>

위와 같이 경계를 지정하는 것이 아니고 디스플레이를 none으로 하여 표시를 안하도록 한다면 안보인다.

여기 까지의 과정이 점차 develop 되는 과정을 생각하는 연습으로 가장 최종적으로 안보이게 해둔 iframe을 활용하면 된다.

 

CSRF Token

CSRF Token이란 CSRF 공격을 막기 위해서 만든 랜덤한 토큰을 의미한다.

ex) 마이페이지에 접근할 때

(CSRF 취약점이 될 수 있을만한) 특정 데이터를 변경하는 페이지에 접근할 때에 랜덤한 토큰을 발행한다.

<input type="hidden" name="csrfT0ken" value=g12e34a56r7890">

위와 같이 변경 링크를 요청할 때에 토큰을 넣어서 보낸다는 것이다. 이 토큰은 사용자가 굳이 직접 넣이 않아도 해당 페이지에서 인증 정보가 포함되게 만드는 것이다.

토큰의 발행 및 동작

1. 특정 페이지 접근 시, 토큰을 발행
2. 해당 토큰을 서버(세션)에 저장
3. 변경 요청시에 비교
4 - True. 일치한다면 그대로 변경 진행
4 - False. 일치하지 않는다면? 변경 실행 X

해당 토큰을 해당 페이지 접근시 발행하여 서버(세션)에 저장해두고 변경 요청시에 비교하여 일치하지 않는다면 해당 페이지에서 보낸 요청이 아니거나 유효한 요청이 아니라고 판단하여 변경을 실행하지 않게 되는 것이다.

토큰은 해당 페이지에 접근 했을 때만 발행되는 것으로 다른페이지에서 iframe을 이용하여 요청을 한번에 보내는 등의 행위를 막아내는 것이다.

그렇다면? CSRF Token이 존재한다면 CSRF 공격이 불가능한걸까?

그렇지 않다 CSRF의 경우 해당 페이지에만 접근하면 얻을 수 있는 정보로서 인증 정보에 해당하기는 하지만 알아낼 수 없는 정보가 아니기 때문이다.

그러므로 iframe을 두개 띄우는 등의 방법으로 우회하는 것이가능해진다.

해당 페이지에 접속한 후 토큰을 빼오고 그 후 값을 적용하는 방식으로 말이다.

(해당 방식은 과제를 통해 더 다뤄 볼 것이다.)

---

질문 환영, 수정 및 보완에 대한 지적 환영