CSRF 대응방법, SOP와 CORS

두서없는내용 [ CSRF와 XSS 차이점 ]

CSRF에 대해 공부를 하다보면 XSS와 비슷한점이 많아 정확한 차이점이 어떤 것이였는지 헷갈리게 된다.

 

CSRF는 피해자가 원치않는 공격자의 요청을 보내게 만드는 공격 기법,

요청을 위조해서 피해자가 요청을 하게 만드는 공격이라 할 수 있다.

 

XSS는 위의 CSRF와는 다르게 피해자의 브라우저에서 실행되는 스크립트를 고의적으로 삽입해,  피해자가 의도치 않았지만 공격자가 원하는 스크립트를 실행 하는 공격기법 이라 할 수 있다.

 

CSRF 대응방법

1. Referer Check.

Referer이란? 

> 지금 이 요청이 어디에서 전송되는 것인지를 나타내는 것이다.

실제 Referer

실제 비밀번호 변경 요청은 mypage.php에서 mypageupdate.php로 요청을 보내는게 정상적인 순서, 그렇지만

CSRF를 통해 요청을 위조한다면 mypage.php가 아닌 다른 페이지에서 요청이 가게된다.

CSRF공격시 Referer

그래서 Referer을 mypage.php가 아니면 비밀번호 변경 요청을 받지 않는식으로 Referer을 체크를 해줌으로써 CSRF공격을 방어할 수 있게 된다.

2. 인증정보 추가.

CSRF는 요청을 위조해서 보내는 기법, 그 요청을 위조할 수 있는 전제중 하나가 "서버에 보내는 파라미터를 공격자가 알고있어야 한다." 이다. 예를들어 위 그림과 같이 비밀번호 변경 CSRF 공격을할때 'pw'라는 파라미터만 보내주면 되기 때문에 공격자는 pw값만 담아 요청을 위조할수 있게 된다. 그래서 우리는 공격자가 알 지 못하는 '인증정보'를 추가하여 서버에 요청할 때 담아서 보내는 방식을 활용할 수 있다. 예를들면 흔히 비밀번호 변경을 할 때 '현재 비밀번호' 를 입력하고 '변경 할 비밀번호' 를 입력 하듯이.

이 '현재 비밀번호' 가 인증정보 역할을 하게 된다.

3. CSRF 토큰 추가.

CSRF 토큰이란? 사용자의 요청을 인증하기 위해 사용되는 무작위 문자열이다. 사용자가 접속을 한다면 세션에 임의의 난수를 저장, 그리고 사용자의 요청마다 해당 난수를 포함시켜 서버에 전송하게 된다. 그리고 서버는 요청 파라미터에 전달된 토큰과 서버 세션에 저장된 토큰을 비교하여 검사한다.

즉 공격자가 사용자의 세션 쿠키만으로는 악성 요청을 보낼 수 없도록 각 요청에 CSRF 토큰을 검증하여 정상적인 요청인지 확인하는 방식이다.

 

---

SOP와 CORS

 

지난 CSRF 연습문제들 중에 CSRF공격을 GET방식이 아닌 POST방식 일때 XSS취약점을 활용하여 스크립트를 삽입해

서버로 요청을 보내는 방식으로 어드민 계정을 탈취하였던 적이 있었다.

이때 드는 의문, 어차피 서버로 요청을 보내기만 하면 되는 것인데 같은 도메인을 가진 페이지에 XSS취약점을 찾을 필요가 있을까?

내가 원하는 대로 임의로 페이지를 만들어 그 사이트에 스크립트를 삽입하고 유도하면 되지 않을까? 라는 생각이 들게된다.

 

이 이유가 SOP로 설명이 된다.

SOP[ Same-origin Policy ]란?  우선 위키 백과를 살펴보았다.

> 동일-출처 정책/ 웹 애플리케이션의 중요한 보안모델이다. 정책에 따라 웹 브라우저는 첫번째 웹 페이지에 포함된 스크립트가 두 번째 웹 페에지의 데이터에 액세스하는 것을 허용하지만 두 웹 페이지의 출처가 동일한 경우에만 허용된다.

 

즉 출처가 동일한 경우에만 스크립트 사용이 가능하다! 라는 것이다.

이 출처가 같은 기준은 [스킴, 도메인, 포트] 이며. 셋 중 하나라도 다를 시에는 스크립트 접근을 제한하게 된다.

 

그렇지만 다른 페이지에 데이터를 가져와야 하는경우가 실제 개발에선 잦다. 그래서 실제 접근이 가능하도록 규칙을 정해주었다.

그것이 CORS이다.

 

CORS[Cross-Origin Resource Sharing] 란?

> 몇가지 규칙을 정해주어 다른 출처에서도 데이터를 사용 하도록 허용해주는 것이다.

핵심적인 규칙 : ACAO [Access-Control-Allow-Origin]

응답에 ACAO 헤더가 존재한다. 이 ACAO는 화이트리스트와 같은 방식으로 동작을 하게되는데.

ACAO에 허락된 도메인이 아니면 다른 출처에서 데이터 사용을 접근을 제한하게 된다는것.

 

그치만 실제 운영에서 ACAO헤더를 관리하며 화이트 리스트를 추가 해주어야 하는 번거로움이 생겨 [ACAO : *] 와 같은 방식 사용 되곤 한다.

이렇게 되면은 사실상 SOP를 사용하지 않겠다는 것이기 때문에 새로운 규칙이 생겨났는데 그 규칙이 [ACAC]이다.

ACAC (Access-Controll-Allow-Credentials)

> 타 도메인에서 쿠키를 포함해서 요청한 것에 대한 응답은 *를 사용할 수 없음

즉 *를 사용하여 모든 출처에서의 데이터 사용 접근을 허용하겠지만, 쿠키를 포함해서 요청한 것에 대한것은 보안을 위해 *를 사용할 수 없게 만들어 졌다. 아래 그림과 같은경우이다.

실제 쿠키포함 데이터 요청

 

하지만 이 마저도 취약한경우가 존재한다.

1) ACAO헤더를 요청 Origin 그대로 응답하도록 설정한 경우

2) ACAC헤더를 True로 응답하도록 개발하는 경우

 

위 두가지의 경우에도 SOP정책을 우회할수 있는 경우에 속하게 된다. 즉 이경우에는 처음 가졌던 의문

<"어차피 서버로 요청을 보내기만 하면 되는 것인데 같은 도메인을 가진 페이지에 XSS취약점을 찾을 필요가 있을까?">

에 대답으로 [아니오] 라는 대답이 할 수있는 경우가 된다.

 

즉 이경우에는 XSS취약점을 찾을 필요가 없이 임의로 페이지를 작성해서 CSRF 공격이 가능하다는 뜻이 된다