CORS와 SOP, XSS 그리고 CSRF

CORS(Cross Origin Resource Sharing)란?

---

브라우저가 A사이트에서 B사이트로 API 요청을 가능하다록 하는 정책이다.

브라우저의 보안과 관련해서 중요한 역할을 하는 것이다.

CORS가 생겨난 이유

---

모든 사이트간에 요청이 자유롭게 되도록 허용하면 간단한 일인데 굳이
CORS라는 정책을 만든 이유를 알아보자.

XSS(Cross Site Scripting) 사례로 알아보자.

1. 착한 사이트에 로그인을 해서 토큰을 브라우저 쿠키에 저장한다. 자동 로그인을 위해서
2. 현재 인증 정보가 쿠키에 저장되어 있는 것이다. 예로 jwt token
3. 나쁜 사이트가 착한 사이트에 쿠키를 탈취하는 스크립트를 심은 게시글을 올린다.
4. 사용자가 게시글을 본다.
5. 게시글에서 이미지에 나쁜 사이트로 쿠키를 탈취하는 스크립트를 심는다.
6. 사용자는 이미지를 클릭한다.
7. 쿠키는 나쁜 사이트로 탈취된다.
8. 나쁜 사이트에서는 이 쿠키로 착한 사이트에 정보를 요청한다.

이와 같은 이유로 출처가 다른 사이트끼리는 요청을 할 수 없도록 CORS가 생겨난 것이다.

Origin이란?

---

origin은 url에서 프로토콜, 도메인, 포트번호를 합친 것을 의미한다.

window.location.origin 스크립트를 실행했을 때 나오는 것이다.

즉, 교차 출처 리소스라고 번역할 수 있는데 다른 출처(cross origin)끼리 리소스를 공유할 수 있도록 한다는 의미로
cors라는 이름이 탄생한 것이다.

SOP(Same Origin Policy)

---

CORS와 반대의 개념으로 동일 출처 정책이다. 즉, 같은 ㅊㄹ처끼리만 요청을 할 수 있도록 하는 정책이다.

이것을 브라우저가 구현하고 있다. 즉, CORS는 교차 출처끼리 리소스를 공유할 수 있도록 SOP를 풀어주는 정책인 것이다.

브라우저의 CORS 동작원리

---

1. 브라우저는 요청 헤더에 Origin이라는 필드에 본인 출처를 넣어서 보낸다.
   (cookie를 사용하는 보안과 관련된 것은 credentials 헤더를 true로 보내줘야 한다.)
2. 서버는 응답 헤더에 Access-Control-Allow-Origin에 본인이 허용하는 출처를 담아서 응답하게 된다.
   (cookie와 같은 보안과 관련된 것은 Access-Control-Allow-Credentials를 true로 응답해야 한다.)
3. 브라우저는 Origin과 Access-Control-Allow-Origin을 비교하고, 맞는지 틀린지 검사만 한다.
4. 맞으면 그대로 응답을 사용하고, 틀리다면 에러를 뱉고 응답을 버린다.

Simple Request

---

위에서 설명한 CORS의 동작 원리는 GET, POST와 같은 일정 조건의 요청들에 사용된다.

이것을 simple request라고 한다. 하지만 delete, put고 같은 것들은 기존 데이터에 영향을 주는 것이기 때문에

Preflight 요청이란걸 먼저 보내서 본 요청이 안전한지 확인하고, 이상이 없다면 요청을 보낼 수 있다.

Preflight 요청

Preflight는 사전적으로 비행 전의, 비행에 대비한이라는 뜻을 가진다.

말 그대로 request 전에 사전 요청을 한다는 의미이다.

아무래도 PUT, DELETE와 같이 서버의 데이터에 영향을 주는 행위는 위험하기 때문에

사전 요청을 하는 것인데 서버에게 해당 request origin에 DELETE를 허용할 것인지 묻는 것이다.

GET같은 경우는 데이터에 영향이 없기 때문에 응답을 버리기만 하면 되는데 DELETE를 데이터를 변경해버리기 때문이다.

아래는 reuqest와 response이다.

// request
OPTIONS /resource/foo
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: origin, x-requested-with
Origin: https://foo.bar.org

// responnse
HTTP/1.1 204 No Content
Connection: keep-alive
Access-Control-Allow-Origin: https://foo.bar.org
Access-Control-Allow-Methods: POST, GET, OPTIONS, DELETE
Access-Control-Max-Age: 86400 // 동일한 origin에 대해서는 기간 내에 사ㅏ전 요청에 대한 응답이 선택적으로 이루어질 수 있다고 함.

CSRF(Cross Site Request Forgery)

---

XSS 방식의 공격말고도 CSFR 공격도 있다 두 공격 방법의 차이점을 알아보자.

XSS

브라우저에서 자바 스크립트가 실행되는 취약점으로 이를 이용해 쿠키 탈취를 해서

해당 사용자처럼 나쁜 사이트에서 사용될 수 있다.

방법은 대략 두 가지가 있다.

• 스토어드

  게시글을 올려서 거기에 쿠키 탈취 스크립트를 심어서 나쁜 사이트로 쿠키를 탈취하도록 한다.

• 리플렉티드

  메일을 보내서 메일에 링크를 주고, 링크에 탈취할 사이트의 쿼리 파라미터로 스크립트를 요청하는 것이다.
  그럼 웹 서버는 이걸 팅겨내게 되는데 팅겨내면 브라우저는 바로 해당 스크립트를 실행하여
  정보를 나쁜 사이트로 보내게 된다.

CSRF

xss와 연관이 있을 수도 있고 없을 수도 있다.

메일을 보내면 xss와 연관은 없다. 왜냐면 로그인만 되어 있다면, 나쁜 사이트로 들어오라고만 하면

브라우저는 헤더 정보들을 자동으로 보내기 때문이다. 그럼 나쁜 사이트는 이 정보를 가지고

비밀번호를 변경하는 행위를 하게 된다.

xss 방어가 되어 있지 않아서 게시글에 해당 스크립트를 넣어놔도 동일하다.

방어 방법

XSS

• 스토어드
  • 아예 스크립트가 실해되지 않도록 이스케이프 처리한다.
  • http.only를 활성화
• 리플렉티드
  • 이상한 요청이 오면 처리를 하면 될까?
• 탈취된 후
  • cors

CSRF

• 일단 xss를 방어해서 스크립트 실행이 사이트에서 안되도록 해야함.
• 메일로 피싱을 하는 경우는 referrer로 체크 가능
• xss가 방어가 안돼서 착한 사이트에서 실행되면, referrer는 의미가 없음.

참고 자료

---

https://4rgos.tistory.com/1

https://it-eldorado.tistory.com/163

https://inpa.tistory.com/entry/WEB-📚-CORS-💯-정리-해결-방법-👏

https://developer.mozilla.org/ko/docs/Web/HTTP/CORS

https://developer.mozilla.org/ko/docs/Glossary/Preflight_request

https://www.youtube.com/watch?v=Zimhvf2B7Es&t=416s

https://www.youtube.com/playlist?list=PLK3IOiy3HLQb6jA9bA5-nJqFxJ96aytCz