Web Arch. / Browser Security : CORS, XSS, CSRF

 

1. 브라우저 보안의 필요성

 

브라우저는 클라이언트와 서버 간 통신을 하며 서버의 데이터, 클라이언트의 사용자 정보 등을 전달하고 표현하는 역할을 하기 때문에, 해커들로부터 공격받기 쉽다. 특히, 브라우저가 자바스크립트를 구동하기 때문에 해커가 사용자의 웹페이지를 조작하거나, 사용자의 정보를 빼돌릴 수 있다.

 

---

 

2.  브라우저를 공격하는 대표적인 2가지 방법, XSS, CSRF

 

 

XSS : Cross Site Scripting

클라이언트가 서버를 신뢰해서 발생하는 문제이다.

XSS는 해커가 서버의 데이터에 특정 <script> 태그를 서버의 데이터 상에 올려놓고, 다른 사용자가 그 데이터를 서버의 응답으로 받게되면 그 사용자가 받은 데이터에 <script> 태그가 있기 때문에 웹페이지에서 DOM을 변경하게 되어 피해를 입게 되는 방식이다. 기본적인 XSS 공격 방식은 브라우저에서 막도록 되어있다.

 

일반적으로 <script> 나 <form> 태그 등이 포함되어 있기 때문에, 서버에서 "<>"가 포함된 HTTP 요청은 받지 않는 방법등이 있다. 순수하게 "<>" 기호를 보내는 경우와 비교하여, 정규표현식으로 해당 코드를 걸러낸다.(RegEX)

그 외에도 여러가지 방법으로 XSS 공격을 서버에서 막아낸다.

 

wpvip.com/documentation/vip-go/vip-code-review/javascript-security-best-practices/

gomakethings.com/preventing-cross-site-scripting-attacks-when-using-innerhtml-in-vanilla-javascript/

출처 : https://spanning.com/blog/cross-site-scripting-web-based-application-security-part-3/

 

 

---

 

 

CSRF : Cross Site Request Forgery

CSRF는 서버가 클라이언트를 신뢰해서 발생하는 문제이다.

해커가 다른 사용자의 인증 정보를 가로채서 서버에 접속 요청을 하면, 서버는 해커를 사용자로 인식하여 요청에 대한 응답을 하게 되는 것이다. 해커는 주로 링크 등을 보내서 다른 사용자의 인증 정보를 가로챈다. 가짜 페이지 등을 만들어서 사용자가 접속하게 한 뒤,사용자의 정보를 입력하게 하여 해당 정보를 탈취하는 것이다.

 

출처 : https://dev.to/caffiendkitten/it-s-really-me-i-swear-an-intro-to-csrf-543p

 

 

 

 

 

---

 

3. CORS

 

CORS 적용 개요

Cross Origin Resource Sharing의 준말로, 특정 웹페이지를 구성하는 요소를 여러 개의 서버(Origin)에서 불러와서 웹페이지를 표시할 때의 보안 정책을 의미하는 단어이다. 보통 어떤 서버에 리소스를 요청하는 코드는 XMLHttpRequest 또는 Fetch를 이용하는데, 이러한 코드들은 모두 동일한 서버에서만 요청을 받을 수 있도록 제한되어 있다.

(Same Origin Policy, developer.mozilla.org/ko/docs/Web/Security/Same-origin_policy)

 

그렇기 때문에 다른 출처에서 리소스를 불러오려면 CORS가 포함된 응답을 반환해야한다.아래 그림에서 웹페이지를 구성하는 빨간색 부분은 domain-a.com과 다른 domain-b.com에서 불러와서 표현하는데, 그렇게 다른 도메인에서 리소스를 불러올 때는 보안 정책인 CORS를 적용한다.

출처 : MDN CORS

 

Pre-flight 요청 승인 후 본 요청 승인하는 방식

 

CORS는 Pre flight 신호를 서버에 보내어 올바른 요청 신호임을 확인받고 본 요청을 다시 보내는 방식으로 정해져있다. 아래 그림과 같이 클라이언트가 'OPTIONS' 신호를 서버에게 보내어 우선 요청에 대한 pre-flight를 날리고, 서버가 200 OK 신호를 보내면 다시 클라이언트가 POST로 본 요청을 보내도록 되어있다. 다만, Simple Request에 대해서는 이러한 과정이 생략되고 바로 본 요청과 응답을 하도록 되어있는데, 아래에서 상세히 살펴보도록 하자.

1. Simple Request

 

MDN 문서에 따르면, Simple Request는 다음 조건을 모두 충족해야 한다.

 

• GET, HEAD, POST 메소드 중 하나이여야 한다.
• fetch에서 지정한 CORS-safelisted request에 해당하는 header 이여야 한다.(Accept, Content-Type 등)
• Content-Type의 종류가 한정된다(text/plain, multipart/form-data, application/x-www-form-urlencoded