CSRF 개념

1.CSRF(1) 

※ 주의 사항 :

1. 교육 목적으로만 이용 해주세요.
2. 무단 침입, 데이터 유출, 개인 정보 침해 등 불법적인 활동은 심각한 법적 결과를 초래할 수 있습니다.
3. 개인적인 테스트 환경을 구축해서 실습하시길 바랍니다.

1.1 개념 

CSRF(Cross-Site Requset Forgery)가 무엇인가?

공격자가 피해자를 하여금 서버로 임의의 요청을 하게 만드는 웹 보안 취약점이다. 예를 들어, 피해자가 로그인한 상태에서 CSRF 링크를 클릭하면,
링크에 담긴 요청이 실제 피해자가 한 것으로 인식되어 요청을 정상적으로 처리한다. 이러한 공격을 통해 공격자는 피해자의 계정으로 정보를
변경하거나 결제, 이체 등을 수행할 수 있다. 이는 피해자가 심각한 금전적 손실을 보거나 계정을 완전히 탈취당할 위험이 있는 공격이다.

1.2 CSRF vs XSS

공통점

두 공격 모두 클라이언트 측 공격이고, 링크를 클릭하도록 피해자를 유도하는 방법을 이용한다. 그렇지만 공격하는 목표와 과정이 다르다는 것을 명심해야 한다.

차이점

1. 취약점의 공격 적용 범위

• CSRF는 주로 사용자가 할 수 있는 특정한 행동에만 영향을 준다. 예를 들면, 비밀번호를 변경하거나 돈을 이체하는 등의 특정 요청을 보낸다.

• XSS는 사용자가 할 수 있는 모든 행동에 영향을 미칠 수 있다. 예를 들면 세션을 탈취하거나 데이터 변조를 변조하고, 사용자의 권한으로 임의의
  작업을 수행할 수 있다.

2. 요청과 응답

• CSRF는 공격자가 피해자를 하여금 HTTP 요청을 보내게 할 수 있지만, 그 요청에 대한 응답은 확인 할 수 없다. 즉, 공격자는 피해자가 요청하게
  만들 수는 있지만 결과는 볼 수 없다.

• XSS는 공격자는 삽입된 스크립트로 임의의 요청을 보낼 수 있으며, 그 응답을 읽어 낼 수 있다. 그 예로 외부 도메인으로 데이터 유출이 가능하다.

1.3 CSRF (feat.XSS)

일반적으로 CSRF는 공격자가 피해자에게 링크를 전달하고, 피해자가 링크를 클릭하면 임의의 요청을 하게 만드는 방식으로 설명된다. 그렇다면, XSS와
함께 사용된다면 어떤 일이 벌어질까?

링크를 클릭하지 않더라도 XSS 취약점이 있는 페이지에 들어온 것만으로도 CSRF를 일으킬 수 있다. 이는 XSS를 통해 악성 스크립트를 작성하여 CSRF
요청을 자동으로 실행하게 만들기 때문이다. 이 결과는 잠시 뒤에 실습에서 후술하겠다.

⚠주의⚠

단순히 CSRF 공격 하나만 고려한다면, HTTP METHOD를 GET에서 POST로 변경하기만 해도 방지할 수 있다고 생각할 수 있다. 하지만 앞에서 살펴
보았듯이 XSS 공격과 결합한다면, form 태그를 이용해서 POST METHOD로 파라미터를 요청할 수 있기 때문에 HTTP METHOD를 GET에서 POST로
변경하는 것만으로 는 방지할 수 없다.

1.4 CSRF 발생하는 곳

[그림 1-1]

일반적으로 CSRF 웹 보안 취약점은 피해자 계정의 정보를 변경하거나 금전적 손실을 초래할 수 있는 곳에 있다고 생각한다. 그런데 컨설턴트의 주관에
따라서 취약점의 범위가 더 넓어질 수 있다. 예를 들어, CSRF로 피해자에게 임의의 게시물을 작성하게 만들 수 있다. 어떤 컨설턴트는 익명이 보장되고
게시물을 삭제할 수 있으므로 취약점이 아니라고 주장할 수 있지만, 다른 컨설턴트는 신원 도용, 프라이버시 침해 등 개인정보 보호법 위반이라고 볼 수
있다.

1.5 CSRF가 중요한 이유

개발자들이 디자인, 실용성, 편의성 등을 중시하다 보면, 사용자 인증 과정 없이도 특정 행동이 가능하게 만드는 실수를 자주 하게 된다. 따라서 CSRF는
다른 취약점보다 쉽게 발견할 수 있다. 그렇기 때문에 CSRF의 보안 절차와 취약점에 대해 자세히 알면 이러한 공격을 예방하는 데 큰 도움이 된다.

1.6 CSRF 실습

-CSRF만 이용한 공격

다음은 DVWA에서 CSRF실습을 하는 과정이다.

[그림 2-1]

위의 [그림 2-1] 와 같이 CSRF의 실습을 진행한다. 새로 변경할 비밀번호를 적고, 요청을 보내는 식이다. 지금 화면에는 보이지 않지만 1234라는
비밀번호로 제출했다. 이 요청이 어떤 파라미터의 데이터로 보내는 지 확인을 해야 CSRF인지 아닌지 알 수 있다. 따라서 Burp Suite으로 확인해보겠다.

[그림 2-2]

GET METHOD, /DVWA-master/vulnerablilites/csrf/?password_new=1234&password_conf=1234&Change=Change 요청(Request)을
보내는 것을 알 수 있다. CSRF는 누군가를 이용하거나 피해를 줄 수 있는 상황에서 본인을 인증할 정보가 포함되지 않은 모든 요청이 취약점이 될 수 있다.
[그림 2-2]의 파라미터에는 변경할 비밀번호만 포함되어 있기 때문에, 공격자는 이를 이용하여 링크를 전달해서 피해자의 비밀번호를 변경할 수 있다.

-CSRF 와 XSS 모두 이용한 공격

• XSS로 <form> 스크립트 작성하기

[그림 3-1]

지금부터는 portswigger 사이트의 LAB: CSRF vulnerability with no defenses 이다. 포스팅을 보고 난 뒤에 스스로 해보길 바란다. 로그인을 하고
MY Account에 들어가 보면 다음과 같은 페이지가 나온다. 이메일을 변경하는 폼을 포함된 페이지이다. 이 동작은 개인 정보를 바꾸는 행위이므로,
인증 정보가 포함된 요청이 아니라면 CSRF 취약점이라고 할 수 있다. Burp Suite을 통해 자세히 살펴보자.

[그림 3-2]

POST 방식으로 요청을 보내고 있고, 파라미터는 변경할 이메일만 작성되어 있다. 따라서 CSRF 취약점이 된다. 그렇지만 POST 방식이기 때문에,
링크를 보낼 url안에 파라미터가 없다. 이는 XSS취약점을 이용해서 다음과 같이 문제를 해결할 수 있다.

[그림 3-3]

아까 이메일을 변경할 수 있었던 화면에서 Go to exploit sever 버튼을 누르게 되면, [그림 3-3] 처럼 스크립트를 작성할 수 있는 페이지가 있다.
이제 form 태그를 이용하면 된다. POST방식으로, 보낼 URL은 이메일을 변경할 수 있는 페이지이고 input 박스에 변경할 이메일을 담아 제출하는
스크립트를 작성했다.

[그림 3-4]	[그림 3-5]	[그림 3-6]

[그림 3-4]에 들어온 피해자가 제출을 누르게 되면, [그림 3-5]처럼 화면이 이동한다. 왜냐하면 이메일 변경 요청을 보냈기 때문에 그에 대한 반응 값이
나타나기 때문이다. [그림 3-6]은 submit 버튼을 누르자 burp suite에서 확인 할 수 있었던 요청이다. 지금까지 form으로 요청을 보낸 작업이 직접
이메일을 변경한 [그림 3-2]와 같으므로 두 결과가 같다는 사실을 알 수 있다. 이렇듯 XSS를 이용해서 CSRF공격을 시도했지만 [그림 3-4] 같은 공격을
한다면, 너무 어설픈 공격처럼 보여서 아무도 클릭을 누르지 않을 것이다. 다음 그림은 input박스를 안 보이게 숨기고, 페이지에 들어오기만 하면 바로
요청을 보내도록 설계했다.

[그림 3-7]

input 태그 안에 type을 hidden 으로 바꾸면, 박스는 보이지 않는다. 그리고 <script> 를 작성해서 form개체의 속성을 submit한다고 작성하면
원하는 모습이 된다.

[그림 3-8]	[그림 3-9]

스크립트 페이지에 들어서자 마자 바로, [그림 3-8] 로 화면이 이동되었다. 데이터가 자동으로 제출되어 이메일을 변경했기 때문이다. 그 사실은
[그림 3-9]를 통해 알 수 있다.

• XSS로 <iframe> 스크립트 작성하기

[그림 4-1]

스크립트가 있던 페이지에 들어서자 마자 바로 요청이 보내진 건 좋았지만 아직도 어설픈 점이 있다. 바로 요청을 보내자 이메일이 변경된 화면으로
이동된다는
점이다. 어떻게 해결해야 할까? 바로 [그림 4-1]처럼 form을 iframe안에 담으면 된다. iframe을 모르는 사람들을 위해 간단히 설명하자면, 현재 url이
아닌 다른 url의 페이지를 가져온다. 비유해보자면 다른 페이지를 포스트 잇에 담아서 가져온다. 실제로 어떤지 다음 그림을 통해 이해해보자.

[그림 4-2]

iframe을 이용하면 화면이 이동하지도 않고 이와 같이 XSS취약점이 존재하는 페이지에 들어선 것 만으로도 이렇게 피해자의 이메일을 변경될 수 있다.
마지막으로 iframe의 흔적이 안 보이게 설정하고, 자연스럽게 만들어 보자. 그러면 피해자가 아무런 의식도 못한 채 이메일이 변경될 것이다.

[그림 4-3]	[그림 4-4]	[그림 4-5]

iframe의 스타일을 display:none으로 설정하고, 자연스럽게 글을 작성했다. 게시판이라고 생각한다면, 피해자는 게시판에서 글 만 읽었을 뿐인데,
개인 정보가 바뀌는 불상사가 발생했다. 따라서 인증 정보를 확인하고 검증하는 적절한 대책 마련이 중요하다.