5. 웹 보안 HTTPS & CORS

HTTPS & 웹 브라우저에서의 CORS

 

웹 보안에서 중요한 두 가지 개념은 HTTPS와 CORS이다. CORS는 웹 개발을 하다보면 한 번쯤은 보게된다는 에러메세지라고 한다. 웹 개발자의 신고식이라고도 하는 CORS가 무엇인지, 이 에러를 사전에 어떻게 방지할 수 있는지를  알아야 더 효율적이고 안전하게 웹 개발을 할 수 있기때문에 알아보고자 한다. 

 

HTTPS는 웹 통신의 보안을 강화하기 위한 프로토콜이며, CORS는 웹 브라우저에서의 발생할 수 있는 악의적, 유저 비의도 요청(CSRF)으로부터 부분적으로 보호하는 정책이다.

 

※ '부분적': 완벽하게는 CSRF를 방어하지 못한다는 의미이다. "웹"에만 있는 방어 정책으로 앱에도 없고 Form 요청도 방어 할수 없다.

---

HTTPS (HTTP Secured, TLS)

HTTPS는 SSL(Secure Sockets Layer) 또는 TLS(Transport Layer Security) 프로토콜을 사용하여 HTTP 요청 및 응답을 암호화한다. 이를 통해 두 주체(클라이언트와 서버, End-to-End)만 데이터에 접근할 수 있다.

• MITM(Man-In-The-Middle) 공격방지

HTTPS 보안 적용 방식

HTTPS는 대칭키 암호화와 비대칭키 암호화 방식의 장점만을 사용하여 보안을 강화한다.

• 비대칭키 암호화: 서버의 공개키(Public Key)와 비공개키(Private Key)를 사용하여 암호화 통신. 공개키는 노출되어도 안전하지만 연산속도가 느리다.
• 대칭키 암호화: 이후 통신에서는 대칭키(세션키)를 사용하여 데이터를 암호화 한다. 대칭키는 연산 속도가 빠르기 떄문에 매번 클라이언트와 서버가 요청/응답을 주고받을 때 성능에 영향을 주지 않는다.
• 서버는 클라이언트에게 비대칭키 중 공개키(Public)를 그냥 전달하지 않고 CA 인증기관의 인증을 거친 후 전달한다.
  • CA: SSL 인증서를 발급하는 기관, 신뢰할 수 있는 기관 

HTTPS 동작 원리

HTTPS는 2개의 비대칭키와 1개의 대칭키를 사용한다.

 

•  2개의 비대칭키 Pair (갑을 관계): 서버는 자신의 공개키와 비공개키를 보유하며, 공개키는 CA(인증기관)에서 인증된 후 클라이언트에게 전달된다.
  
  1.  서버의 공개키 + 서버의 비공개키: HTTPS 적용하려는 웹 서버가 갑 + HTTPS 통신하려는 클라이언트가 을
  2. CA의 공개키 + CA의 비공개 키: 인증을 해주는 주체인 CA가 갑 + 인증받아야하는 많은 웹 서버가 을
• 1개의 대칭키: 가장 마지막에 서버와 클라이언트가 주고받기 위해 사용하는 암호/복호화 성능이 좋은(빠른) 키
  
  • 서버와 클라이언트는 비대칭키를 사용해 세션키를 생성하고, 이 세션키로 암호화된 통신을 수행.

(A) 비대칭키 (서버 공개키 / 비공개키) + (B) 비대칭키 (CA 공개키 / 비공개키) + (C) 대칭키 (= 세션키)

 

---

CORS: CSRF "부분"방지를 위한 웹 브라우저 정책

CSRF(Cross-Site Request Forgery)

CSRF는 사용자가 의도하지 않은 상태에서 악의적인 자바스크립트를 통해 타 사이트에 요청이 전송되는 공격이다.

웹 브라우저는 이러한 공격을 방지하기 위해 SOP (Same-Origin Policy) 와 CORS (Cross-Origin Resource Sharing) 정책을 마련했다.

 

CORS의 역할

CORS는 웹 브라우저에서 자바스크립트 AJAX(Asynchronous JavaScript and XML) 요청을 통해 발생할 수 있는 CSRF공격을 방지하기 위한 정책이다. 하지만 CORS는 부분적인 방어만 제공하며 모든 CSRF 공격을 완벽하게 방어하지는 못한다. 예를 들어 네이티브 어플리케이션에서의 요청이나 웹 브라우저의 FORM 요청은 CORS의 영향을 받지 않는다.

 

W3C는 가장 먼저 SOP라는 정책표준을 도입했다. 이는 프론트엔드의 골머리를 썩게하는 시발점이 되었다.

그래서 CORS는 SOP(Same-Origin Policy) 정책을 보완하여, API 호출을 허용하기 위해 특정 조건에서만 Cross-Origin 요청을 허용한다. 이를 통해 웹 브라우저는 자바스크립트를 사용해 타 사이트의 리소스에 접근하는 것을 제한하고, 필요한 경우에만 예외를 두어 허용할 수 있게된다.

 

CSRF와 CORS가 헷갈릴 수 있다.

CS__(Cross-Site)와 CO__(Cross-Origin)혹은 Same-Site, Same-Origin 차이는 무엇일까?

 

• Origin과 Site의 차이
  • Origin: Scheme + Host Name(Domain Name) + Port
    • EX) https://api.sanghyun.com:8080 
• Site: Domain Name 중 SLD(Second-Level Domain) + TLD(Top-Level-Domain)
  • EX) api.sanghyun.com / admin.sanghyun.com (api 혹은 admin은 Sub Domain)
  • 다른 말로 정의하자면 TLD +1 혹은 eTLD + 1 영역을 가르킴.

---

• Domain, Origin과 Site 차이 정리
  • Domain: sanghyun.com
  • Origin: https// + sanghyun.com + :8080
  • Site: api.sanghyun.com or admin.sanghyun.com

 

CORS 서버 측 적용 방법

웹 서버는 CORS 정책을 적용하여 웹 브라우저로부터 어떤 요청을 허용할지 결장할 수 있다. 이를 위해 세 가지 주요 헤더를 설정한다. 

 

1. 허용된 Origin 설정

• Origin(브라우저): 브라우저가 요청을 보낼 때 포함하는 헤더, 요청이 발생한 출처를 나타낸다.
• Access-Control-Allow-Origin(서버): 서버가 응답 시 보내는 헤더, 허용된 출처를 명시한다.
• 유효성 검사: 브라우저는 자신이 보낸 Origin 헤더와 서버가 응답한 Access-Control-Allow-Origin 헤더를 비교하여 요청이 허용된 출처에서 왔는지 확인한다.

OPTIONS /some-resource HTTP/1.1
Host: example.com
Origin: https://sanghyun.com

 

서버는 'Access-Control-Allow-Origin' 헤더를 통해 https://sanghyun.com 에서의 요청만을 허용할 수 있다.

 

2. 허용된 Method 설정

• Access-Control-Request-Method(브라우저): 브라우저가 Preflight Request(사전 요청)를 통해 서버에 사용하고자 하는 HTTP 메소드(GET, POST, PUT 등)를 알린다.
• Access-Control-Allow-Methods(서버): 서버가 응답 시 허용된 HTTP 메소드를 명시한다.
• 유효성 검사: 브라우저는 자신이 보내려는 메소드가 서버에서 허용된 메소드인지 확인한다.

OPTIONS /some-resource HTTP/1.1
Host: example.com
Origin: https://sanghyun.com
Access-Control-Request-Method: PUT

 

서버는 'Access-Control-Allow-Methods' 헤더를 통해 'PUT' 메소드가 허용되는지 응답한다.

 

3. 허용된 Header 설정

• Access-Control-Request-Headers(브라우저): 브라우저가 Preflight Request에서 서버에 전송하려는 헤더 목록을 포함한다.
• Access-Control-Allow-Headers(서버): 서버가 응답 시 허용된 헤더 목록을 명시한다.
• 유효성 검사: 브라우저는 자신이 보내려는 헤더가 서버에서 허용된 헤더인지 확인한다.

OPTIONS /some-resource HTTP/1.1
Host: example.com
Origin: https://sanghyun.com
Access-Control-Request-Headers: X-Custom-Header

 

서버는 'Access-Control-Allow-Headers'헤더를 통해 'X-Custom-Header'가 허용되는지를 응답한다.

 

자격증명 Header 허용

• 자격증명: Cookie, Authorization Headers 또는 TLS Client 인증 정보 등
• 브라우저 측 설정: credentials: "include" (최신 자바스크립트 fetch API) 또는 allowCredentials=true (XMLHttpsRequest)옵션을 통해 자격증명 정보를 포함하도록 요청할 수 있다.
• 서버 측 설정: Access-Control-Allow-Credentials = true로 설정하여, 서버가 자격증명이 포함된 요청을 허용한다. 이 경우 Access-Control-Allow-Origin 헤더에서 와일드카드 '*' 를 사용할 수 없다는 제약이 있다.

 

---

CORS 검증을 위한 요청 유형

1. Simple Request: 서버 상태 조회

• Methods: GET, HEAD와 같은 서버 상태를 조회하는 요청에 사용된다.
• 절차:
  1. 브라우저가 서버에게 원 요청을 보낸다.
  2. 서버는 응답과 함께 CORS 헤더를 전송한다.
  3. 브라우저는 서버의 CORS 헤더를 검토하여 요청이 허용된 출처에서 온 것인지 확인하고, 그렇지 않으면 응답을 폐기한다.

GET /some-resource HTTP/1.1
Host: example.com
Origin: https://sanghyun.com

 

서버는 Access-Control-Allow-Origin: https://sanghyun.com 헤더를 포함한 응답을 반환한다 

 

2. Preflight Request: 서버 상태 변경

• Methods: POST, PATCH, PUT과 같은 서버 상태를 변경하는 요청 또는 GET, HEAD에 커스텀 헤더가 포함된 요청에 사용된다.
• 절차:
  1. 브라우저가 서버에게 사전 요청(OPTIONS)을 보내, 서버가 허용하는 Origin, Method, Header를 확인한다.
  2. 서버는 CORS 헤더만 포함된 응답을 보낸다.
  3. 브라우저는 응답된 CORS 헤더를 검토하여 요청이 허용된 경우에만 실제 원 요청을 전송한다.

OPTIONS /some-resource HTTP/1.1
Host: example.com
Origin: https://sanghyun.com
Access-Control-Request-Method: POST
Access-Control-Request-Headers: Content-Type

 

서버는 Access-Control-Allow-Mothods: POST 와 Access-Control-Allow-Headers: Content-Type 헤더를 포함한 응답을 반환한다.

 

 

---

ℹ️참고

[ASAC 6기 강의자료]