HTTP vs HTTPS
HTTP
HTTP는 서버 / 클라이언트 모델을 따라 데이터를 주고 받기 위한 가장 기초적인 프로토콜이다.
HTTP는 인터넷에서 하이퍼텍스트를 교환하기 위한 통신 규약으로, 80번 포트를 사용하고 있다.
HTTP Request 구조
HTTP는 애플리케이션 레벨의 프로토콜로 TCP/IP 위에서 작동한다. HTTP는 상태를 가지고 있지 않는 Stateless 프로토콜이며, startLine에는 Method, Path, Version, Headers, Body 등으로 구성된다.
HTTP 문제점
- 암호화 기능 없음
단순 text형식으로 주고받기 때문에, 중간에서 누군가가 신호를 가로챈다면 내용이 그대로 노출된다. - 신뢰할 수 있는 사이트인지 확인 불가
통신하려는 사이트를 따로 확인하는 작업이 없어 다른 사이트가 통신하려는 사이트로 위장 가능 - 통신 내용 변경 가능
요청을 보낸 곳과 받은 곳의 리소스가 정확히 일치하는지 확인할 수 없다.
누군가가 중간에 데이터를 악의적으로 변조한다면 정확한 데이터를 주고받을 수 없게된
HTTPS
HTTP에 데이터 암호화가 추가된 프로토콜이다. HTTPS는 HTTP와 다르게 443번 포트를 사용하며, 네트워크 상에서 중간에 제3자가 정보를 볼 수 없도록 공개키 암호화를 지원하고 있다.
HTTPS는 HTTP 요청을 SSL 혹은 TLS라는 알고리즘을 이용해, HTTP 통신을 하는 과정에서 내용을 암호화하여 데이터를 전송하는 방법이다.
정리
HTTP는 암호화가 추가되지 않았기 때문에 보안에 취약한 반면,
HTTPS는 안전하게 데이터를 주고받을 수 있다.
하지만 HTTPS를 이용하면 암호화/복호화의 과정이 필요하기 때문에 HTTP보다 속도가 느리다.
(오늘날에는 거의 차이를 못느낄 정도)
‘HTTP vs HTTPS 차이’는 바로 SSL 인증서
HTTPS는 인증서를 발급하고 유지하기 위한 추가 비용이 발생한다.
개인 정보와 같은 민감한 데이터를 주고 받아야 한다면 HTTPS를 이용해야 하지만,
단순한 정보 조회 등만을 처리하고 있다면 HTTP를 이용하면 된다.
CORS
예전에는 웹사이트에서 다른 서버로 요청을 날린다 하면 개인정보 유출, 피싱 사이트와 같이 보안상 악의적인 행동을 하는 걸로 의심을 했다. 그랬기 때문에 웹브라우저에서는 같은 도메인이 아니면
요청 자체를 SOP Same-Origin Policy를 이용해 막는 선택을 하였다.
그때 개발자들은 JSONP방식을 이용해 이를 우회하는 방법으로 이를 회피했다.
이걸 합의된 출처들간에 합법적으로 허용해주기 위해 기준을 충족시키면 리소스 공유가 되도록 만들어진 CORS정책이 생겼다.
서로 다른 도메인의 리소스 요청을 보내고 받기 위해서는 웹 프론트엔드와 서버에서 특정한 작업을 해주어야한다.
postman이나 백엔드 http 요청은 되는데 브라우저 내에서 하면 CORS에러가 발생함
SOP
한 origin으로부터 로드된 document 또는 script가 다른 origin의 리소스와 상호작용 할 수 있는 방법을 제한하는 보안 메커니즘 잠재적으로 해로울 수 있는 문서를 분리함으로써 공격받을 수 있는 경로를 줄여줍니다.
CORS에 대한 기본적인 내용
CORS 는 Cross-Origin Resource Sharing 의 약자로 HTTP 헤더에 기반하는 메커니즘이다.
한 출처에서 실행 중인 웹 애플리케이션이 다른 출처의 선택한 자원에 접근할 수 있는
권한을 부여하도록 브라우저에 알려주는 체제이다.
동작방식
웹 애플리케이션을 A라고 하고 다른 출처를 B라고 하면,
A가 B가 가진 자원을 사용하겠다고 요청을 하고,
B는 본인이 정해놓은 허용 기준에 A가 맞는다면 이를 사용할 수 있도록 권한을 주어 허용해주며,
이를 사용하기위한 약간의 규칙을 알려준다는 과정이라고 보면 쉽다.
요청 방법에는 3가지가 있다.
1. Simple requests(단순 요청)
2. Preflighted requests(프리플라이트 요청)
3. Requests with credentials(인증정보를 포함한 요청)
Simple requests - 단순요청
일부요청은 preflight방식으로 요청하지 않는다.
Prefight Request 이 외의 방식으로 요청하는 것을 Simple Request 방식이라고 하는데, 브라우저는 요청을 분석하여 아래 와 같은 조건을 충족할 때 Simple Request 방식으로 요청한다.
- HTTP Method가 GET, POST ,HEAD 이 셋 중에 하나로 요청한 경DN
- Fetch 표준 정책에서 정의한 Forbidden Header Name 이라는 헤더 목록
(클라에서 자동으로 넣음)과 CORS-safelisted request header 라는 헤더 목록 이외에 다른 커스텀 헤더,
권한과 관련된 헤더가 없는 경우 - HTTP Method가 POST인 경우 Content-Type 헤더를 수동으로 지정할 수 있는데,
application/x-www-form-urlencoded, multipart/form-data, text/plain 이 세 가지 값에 포함되는 경우
Preflighted Requests - 프리플라이트 요청
Preflighted Request는 가장 먼저 HTTP Request Method 중 하나인 OPTION 메소드를 Cross-Origin으로 보내고(Preflight), 응답 받은 헤더 정보를 통해서 메인 요청을 보낼 수 있는지 판단하는 방식이다.
Authorization과 같은 유저 정보와 관련된 헤더는 브라우저로 하여금 Preflight Request방식으로 요청하도록 유도한다.
Requests with credentials - 인증정보를 포함한 요청
기본적으로 CORS 정책상 XmlHttpRequest 혹은 Fetch API를 사용하여 외부 서버에 요청을 보낼 때
쿠키 정보나 HTTP Authentication 정보는 보내지 않는 것이 원칙이다.
그러나 특정 플래그 값을 이용해서 외부 서버에 쿠키 혹은 HTTP Authentication 정보를 보낼 수 있다.
same-origin이란 scheme(프로토콜), host(도메인), 포트가 같다는 말이며, 이 3가지 중 하나라도 다르면 cross-origin이다.
