[네트워크]HTTP + 보안 1

#.HTTP란

HTTP(Hyper Text Transfer Protocol)란 브라우저와 서버가 통신할 수 있도록 만들어주는 여러 프로토콜 중 하나로, 인터넷에서 웹 브라우저와 웹 서버 사이에 HTML 문서(데이터)를 주고 받는데 쓰이는 통신 프로토콜이다.

일반적으로 전송 계층 프로토콜로 TCP를 사용하고, 네트워크 계층 프로토콜로 IP를 사용한다. TCP/IP에서는 IP 주소를 사용해서 통신할 컴퓨터를 결정하고, 포트 번호를 사용해서 해당 컴퓨터의 어떤 프로그램과 통신할지를 결정한다. (HTTP에서는 기본적으로 80번 포트를 사용한다.)

 

HTTP 동작 방식

HTTP는 서버-클라이언트 모델을 따른다.

클라이언트는 서버로 요청(Request)을 전송하고, 서버는 요청에 대한 응답(Response)을 보냄으로써 통신한다.

1. connect : 클라이언트가 원하는 서버와 연결을 맺는다. 이 때, TCP를 이용하여 연결을 맺는다. TCP 연결은 요청을 보내거나 받는데 사용하며, 새 연결을 시도하거나 기존 연결을 재사용할 수 있다.
2. request : 클라이언트가 서버에 요청한다. 클라이언트의 요청에 대한 정보를 HTTP 메시지로 전송한다.
3. response : 서버가 요청에 대한 응답 결과를 클라이언트에게 보낸다.
4. close : 응답이 끝나면 서버와 클라이언트의 연결을 끊는다. (다른 요청을 위해 재사용할 수 있다)

 

HTTP의 특성

1. 비연결성(Connectionless)
   1. 클라이언트와 서버가 한 번 연결을 맺은 후 클라이언트의 요청에 대한 서버가 응답을 마치면 연결을 끊는다. 서버는 다수의 클라이언트와 연결을 지속 시 많은 리소스가 발생하게 된다. 따라서 서버가 응답을 마친 후 연결을 끊어 연결 유지에 필요한 리소스를 줄이고 더 많은 연결을 할 수 있게 된다.
   2. 하지만 서버가 클라이언트를 기억하지 못해 모든 요청에 대해 매번 새로운 연결을 해야 하는 일이 발생한다. 이렇게 되면 연결 해제에 대한 오버헤드가 많이 발생하게 되는데, 이를 해결하기 위해 Keep Alive를 사용한다. 클라이언트와 서버 사이 상대방의 안부를 묻기 위해 packet을 주기적으로 보낸다. 만약 packet에 대해 반응이 없으면 접속도 끊는다. 이 방법 역시 주기적으로 패킷을 보내며 확인해야 하기 때문에 서버가 바쁜 상황에서도 process 수가 늘어나고 keep alive를 유지하기 위한 메모리가 많아져 주의해야 한다.

#.HTTP 메서드

HTTP에서 요청을 전송할 때, HTTP Method를 포함하여 전송한다.

HTTP Method는 어떠한 기능을 수행할 것인지에 대한 부가적인 설명을 하는 역할을 한다.

클라이언트에서 서버가 수행하기 원하는 동작을 말한다.

GET	- 특정 리소스를 검색 및 취득 - 요청 시 전송하는 데이터를 URI의 Query Parameters 형태로 포함
POST	- 새로운 리소스를 생성 - 서버측의 상태 변화를 유발 - 요청 시 전송하는 데이터를 HTTP Body에 포함
PUT	- 리소스의 내용 수정 및 생성
DELETE	- 리소스 삭제
PATCH	- 리소스를 부분적으로 수정
TRACE	- 요청 리소스가 수신되는 경로를 확인
OPTION	- 서버측이 제공하는 HTTP Method의 종류에 대해 질의할 때 사용 - 응답의 Allow 헤더에 사용가능한 HTTP Method의 종류가 포함됨
HEAD	- 특정 리소스를 GET 메서드로 요청했을 때 반환되는 헤더를 요청할 때 사용 - HTTP 헤더만을 원할 때 사용하므로 응답에 HTTP Body가 없음
CONNECT	- 요청한 리소스에 대한 양방향 연결을 시작하기 위해 사용 - 원하는 목저지와의 TCP 연결을 HTTP 프록시 서버에 요청

 

#.GET과 POST의 차이

GET과 POST는 HTTP 포로토콜을 이용하여 클라이언트에서 서버로 무엇인가를 요청할 때 사용한다.

 

GET

GET은 클라이언트에서 서버로 어떠한 리소스를 요청하기 위해 사용되는 메서드이다.

GET 방식은 요청하는 데이터가 HTTP Request Message의 Header 부분에 URL에 담겨서 전송된다.

URL 끝에 "?"를 붙이고 변수명1=값1&변수명2=값2.. 형식으로 파라미터를 작성하여 데이터를 전송한다.

이러한 방식은 URL이라는 공간에 담겨가기 때문에 전송할 수 있는 데이터의 크기가 제한적이다.

또, 보안이 필요한 데이터에 대해서는 데이터가 그대로 노출되는 문제가 있다.

 

POST

POST는 클라이언트에서 서버로 리소스를 생성하거나 변경을 위해 데이터를 전송할 때 사용하는 메서드이다.

POST 방식의 요청은 HTTP Request Message의 Body 부분에 데이터가 담겨서 전송된다.

HTTP Message의 Body는 길이의 제한이 없고, GET 방식에 비해 보안적인 측면에서 낫다.

하지만, 데이터를 암호화하지 않는 이상 비슷하다고 볼 수 있다.

 

GET과 POST의 차이점

사용 목적

GET은 데이터를 가져오는 것이다. 서버에 어떤 데이터를 가져와서 보여주는 용도이지, 서버의 값이나 상태를 변경하지 않는다.

반면, POST는 서버의 값이나 상태를 변경하거나 추가하기 위해 사용된다.

 

캐싱

GET은 캐시가 가능하다. GET을 통해 서버에 리소스를 요청할 때, 웹 캐시가 요청을 가로채 서버로부터 리소스를 다시 다운로드하는 대신 리소스의 복사본을 반환한다. HTTP 헤더에서 cache-control 헤더를 통해 캐시 옵션을 지정할 수 있다.

반면, POST는 캐시되지 않는다. 때문에 POST 방식으로 요청해야 할 것을 데이터의 크기가 작고 보안적인 문제가 없다는 이유로 GET 방식으로 요청한다면 기존의 캐싱되었던 데이터가 응답될 수 있다.

 

멱등성(Idempotent)

GET은 멱등이고, POST는 멱등이 아니다.

멱등의 사전적 정의는 연산을 여러 번 적용하더라도 결과가 달라지지 않는 성질을 의미한다.

GET은 리소스를 조회한다는 점에서 여러 번 요청하더라도 응답이 똑같다.

반면, POST는 리소스를 새로 생성하거나 변경할 때 사용되기 때문에 멱등이 아니다.

(POST 요청이 발생하면 서버가 변경될 수 있다.)

 

[멱등성이란]

멱등성 - MDN Web Docs 용어 사전: 웹 용어 정의 | MDN

 

 

 

#.HTTP 상태 코드

HTTP를 사용할 때, 요청에 대한 응답의 결과는 HTTP 상태 코드를 통해 전달된다.

요청에 대한 처리가 성공했는지, 실패했는지 등의 결과를 HTTP 상태 코드를 통해 알려준다.

 

1xx (정보)

서버가 요청을 받았으며, 서버에 연결된 클라이언트는 작업을 계속 진행하라는 의미

 

2xx (성공)

요청이 성공적 수행됨.

200 OK - 요청에 성공했으며, 요청에 대한 응답을 반환

201 Created - 요청에 성공했으며, 그 결과 새로운 리소스가 생성되었다.

 

3xx (리다이렉션)

요청 완료를 위해 추가 작업 조치가 필요하다.

 

4xx (클라이언트 오류)

요청의 문법이 잘못되었거나, 요청을 처리할 수 없다.

400 bad request - 잘못된 문법으로 인해 서버가 요청을 이해할 수 없음

401 unauthrized - 클라이언트의 인증이 필요하다.

403 forbidden - 클라이언트는 콘텐츠에 접근할 권리가 없다. 401과 다른점은 서버가 클라이언트가 누구인지는 알고 있다.

404 not found - 서버는 요청받은 리소스를 찾을 수 없다.

 

5xx (서버 오류)

서버가 명백히 유효한 요청에 대한 충족을 실패했다.

[HTTP 상태 코드]

HTTP 상태 코드 - HTTP | MDN

 

#.HTTP vs HTTPS

HTTP에는 문제점이 있다.

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

각 문제점에 대해 자세히 알아본다.

1. HTTP는 도청이 가능하다.

HTTP는 TCP/IP 위에서 동작하며, TCP/IP 구조의 통신은 전부 통신 경로 상에서 엿볼 수 있다.

패킷을 수집하는 것만으로도 도청할 수 있다.

평문으로 통신하는 경우 메시지의 의미를 파악할 수 있기 때문에 암호화하여 통신해야 한다.

보안 방법

1. 통신 자체를 암호화한다.
2. SSL(Secure Socket Layer) or TLS(Transport Layer Security)라는 프로토콜을 조합함으로써 HTTP의 통신 내용을 암호화할 수 있다. SSL을 조합한 HTTP가 HTTPS이다.
3. 콘텐츠를 암호화한다. HTTP를 사용해서 운반하는 내용인 HTTP 메시지에 포함되는 콘텐츠만 암호화하는 것이다. 암호화해서 전송하면 받는 측에서는 해독하여 출력하는 처리가 필요하다.

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

HTTP에 의한 통신에는 상대가 누구인지 확인하는 처리가 없기 때문에 누구든지 request를 보낼 수 있다.

IP 주소나 포트 등에서 웹 서버에 엑세스 제한이 없는 경우 request가 오면 누구든지 response를 반환한다.

이러한 특징은 여러 문제점을 유발한다.

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

보안 방법

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

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

여기서 완전성이란 정보의 정확성을 의미한다.

서버 또는 클라이언트에서 수신한 내용이 송신 측에서 보낸 내용과 일치한다라는 것을 보장할 수 없는 것이다.

request나 response가 발신된 후에 상대가 수신하는 사이에 누군가에 의해 변조되더라도 이 사실을 알 수 없다. 이와 같은 공격자가 도중에 request나 response를 빼앗아 변조하는 공격을 중간자 공격(Man-in-the-Middle)이라고 부른다.

보안 방법

MD5, SHA-1 등의 해시 값을 확인하는 방법과 파일의 디지털 서명을 확인하는 방법이 존재하지만, 확실히 확인할 수 있는 것은 아니다. 확실히 방지하기 위해서는 HTTPS를 사용해야 한다.

SSL에는 인증이나 암호화, 다이제스트 기능을 제공하고 있다.

HTTPS

HTTPS는 인터넷상에서 정보를 암호화하는 SSL 프로토콜을 사용해 클라이언트와 서버가 자원을 주고받을 때 쓰는 통신 규약이다. HTTP에 암호화와 인증, 그리고 완전성 보호를 더한 것이다.

HTTPS는 새로운 애플리케이션 계층의 프로토콜이 아닌, HTTP 통신하는 소켓 부분을 SSL 또는 TLS 프로토콜로 대체한 것이다. HTTP는 원래 TCP와 직접 통신했지만, HTTPS에서는 HTTP는 SSL과 통신하고 SSL이 TCP와 통신한다.

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

HTTPS는 평문 통신에 비해 암호화 과정을 거치기 때문에 CPU나 메모리 등 리소스를 더 많이 요구한다. 통신할 때마다 암호화를 거치면 추가적인 리소스를 소비하기 때문에 서버 한 대당 처리할 수 있는 request의 수가 상대적으로 줄어들게 된다.

하지만, 최근에는 하드웨어의 발달로 인해 HTTPS를 사용하더라도 속도 저하가 거의 일어나지 않으며, 새로운 표준인 HTTP 2.0을 함께 이용하면 오히려 HTTPS가 HTTP보다 더 빠르게 동작한다고 한다.

따라서 웹은 과거의 민감한 정보를 다룰 때만 HTTPS에 의한 암호화 통신을 사용하는 방식에서 현재 모든 웹 페이지에서 HTTPS를 적용하는 방향으로 바뀌어가고 있다.

 

#.DNS

도메인(Domain)이란?

도메인이란 원래 ip주소 대신 기억하기 쉬운, 사람이 읽은 수 있는 이름으로 사용하는 주소이다.

예를 들어, 192.168.1.2라는 ip 주소를 www.이름.com이라는 도메인 주소로 나타내는 것이다.

DNS(Domain Name System)이란?

위에서 말했듯이, 웹 사이트에 접속할 때 외우기 어려운 IP 주소 대신 도메인 이름을 사용한다.

도메인 이름을 사용했을 때, 입력한 도메인을 실제 네트워크 상에서 사용하는 IP 주소로 바꾸는 과정이 필요하다. 이러한 과정을 DNS라고 한다.

DNS 작동 방식

1. 주소.com 입력
2. 주소.com을 가지고 있는 네임 서버에 접속
3. IP 주소를 확인 및 전달
4. IP 주소를 가진 서버로 접속
5. 연결된 브라우저 실행

#.Session Hijacking

세션은 클라이언트와 컴퓨터 간의 활성화된 상태를 말한다.

세션 하이재킹은 시스템간의 연결이 활성화된 상태를 가로채는 것을 뜻한다.

 

TCP 세션 하이재킹은 TCP의 고유한 취약점을 이용해 정상적인 접속을 빼앗는 방법이다.

TCP는 클라이언트와 서버 통신을 할 때, 패킷의 연속성을 보장하기 위해 시퀀스 넘버를 사용한다.

 

이 시퀀스 넘버가 잘못되면 이를 바로잡기 위한 작업을 수행하는데, TCP 세션 하이재킹은 서버와 클라이언트에 각각 잘못된 시퀀스 넘버를 위조해서 연결된 세션에 잠시 혼란을 준 뒤, 자신이 끼어들어 가는 방식이다.

 

HTTP 세션 하이재킹은 이미 인증이 완료된 타인의 세션 ID를 탈취하여 웹 서버에 요청을 보내는 방식이다.

 

해당 공격이 성공하려면 세션 ID 값이 유효해야 하므로 사용자가 로그인 한 상태에서 공격이 이루어져야 하거나 세션 ID 값의 유지 시간이 긴 경우라는 제한 사항이 필요하다. 즉, 세션 ID를 통해 사용자와 서버의 세션이 활성화된 상태를 가로채는 방식이다.

[세션 하이재킹]

Session Hijacking

 

CORS

CORS(Cross Origin Resource Sharing, 교차 출처 리소스 공유)란 HTTP 헤더를 사용하여 한 출처(origin)에서 실행중인 웹 어플리케이션이 다른 출처(cross-origin)의 자원에 접근할 수 있는 권한을 부여하도록 브라우저에 알려주는 정책이다.

출처(Origin)

출처에 대해 알아보기 전 URL 구조에 대해 살펴본다.

출처란 URL 구조에서 살펴본 프로토콜, 호스트 주소, 포트번호를 합친 것을 말한다. 따라서 이 중 하나라도 다르다면 다른 출처인 것이다.

 

SOP와 CORS

SOP(Same Origin Policy, 동일 출처 정책)란 다른 출처로 요청을 보낼 수 없도록 금지하는 브라우저의 기본적인 보안 정책이다. 즉, 동일한 출처로만 요청을 보낼 수 있게 하는 것이다. SOP를 따른다면 외부 리소스를 가져오지 못해 불편하지만, XSS나 XSRF 등의 보안 취약점을 노린 공격을 방어할 수 있다.

하지만, 대규모 웹 서비스가 늘어나게 되면서 불편함을 느끼게 되었고, W3C(월드 와이드 웹을 위한 표준을 개발하고 장려하는 조직)는 조금 더 안전하게 다른 출처로의 요청을 보낼 수 있도록 CORS라는 정책을 내놓았다. 즉, CORS는 SOP에 의해 막힌 다른 출처로의 요청을 풀어주는 정책이다.

 

[CORS 동작 방식 및 해결방안(In Spring Boot)]

CORS (Cross Origin Resource Sharing)