CORS(Cross origin resource sharing)
2012년 이후에 출시된 거의 모든 브라우저버전에 탑재된 보안기능.
응답헤더에 Access-Control-Allow-Origin 가 있으면 CORS위반이 아니다
🚫AJAX는 Same Origin Policy라는 원칙이 있다
CORS가 도메인 website.com에서 사용가능한 서버에서 구성되면 리소스는 ajax를 통해 동일한 도메인에서 제공되는 주소(same origin policy)에서 시작돼야 한다
즉, domain-b.com에서 CORS를 활성화하고 domain-b.com의 get요청만 허용하도록 구성한 겨우 domain-a.com에 호스팅된 https://domain-b.com/image/example.png 이미지를 이용하려고 할 때 대부분의 방문자에게 해당 이미지가 로드되지 않는다. 우리가 어떤 특별한 정책을 따로 준수하지 않아도 우리의 리소스는 CORS에 의해 보호되고 있다
same origin policy (같은 출처)
same origin policy란?
- 현재 브라우저가 보여지고 있는 HTML을 내려준 웹서버(Origin- 동일 도메인, 동일port, 동일 프로토콜)에게만 Ajax 요청을 보낼 수 있음
- CORS가 미 구현된 웹브라우저에서는 다른 도메인간 통신이 불가능
- 우회방법으로 JSONP, IFAME IO, CrossDomain Proxy 등이 고안됨(get만 허용, 보안취약, 동기호출안됨 등 문제있음
- HTML5에서 다른 도메인간 통신이 가능한 스펙이 추가되었는데 바로 CORS이다
Preflight Requests(예비요청)
만약에 put이나 delete와 같은 http요청이 이루어진다면 , 혹은 구체화되지 않은 헤더를 더해준다면 브라우저는 실제 요청 전에 서버가 실제 요청을 받아도 괜찮은지 확인하는 preflight 요청을 보낸다 해당 인스터에서 브라우저가 신경쓰는 유일한 것은 서버가 Access-Control-Allow-Origin 헤더를 반환하는지의 여부이다. 브라우저가 preflite 요청을 보내면 해당 요청은 option라는 http요청메소드를 사용한다 이 요청은 서버가 앞으로 나올 내용을 알고 허용 여부를 결정할 수 있도록 하기 위한 것이다. 서버가 성공(200) 상태코드로 preflite 요청에 응답하지 않거나 올바른 헤더를 포함하지 않으면 브라우저는 실제 요청을 시도조차하지 않는다
만약에 AJAX요청에 custom header를 추가하면 브라우저가 실제 요청전에 preflite 요청을자동으로 포함한다.
XSS(Cross Site Scripting)
XSS는 주입식 공격이다. 공격자가 악의적인 스크립트를 신뢰할 수 있는 웹사이트에 삽입하는 방법의 공격이며 총 3가지 유형이 있다.
- Stored XSS : 보호되지 않고 검수되지 않은 사용자 입력으로 인한 취약점(데이터 베이스에 직접 저장되어 다른 사용자에게 표시됨)
- Reflected XSS : 웹 페이지에서 직접 사용되는 URL의 비보안에 의해 발생하는 취약점
- Dom based XSS : 웹 페이지에서 직접 사용되는 URL의 비보안에 의해 발생한 취약점이라는 점에서 reflected XSS와 비슷하지만 DOM based XSS는 서버측으로 이동하지 않는다
CSRF(Cross site request forgery)
CSRF는 악의적인 웹사이트, 전자메일, 블로그, 인스턴트 메시지 또는 프로그램으로 인해
사용자의 웹브라우저가 사용자가 인증 된 다른 신뢰할 수 있는 사이트에서 원치 않는 작업을 수행 할 때 발생하는 공격 유형이다. 이 취약점은 브라우저가 세션 쿠키, ip 주소 또는 각 요청과 유사한 인증 리소스를 자동으로 보내는 경우 발생할 수 있다
'Web' 카테고리의 다른 글
| [web] Session VS JWT(JSON Web Token) (0) | 2022.02.09 |
|---|