[정보보안기사] HTTP 개념

1. HTTP 

웹 상에서 클라이언트와 서버간에 통신을 위해 개발된 프로토콜이고 상태정보를 유지하지 않는다.

상태정보를 유지하기 위해서 클라이언트 기술인 쿠키 또는 서버 기술인 세션을 활용한다.

 

1) HTTP 1.0, 1.1 개념

HTTP 1.0

비 영속적 연결(end-of-file)

많은 클라이언트의 요청을 처리하기 위해 HTTP 요청에 대한 서버의 HTTP 응답 이후에 TCP연결을 바로 종료하는 구조이다.

이는 서버 입장에서 통신을 위한 다수의 TCP 연결 설정 및 종료에 대한 부하가 발생한다.

 

HTTP 1.1

Connection 헤더에 Keep-Alive 옵션이 추가되어 영속적 연결을 유지한다.

TCP 연결 설정 및 종료에 대한 부하를 줄일 수 있다.

 

Keep-Alive

일정시간 지속시키는 옵션

timeout:15 → 15초동안 유지

max:100 → 최대 100건까지 저장

 

 

 

Apache KeeAlive 설정 방법

파일명: httpd.conf

KeepAlive On

MaxKeepAliveRequest 100

KeepAliveTimeout 15

2. 쿠키 (Cookie)

1) 개념

개별 클라이언트 상태정보를 HTTP 요청/응답 헤더에 담아서 전달하는 작은 데이터이다.

클라이언트에 저장되며 웹사이트 마지막 방문 시간, 방문한 페이지 등 다양한 정보를 기록할 수 있다.

 

사용자가 사이트에 방문하면 사용자의 사이트는 쿠키를 만들고 브라우저를 확인하는 ID 번호를 쿠키 파일에 넣어서 사용자의 컴퓨터에 저장한다.

사용자가 사이트를 재 방문할 경우 쿠키 내용을 이용하여 신분 확인을 통해 빠르게 접근이 가능하다.

아이디와 패스워드를 저장한 경우에도 쿠키로 남아있기 때문에 화면이 갱신 되어도 다시 로그인 하지 않아도 된다.

 

영속 쿠키: 클라이언트에 파일 형태로 지속 또는 일정 기간동안 존재하는 쿠키로 설정된 사이트 요청시마다 Cookie 헤더에 쿠키 정보를 담아서 전달한다.

세션 쿠키: 클라이언트 메모리상에 세션이 유지되는 동안 존재하는 쿠키로 세션이 종료되면 소멸된다.

2) 쿠키의 용도

사이트 개인화

사용자의 아이디, 패스워드 뿐만 아니라 성향까지 파악할 수 있다.

 

장바구니 시스템

전자상거래 이용시 사용자가 물건을 고르면 그 내용이 쿠키에 저장된다.

 

웹 사이트 이용방식 추적

사용자의 웹 사이트 사용 방식을 파악해 자주 방문, 자주 방문하지 않는 사이트를 파악한다.

 

광고 마케팅

쿠키를 통하여 리타게팅 광고를 수행한다.

 

3) 쿠키의 구조

4개의 속성과 하나의 데이터를 가지는 구조체이다.

웹브라우저가 웹 서버에 요청할 경우 Cookie 헤더를 사용하고 서버는 응답에 Set-Cookie 헤더를 포함시키는 방식으로 쿠키를 설정한다.

Set-Cookie: name=value;expires=[Date];domain=[Domain];path=[PATH];[secure]

 

유효기간 (Expire): 기본적으로 브라우저가 종료될 때까지 이용할 수 있지만 사용자가 기간을 지정할 수 있다.

패스 (Path): 패스를 지정해 주면 해당 패스 이하에서는 그 쿠키 데이터를 공유할 수 있다.

도메인 (Domain): 도메인 단위에서 쿠키 데이터를 읽고 쓰는 권한을 설정한다.

 

4) 쿠키의 보안 취약점

클라이언트 상태정보를 클라이언트에 저장하고 HTTP 요청 응답 헤더에 담아서 전송하기 때문에 해킹 및 스니핑 공격에 의한 변조와 외부 노출에 취약하다.

그러므로 중요한 정보(개인정보, 신용정보)의 경우 쿠키가 아닌 세션 방식으로 전달해야 한다.

 

XSS 공격 (Cross Site Script Attack)

웹사이트를 구축하기 위해서 HTML + Javascript + JSP,PHP,ASP 등을 구성해야한다.

그 중 Javascript가 사용자의 컴퓨터에서 실행된다는 점을 이용한 공격이다.

게시판에 script문을 삽입하거나 document.setcookie() 를 이용하여 쿠키 값을 유출시킨다.

 

스니핑 (Sniffing) 공격

쿠키 값을암호화 하지 않고 HTTP로 전송했을 경우중간에서 스니핑이 가능하다.

 

공용 PC에서 쿠키값 유출

여러명이 사용하는 경우 한사람이 사용한 뒤 그 다음 사람이 이전 사람의 쿠키 값을 확인할 수 있다.

 

5) HTTP 쿠키관련 보안 속성

Set-Cookie 응답 헤더에 설정한다.

 

HttpOnly 속성

클라이언트에서 스크립트를 통해 해당 쿠키에 접근하는것을 차단해주는 속성이다. 

일반적으로 세션 쿠키를 탈취하기 위한 Cross Site Script 공격에 대비하기 위해서 사용된다.

 

공격 구문: <script> alert(document.cookie)</script>

 

Set-Cookie: JSESSIONID=134958; path=\; HttpOnly

 

PHP HttpOnly 설정 방법

파일명: /etc/php.ini

session.cookie_httponly = 1

 

secure 속성

스크립트를 통해 쿠키에 접근하는것을 차단했다고 하더라도 공격자는 스니핑을 통해 세션 쿠키 정보를 확인할 수 있다.

스니핑을 방지하기 위해 암호화된 HTTPS(TLS/SSL) 통신일 경우에만 쿠키를 전송한다.

쿠키에 대한 기밀성을 보장하기 위한 목적으로 사용된다.

 

Set-Cookie: JSESSIONID=134958; path=\; secure

 

PHP secure 설정 방법

파일명: /etc/php.ini

session.cookie_secure = 1

3. 세션 (Session)

개별 클라이언트 인증과 같은 보안관련 상태 정보를 서버에 저장하는 기술이다.

클라이언트 별로 Session ID를 부여하고 Session 쿠키를 통해 주고 받는다.

 

동작 순서

① 클라이언트에서 요청 시 세션 타임 아웃이 설정된 세션 객체를 생성한다.

② 웹서버에 set-cookie를 통해 서버에서 생성한 세션 ID를 클라이언트에게 전달한다.

③ 크라이언트에서 웹 브라우저 메모리상에 세션 쿠키를 저장한다.

④ 매 요청시마다 Cookie에 세션 ID를 넣어 전달한다.

⑤ 클라이언트에서 웹브라우저 종료 시 세션 쿠키가 소멸된다.

 

 

세션 하이제킹 (Session Hijacking)

해당 동작 방식은 공격자가 세션을 가로채 전송할 수 있기 때문에 HTTP Session Hijacking 공격에 취약하다.

Attacker가 Session ID를 스푸핑한다면 정상 사용자로 위장한 접근이 가능하다. 

설명: https://peemangit.tistory.com/354

4. HTTP 요청/응답 메시지

1) 요청 메시지

구조

Start Line: 요청 메소드<공백>요청 URL<공백>HTTP버전<개행>

Header: 헤더명: 헤더 값<개행>

Blank Line: <개행>Body: 요청 메시지(POST)

 

 

요청 헤더 라인

요청 라인 이후 요청 헤더 라인을 가질 수 있다.

요청 헤더라인 이후 빈 라인을 통해 헤더의 끝을 표시하고 이후 본문 내용 표시한다.

 

Host: 요청의 대생이 되는 서버의 도메인명/호스트명 포트 정보

User-Agent: 요청 클라이언트의 애플리케이션/OS 정보

Content-Type: 동봉되는 데이터 타입

Content-Length: POST 방식을 사용할 경우 데이터 크기

Referer: 현재 요청 URL 정보를 담고 있는 이전 문서의 URL 정보

 

요청 메소드

GET, POST이외에 불필요한 메소드를 허용할 경우 공격자가 이를 악용하여 웹 서버에 파일을 생성하거나 삭제 및 수정이 가능하기 때문에 사용하지 못하도록 설정이 필요하`다.

 

메시지	설명
GET	가장 일반적인 HTTP Request 형태로 웹브라우저에 요청 데이터에 대한 인수를 URL을 통해 전송 각 이름과 값을 &로 결합하며 255자까지 쓸 수 있음
POST	HTTP Body 영역에 소켓을 이용하여 데이터를 전송 URL에 정보가 노출되지 않기 때문에 최소한의 보안성을 만족
HEAD	서버 응답 시 body 부분을 제외하고 header 부분만 응답해주는 메소드 검색엔진에서 사이트 동작여부를  확인할 경우 사용
TRACE	클라이언트에서 수신한 메시지를 서버에서 그대로 반환하는 메소드
OPTION	서버가 지원하는 메소드를 확인하는 목적으로 사용 응답: Allow: GET, HEAD, OPTIONS, TRACE

 

그 이외에도 PUT, DELETE, TRACE, CONNECT 등 다양한 지시자가 존재한다.

 

2) 응답 메시지

상태 라인

구분	응답 코드/ 메시지	설명
1xx : Information	100(Continue)	메시지의 첫부분이 서버에 도착하였고 클라이언트는 계속 요청 가능
2xx : Success	200(OK)	요청 성공
	201(Created)	PUT 메소드에 의해 원격지 서버에 파일이 정상적으로 생성
	202(Accepted)	요청 수락
3xx : Redirection	301(Moved Permanently)	요청을 다른 URL로 항시 전달
	302(Found)	임시 URL로 바꿈
	304 (Not Modified)	요청한 자원이 변경되지 않았으므로 클라이언트 로컬 캐시에 저장된 자원을 이용하라는 의미
4xx : Client Error	400(Bad Request)	요청 메시지의 문법 오류
	401(Unauthorized)	요청한 자원에 대한 인가 인가 필요 (권한 없음)
	403(Forbidden)	접근 차단
	404(Not Found)	페이지 없음
5xx : Server Error	500(Internal Server Error)	메시지 손상과 같은 오류 발생

 

301(Moved Permanently) 요청 응답

Request

GET /index.php

Host: www.peemangit.com 

 

Response

HTTP/1.1 301 Moved Permanently

Location: http://www.peemangit.com/mobile/index.php

 

302(Found) 요청 응답

Request

GET /index.php

Host: www.peemangit.com 

 

Response

HTTP/1.1 302 Found

Location: http://www.peemangit.com/mobile/index.php

 

3.2) 응답 헤더라인

상태라인 이후 응답 헤더 라인을 가진다.

Content-type: 메시지 바디의 데이터 형식

Content-Length: 메시지 바디의 전체 크기(단위: 바이트)

 

응답 헤더라인 이후 빈 라인을 통해 헤더의 끝을 표시하고 이후 본문 내용 표시

 

2. SSL/TLS

CS환경에서 TCP 기반의 Application에 대한 종단간 보안서비스를 제공하기 위해 만들어진 전송계층 보안 프로토콜이다.

대칭키 암호, 공개키 암호, 일방향 해시함수, 메시지 인증코드, 의사난수 생성기, 전자서명을 조합해서 안전한 통신을 수행하고 암호 스위트를 선택하여 보다 강력한 암호화 알고리즘을 사용할 수 있다.

 

1) 통신 과정

프로토콜의 이중 구조이고 URL은 https://로 표기된다.

 

① 개인정보를 보낼 때 개인정보 데이터는 클라이언트의 요청으로 서버에 보내진다.

② 통신 내용을 암호화 해주는 프로토콜로 SSL/TLS를 이용한다. 그리고 그 위에 HTTP를 올린다.

③ HTTP 통신이 암호화되어 MIMT공격을 방지 할 수 있다.

 

2) 보안 서비스

기밀성: DES, RC4와 같은 대칭키 암호화 알고리즘 사용되며, 비밀키는 Handshake Protocol을 통해 생성된다.(3.1확인)

클라이언트와 서버 상호 인증: RSA, DSS, X.509가 사용된다.

메시지 무결성 서비스: 해시 알고리즘을 사용해서 메시지 인증코드를 만들어 메시지에 포함시켜 신뢰성있는 통신 가능

 

3) 암호 스위트(cipher suite)

SSL/TLS에서 사용하는 암호기술에 결함이 발견 되었을 때 부품과 같이 교환할 수 있다.

Clinet-Server 간 같은 암호기술 사용해야 한다.

Null cipher suites는 암호화를 수행하지 않고 테스트와 디버깅 목적으로만 사용되어야 한다.

 

3. SSL Handshake 과정

① 클라이언트의  SSL 버전번호, 암호세팅, 랜덤데이터, 기타 정보, 서버인증서를 클라이언트에게 전송한다.

② 서버의 SSL 버전번호, 암호세팅, 랜덤데이터, 기타 정보, 서버인증서를 클라이언트에게 전송한다.

③ 클라이언트는 Premaster secret 정보를 서버의 공개키로 암호화 하여 전송한다.

④ 서버는 Premaster secret 정보를 이용하여 master secret을 생성하고 세션키를 생성한다.

⑤ 클라이언트는 생성된 세션키를 이용하여 암호통신 수행을 클라이언트에게 알리고 SSL handshake 프로토콜을 완료한다.

⑥ 서버는 생성된 세션키를 이용하여 암호통신 수행을 클라이언트에게 알리고 SSL handshake 프로토콜을 완료한다.

 

 

4. TLS(Transport Layer Security) 프로토콜

5가지: Handshake Protocol, Recode Protocol, ChangeCipherSpec Protocol, Alert Protocol, Heartbeat Protocol

2개의 계층으로 구성 (Handshake Protocol, Recode Protocol)

 

1) Handshake Protocol

암호 집합을 설정하고 키와 보안 매개변수를 제공한다. 또한 필요하다면 클라이언트가 서버에 대해 그리고 서버가 클라이언트에 대해 인증된다.

 

1.1) 메시지 유형

1단계(보안정보 수집): Hello Request → Client Hello → ServerHello

2단계(서버): ServerCertificate → ServerKeyExchange → CertificateRequet → ServerHelloDone

3단계(클라이언트): ClientCertificate → ClientKeyExchange → ClientKeyExchange

4단계(암호정보 교환): ChangeCipherSpec → Finished

 

1.1.1) 1단계 (보안정보 수집)

① Hello Request

서버가 아무때나 보낼 수 있고, 클라이언트에게 협상을 시작하자고 요구하는 메시지이다.(진행중이면 클라이언트에서 무시)

 

② Client Hello 

클라이언트가 서버에 처음으로 연결 시작 또는 Hello Request  메시지에 대한 응답으로 보내는 메시지이다.

클라이언트의  SSL 버전번호, 암호세팅, 랜덤데이터, 기타 정보, 서버인증서를 클라이언트에게 전송한다.

 

random: Replay 공격 방지

session_id: full handshake는 empty를 전송하고 abbreviate Handshake는 재사용하고자하는 세션의 ID를 전송한다.

cipher_suites: 키 교환 알고리즘, 암호 알고리즘, MAC 알고리즘을 포함하는 CipherSuite를 선택한다.

 

③ ServerHello

ClientHello 메시지에 대한 응답으로 ServerHello 메시지를 보낸다.

서버의 SSL 버전번호, 암호세팅, 랜덤데이터, 기타 정보, 서버인증서를 클라이언트에게 전송한다.

 

random: Replay 공격 방지

session_id: 현재 접속중인 세션의 ID이다.(empty 또는 재사용 세션 ID 값)

cipher_suites: 클라이언트에서 받은 목록 중 하나를 정한다.

 

1.1.2) 2단계 (서버)

④ ServerCertificate

서버의 인증이 필요한 경우 ServerHello뒤에 인증서를 보내야 한다.

 

⑤ ServerKeyExchange

서버의 인증서를 보내지 않았거나, 보낸 인증서에 키교환에 필요한 정보가 부족할 때 보내는 메시지이다.

 

⑥ CertificateRequest

클라이언트에게 클라이언트 인증서를 통한 인증을 요구할때 사용하는 메시지이다.(기본적으로 부인방지 기능은 제공하지 않는다.)

 

⑦ ServerHelloDone

서버가 보낼 메시지를 다 보냈음을 알려주는 메시지이다.

 

1.1.3) 3단계 (클라이언트)

⑧ ClientCertificate

서버가 CertificateRequest 메시지를 보냈을 때 클라이언트가 보내는 메시지이다.

 

⑨ ClientKeyExchange

세션키를 생성하기 위해서 임의의 비밀 정보인 48바이트로 RSA, DH 등을 이용하여 암호화한다.

 

⑩ CertifficateVerify

인증서의 명백한 확인을 위해서 handshake 메시지를 전자서명하여 전송한다. 

 

1.1.4) 4단계 (암호정보 교환)

ChangeCipherSpec: 이 메시지 이후 전송되는 메시지는 새롭게 협상된 알고리즘 과 키를 이용한다는 메시지이다.

Finished: 협상된 알고리즘과 키가 처음으로 적용된다.

 

메시지 유형	매개변수
hello_request, server_hello_done	없음
client_hello	버전, 랜덤, 세션, 암호도구, 압축방법
server_hello
certificate	연속된 X.509v3 인증서
server_key_change	매개변수, 서명
certificate_request	유형, 기관
certificate_verify	서명
client_key_exchange	매개변수, 서명
finished	해시 값

 

2) Record Protocol

적용/변경된 보안 파라미터를 이용하여 실제 암복호화, 무결성, 압축/압축해제 등의 기능을 하는 프로토콜이다.

실제 SSL/TLS 데이터 교환을 할때 사용하고 신뢰성 있는 전송을 위해서 TCP를 사용하고 기밀성과 무결성을 제공한다.

 

기밀성: TLS 페이로드를 관용 암호화 하는데 쓸 공유 비밀키를 정의한다.

무결성: MAC에 사용할 공유 비밀키를 정의한다

 

2.1) 동작 과정

① Payload를 단편화

② 단편화된 Payload 압축

③ hash함수를 이용해 MAC(Handshake Secret Key 이용)을 생성한다.

④ 해당 값을 암호화 한다.

⑤ 암호화 한 값을 SSL Record 프로토콜 앞에 붙여줌

 

3) ChangeCiperSpec Protocol

바로 직전에 새롭게 협상된 CipherSpec과 키에 의하여 보호될 후속 레코드를 상대에게 알리기 위해 서버 또는 클라이언트에게 전송하는 프로토콜이다.

해당 메시지를 받으면 보류된 읽기 상태(Pending write state)를 현재 읽기 상태(Current write state)로 변경한다.

한 바이트로 구성되고 값 1을 갖는 한 개의 메시지로 구성된다.

 

4) Alert Protocol

SSL/TLS 통신 과정에서 발생하는 오류를 통보하기 위해 경고 할 때 사용된다. Critical Level일 경우 연결을 즉시 단절한다.

메시지는 2바이트로 구성되어있고 첫번째 바이트는 warning(경고) 또는 fatal(심각)을 표현하고 두번째 바이트는 경고 코드를 표현한다.

 

5) Heartbeat Protocol

정상적으로 동작한다는걸 나태내기 위해서 동기화를 위해 H/W 또는 S/W가 생성하는 주기적 신호를 의미한다.

주로 가용성 모니터링을 할 경우 사용된다.

 

6) SSL/TSL 관련 공격

6.1) OpenSSL의 HeartBleed 취약점 (2014.04)

TLS의 하트비트 확장이라고 하는 요구 데이터 길이에 대한 점검이 결여되어서 메모리상 관계없는 정보까지 상대방에게 전송하게되어 서버의 정보를 일정범위까지 훔칠 수 있다.

대책: OpenSSL 갱신, 하트비트 확장 미사용, 인증서 재발급, 비밀번호 변경 등

 

6.2) SSL 3.0의 취약점과 POODLE(Padding Oracle On Downgraded Legacy Encryption)공격 (2014.10)

특정 조건에서 공격자의 TLS를 SSL 3.0으로 다운그레이드한 통신을 강요할 수 있게 된다.

POODLE공격을 통해 SSL3.0을 사용하게 한뒤 MIMT공격을 정보 흭득이 가능하다.

대책: SSL3.0 미사용

 

6.3) 완전 순방향 비밀성(PFS, Perfect Forward Secrecy)

6.3.1) 개인키 노출 시 문제점

서버의 공개키와 개인키를 이용하여 키교환을 수행할 경우 공격자는 MIMT공격을 통해 트래픽을 가로채고 서버의 개인키를 이용해 세션키/비밀키 및 송수신 데이터를 복호화 할 수 있다.

해당 서버 인증서를 패기해도 CRL 또는 OCSP프로토콜을 통해 공격자가 이전 트래픽 정보를 보관하고 있다면 복호화 될 수 있다.

 

6.3.2) PFS 사용

비밀 키가 노출되더라도 그 전의 키 분배 과정에서 얻는 새로운 세션 키 정보가 수학적으로 예전의 키 정보와 관련이 없기 때문에 안전성에는 영향을 미칠 수 없어야 한다는 성질이다.

 

5. HTTPS와 S-HTTP

1) HTTPS

웹브라우저와 웹서버 간 안전한 통신을 위해 HTTP와 SSL의 결합이다.(https:// 사용, TCP 443 포트)

사용자 입력 값에 대한 검증은 수행하지 못한다.

암호화: URL, 내용, 브라우저 양식 내용, 쿠키, 헤더 내용

 

2) S-HTTP

SSL을 사용하지 않고 HTTP 메시지를 메시지 단위로 암호화하여 기존 TCP/IP망을 통해 전송된다.

요청 메시지 첫 번째 줄은 'Secure * SecureHTTP/1.1'과 같은 형태이다.

 

네트워크 관련 보안 프로토콜

3계층: IPSEC

4계층: SSL/TLS

7계층: S/MIME, Kerveros, S-HTTP, SET, OTP

 

 

[참조] 

http 요청 구조: https://deepwelloper.tistory.com/98

SSL/TLS: sonseungha.tistory.com/483 

SSL/TLS: hack-gogumang.tistory.com/550

PFS: www.krcert.or.kr/data/trendView.do?bulletin_writing_sequence=2407

http1.0, 1.1 그림: https://it-mesung.tistory.com/m/146