y-log

HTTP란

Hyper Text Transfer Protocol
www상에서 정보를 주고받는 프로토콜

클라이언트인 웹 브라우저가 서버에 HTTP를 통해 웹페이지나 이미지 정보를 요청하면, 서버는 이 요청에 응답하여 요구하는 정보를 제공하게 된다.

HTTP는 웹 브라우저Client와 서버Server간의 웹페이지 같은 자원을 주고 받을 때 쓰는 통신 규약이다.

HTTP는 텍스트 교환이라 (html페이지도 텍스트!) 누군가 네트워크에서 신호를 가로채 본다면 내용이 노출될 것이다.

이와같은 보안상의 문제를 해결해주는 프로토콜이 HTTPS이다.

" HTTP의 문제점 "

• HTTP 는 평문 통신이기 때문에 도청이 가능하다.
• 통신 상대를 확인하지 않기 때문에 위장이 가능하다.
• 완전성을 증명할 수 없기 때문에 변조가 가능하다.

* 위와 같은 문제점은 암호화하지 않은 다른 프로토콜에도 공통되는 문제점이다.

1. TCP/IP 는 도청 가능한 네트워크...

 TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있다. 패킷을 수집하는 것 만으로도 도청할 수 있다. 따라서 암호화하여 통신해야한다.

보안 방법

1. 통신 자체를 암호화
SSL 또는 TLS라는 다른 프로토콜을 조합함으로써  HTTP의 통신 내용을 암호화할 수 있다.  SSL을 조합한 HTTP를 바로 HTTPS(HTTP over SSL)라고 부른다.

2. 콘텐츠를 암호화
말 그대로 HTTP를 사용해서 운반하는 내용인 HTTP 메세지에 포함되는 콘텐츠만 암호화하는 것이다. 암호화해서 전송하면 받은 측에서는 그 암호를 해독하여 출력하는 처리가 필요하다.  

2. 통신 상대를 확인하지 않기 때문에 위장이 가능...

HTTP 에 의한 통신에는 상대가 누구인지 확인하는 처리는 없기 때문에 누구든지 리퀘스트를 보낼 수 있다. IP 주소나 포트 등에서 그 웹 서버에 액세스 제한이 없는 경우 리퀘스트가 오면 상대가 누구든지 무언가의 리스폰스를 반환한다. 이러한 특징은 여러 문제점을 유발한다.

1. 리퀘스트를 보낸 곳의 웹 서버가 원래 의도한 리스폰스를 보내야 하는 웹 서버인지를 확인할 수 없다.
2. 리스폰스를 반환한 곳의 클라이언트가 원래 의도한 리퀘스트를 보낸 클라이언트인지를 확인할 수 없다.
3. 통신하고 있는 상대가 접근이 허가된 상대인지를 확인할 수 없다.
4. 어디에서 누가 리퀘스트 했는지 확인할 수 없다.
5. 의미없는 리퀘스트도 수신한다. —> DoS 공격을 방지할 수 없다.

보완 방법

윗 상자에서 말한 SSL 로 상대를 확인할 수 있다. 
SSL은 상대를 확인하는 수단으로 증명서를 제공하고 있다. 증명서는 신뢰할 수 있는 제 3자 기관에 의해 발행되는 것이기 때문에 서버나 클라이언트가 실재하는 사실을 증명한다. 이 증명서를 이용함으로써 통신 상대가 내가 통신하고자 하는 서버임을 나타내고 이용자는 개인 정보 누성 등의 위험성이 줄어들게 된다.
한 가지 이점을 더 꼽자면, 클라이언트는 이증명서로 본인 확인을 하고 웹 사이트 인증에서도 이용할 수 있다.

3. 완전성을 증명할 수 없기 때문에 변조가 가능하다

여기서 완전성이란 정보의 정확성 을 의미한다. 서버 또는 클라이언트에서 수신한 내용이 송신측에서 보낸 내용과 일치한다라는 것을 보장할 수 없는 것이다. 리퀘스트나 리스폰스가 발신된 후에 상대가 수신하는 사이에 누군가에 의해 변조되더라도 이 사실을 알 수 없다. 이와 같이 공격자가 도중에 리퀘스트나 리스폰스를 빼앗아 변조하는 공격을 중간자 공격(Man-in-the-Middle)이라고 부른다.

보완 방법

MD5, SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재하지만 확실히 확인할 수 있는 것은 아니다. 확실히 방지하기에는 HTTPS를 사용해야 한다. SSL 에는 인증이나 암호화, 그리고 다이제스트 기능을 제공하고 있다.

HTTPS

HTTP에 암호화와 인증과 완전성 보호를 더한 HTTPS

HTTPS는 SSL 의 껍질을 덮어쓴 HTTP 라고 할 수 있다. 즉, HTTPS 는 새로운 애플리케이션 계층의 프로토콜이 아니라는 것이다. HTTP 통신하는 소켓 부분을 SSL(Secure Socket Layer) or TLS(Transport Layer Security)라는 프로토콜로 대체하는 것 뿐이다. HTTP 는 원래 TCP 와 직접 통신했지만, HTTPS 에서 HTTP 는 SSL 과 통신하고 SSL 이 TCP 와 통신 하게 된다. SSL 을 사용한 HTTPS 는 암호화와 증명서, 안전성 보호를 이용할 수 있게 된다.

HTTPS 의 SSL 에서는 공통키 암호화 방식과 공개키 암호화 방식을 혼합한 하이브리드 암호 시스템을 사용한다. 공통키를 공개키 암호화 방식으로 교환한 다음에 다음부터의 통신은 공통키 암호를 사용하는 방식이다.

모든 웹 페이지에서 HTTPS를 사용해도 될까?

평문 통신에 비해서 암호화 통신은 CPU나 메모리 등 리소스를 더 많이 요구한다. 통신할 때마다 암호화를 하면 추가적인 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 리퀘스트의 수가 상대적으로 줄어들게 된다.
하지만 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며, 새로운 표준인 HTTP 2.0을 함께 이용한다면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다. 따라서 웹은 과거의 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용하는 방식에서 현재 모든 웹 페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있다.

Reference.

• https://jeong-pro.tistory.com/89

HTTP

웹 상에서 클라이언트와 서버 간에 데이터를 주고 받을 수 있는 프로토콜인
HTTP 메소드에는 크게 2가지 방식이 있는데
그것이 GET 방식과 POST 방식

---

GET 

'가져오다'
어떠한 정보를 가져와서 조회하기 위해서 사용되는 방식

• URL에 변수(데이터)를 포함시켜 요청
• 데이터를 header에 포함시켜 전송
• URL에 데이터가 노출되어 보안에 취약
• 캐싱 가능

GET은 URL끝에 ?와 함께 이름과 값으로 쌍을 이루는 요청 파라미터(쿼리 스트링)를 통해 필요한 데이터를 서버로 전송한다. 쿼리 스트링이 여러개일 경우 &로 연결해준다.

불필요한 요청을 제한하기 위해 요청이 캐시될 수 있다.

ex. js, css와 같은 데이터 양이 크고 변경될 일이 적은 정적 컨텐츠

정적 컨텐츠를 요청하고 나면 브라우저에서는 요청을 캐시한다. 동일 요청 발생시 서버로 요청을 보내지 않고 캐시된 데이터를 사용한다.

프론트앤드 개발시 정적 컨텐츠가 캐시되어 컨텐츠를 변경해도 적용되지 않는 경우 브라우저의 캐시를 지워주면 해결된다.

POST

'제출하다'
데이터를 서버로 제출하여 추가 또는 수정하기 위해 사용하는 방식, 작업 수행 시 사용됨

• URL에 변수(데이터)를 노출하지 않고 요청
• 데이터를 body에 포함시켜 전송
• URL에 데이터가 노출되지 않아서 기본 보안이 되어있음
• 캐싱 불가능

GET과 달리 http 메세지의 길이 제한이 없는 body에 담아서 보내기 때문에 대용량 데이터를 전송할 수 있다. 

GET보다는 보안성이 높지만 크롬 개발자 도구나 Fiddler와 같은 툴로 요청 내용 확인이 가능하기 때문에 민감 데이터 전송시에는 반드시 암호화를 해야한다.

POST는 요청 헤더의 content-type에 요청 데이터 타입을 표시해야 한다.

표시하지 않으면 서버는 내용이나 URL에 포함된 리소스 확장자명 등으로 데이터 타입을 유추하고, 알 수 없는 경우엔 aplication/octet-stream로 요청을 처리함

GET과 POST와 멱등성

멱등 - 동일한 연산을 여러 번 수행하더라도 동일한 결과가 나타나는 것

GET은 서버에게 동일한 요청을 여러번 전송하더라도 동일한 응답이 돌아와야하는 멱등성을 갖도록 설계되어있다.

서버의 데이터나 상태를 변경시키지 않아야 멱등성을 갖게 되기 때문에 GET은 주로 조회시 사용되는 것이다.

POST는 서버에게 동일한 요청을 여러 번 전송하더라도 응답은 다 다를 수 있다.

따라서 서버의 상태나 데이터를 변경시킬 때 사용이 된다.

<참고>

https://mangkyu.tistory.com/17 https://hongsii.github.io/2017/08/02/what-is-the-difference-get-and-post/