3장. 웹 애플리케이션 기술 - 1. HTML 프로토콜

1. HTML 프로토콜

메시지 기반 모델

“나는 이렇게 줄테니 너는 이렇게 받고 난 너가 준거 그렇게 받을게＂라고 하는 ‘약속’

요청,응답에 대한 교환은 독립적으로 취급되므로 각기 다른 TCP 연결 사용 (즉, 이전 데이터의 요청과 다음 데이터의 요청이 서로 관련이 없음

--> 비연결지향적 프로토콜

URL 구조

 

A. HTTP 요청

특정한 정보를 가진 헤더 존재
헤더+빈줄+바디 구조

*첫번째 줄에 있는 요소*
1) HTTP 전송방법 - GET 메소드 사용
2) 요청된 URL - 자료를 요청할 때 쓰는 이름. 클라이언트가 자료를 요청하기 위해 보내는   인자값 등 임의의 쿼리문자열
3) HTTP 버전 – 1.1,1.0이 주로 쓰임 (공격 시 1.1은 호스트 요청 헤더가 강제적)

*Request Header*
1) Referer: 이 요청이 어디에서 요청을 받았는지 URL (바로 직전에 머물렀던 웹 링크 주소)
2) User-Agent: 클라이언트 소프트웨어(브라우저,OS) 명칭 및 버전 정보, Mozila
3) Host: URL 주소에 나타난 호스트명을 상세하게 나타냄. 특히 다양한 웹시이트가 하나의 서버 안에서 호스트 되었을 때 필요.
4) Cookie: 서버가 Set-Cookie로 클라이언트에게 설정한 쿠키 정보.

서버가 클라이언트에게 전송한 인자값에 추가 정보를 보낼 때 사용???

 

B. HTTP 응답

*HTTP 응답의 첫번째 줄에 있는 요소*
1) HTTP 버전
2) 요청에 대한 결과 코드 – 성공 시 200
3) 응답에 대한 상황을 설명해주는 문자열 – 정상일 시 OK

*Response Header*
1) Server: 웹 서버 소트프웨어 정보 (모듈,운영체제)
2) Set-Cookie: 브라우저에게 쿠키에 대한 정보를 알려줌. 클라이언트가 페이지 요청 시,   쿠키로 사용됨
3) Pragma: 응답한 내용을 브라우저가 캐시에 저장하지 않도록 함
4) Expires: 리소스가 지정된 일시까지 캐시로서 유효함. 즉, 응답 컨텐츠가 언제 만료 되  었는지 나타냄
à Pragma와 Expire은 브라우저가 요청한 내용에 대해 최근 정보를 가지고 있는지 확인할 수 있음
5) Content-Type: 해당 개체에 포함되는 미디어 타입 정보(html/text, font, image 등..)
6) Content-Length: 메시지 바디 길이를 바이트 단위로 나타냄

 

 

C. HTTP 메소드

1) GET 메소드
-웹 서버에 존재하는 자원에 대한 요청
-요청된 자원의 URL 쿼리 문자열에 인자값을 보내는 용도 à 즐겨찾기
-URL을 주소창에 입력하면 웹서버 로그, 브라우저 히스토리, 다른 외부사이트로 연결될 시 -그 사이트의 Referer헤더에 저장되므로 쿼리에는 중요한 문자열이  오면 안됨

2) POST 메소드
-특정 행동을 시작할 때 사용. 행동을 수행하도록 설계됨. 새로운 자원을 생성
-요청인자를 메시지 바디에 보낼 수 있음 à 이걸로 전송된 매개변수들은 브라우저 주소창에 표시되지 않음
  cf)  쿼리 문자열에 요청인자 전달
-한번 열었던 페이지를 다시 띄우려고 하면 경고창이 나옴
why? 특정 행동을 수행하도록 설계되었기 때문. 한 번 액션이 실행된 경우, 브라우저는 사용자가 보낸 POST 요청을 바로 수락하지 않음.
  à 실수로 동일한 정보 재전송 방지

3) HEAD 메소드
-GET 메소드와 비슷하게 작동하지만 응답 시 메시지 바디를 보내지 않음 Only 헤더부분만! à GET 요청 전 자료가 있는지 확인하기 위해 보냄

4) TRACE 메소드
-진단 목적
-서버가 응답 바디에 요청 받은 자료와 똑같은 내용을 보냄(Loopback) à 클라이언트와 서버 사이에서 어떤 프록시 서버가 요청을 조정하는지 여부 판단 가능

5) OPTION 메소드
-특정 자원에 맞는 HTTP 방식을 알려 달라고 서버에 요청
-서버는 Allow 헤더에 사용 가능한 메소드 리스트를 보내줌
 
이 외에도 PUT(존재하는 자원에 대한 변경), DELETE(존재하는 자원에 대한 삭제) 등이 존재

 

 

D. URL

Uniform Resource Locator
웹 자료 고유의 이름. 자원 검색 시 활용

URL 구조 (형식)

포트 번호는 기본 80, 다른 번호 사용시에만 입력해주면 됨
path/to/resource?a=b&x=y나 resource?a=b&x=y처럼 경로만 나타낼수도 있는데 이는 웹페이지에서 웹사이트 안의 경로를 나타내거나 애플리케이션 자체에서 사용됨

 

E. REST (Representational state transfer)

분산 시스템에서 사용하는 아키텍처
요청과 응답 내용에 시스템 자원의 현재 상태를 나타냄

*REST형식 URL*
http://wann-app.com/search/ford/pinto
cf) 쿼리 문자열에 매개변수를 가진 URL
http://wann-app.com/search?make=ford&model=pinto

 

 

F. HTTP 헤더

1) 일반적인 헤더
Connection: HTTP 전송 완료 후 TCP연결 개방 여부
Content-Encoding: 메시지 바디에 어떤 인코딩 할지 (ex.gzip 압축)
Content-Length: 메시지 바디 길이 (ex. GET요청에 대한 응답으로)
Content-Type: 메시지 바디에 있는 콘텐츠 종류
Transfer-Encoding: 메시지 바디가 HTTP전송을 쉽게 하도록 도와주는 인코딩 방법을 보여줌?

2) 요청 헤더
Accept: 어떤 종류의 내용(그림,문서..)을 수락할지 서버에 알림
Accept-Encoding: 어떤 종류로 인코딩 된 문서를 받아들일지 서버에 알림
이 외에도 Accept-Charset, Accept-Language 등이 있는데, 1)의 Content-… 헤더와 1:1 대응함
 
Authorization: HTTP 인증 형태에서 사용자의 식별정보를 서버에 보냄.
  사용자 식별정보: 인증 토큰(JWT/Bearer 토큰)
  “토큰의 종류(Basic,Bearer 등)+실제 토큰 문자”를 전송
Cookie: 서버로부터 받은 쿠키를 다시 서버로 전달함. 서버는 이 쿠키를 이용하여 사용자를 식별함
Host: URL에 나타난 호스트명의 상세
If-Modified-Since: 제시한 일시 이후로만 변경된 리소스를 취득 요청함.
If-None-Match: 서버에 Etag가 달라졌는지 검사를 요청함. ETag가 다를 경우에만 컨텐츠를 새로 받음
  *entity tag (ETag): 메시지 바디 내용을 식별하는 태그. 같은 주소의 자원이더라도 컨텐츠가 달라졌다면 Etag가 다름.
  --> 따라서 Etag의 헤더값이 바뀌었다면 캐시를 지우고 새로 변경된 컨텐츠를 받음    서버가 요청에 대한 응답을 하면, 브라우저는 Entity tag를 서버에게 보냄 à 서버는 브라우저가 자료의 복사본을 사용할 수 있을 지 판단
--> 위의 두 헤드에서 만약 내용이 수정되지 않았다면 서버는 304모드를 보내 하드에 저장된 복사본을 사용하도록 지시함
Origin: 크로스도메인 Ajax 요청에서 요청이 시작된 도메인을 나타냄

참고 https://developer.mozilla.org/ko/docs/Web/HTTP/Access_control_CORS

  서버로 POST 요청을 보낼 때, 요청이 어느 주소에서 시작되었는지 나타냄.
  요청을 보낸 주소와 받는 주소가 다르면 CORS에러가 발생 --> 응답 헤더의 Access-Control-Allow-Origin와 관련됨

 

 --> Referer이랑 차이가 뭐지?

The Origin request header indicates where a fetch originates from. It doesn't include any path information, but only the server name. It is sent with CORS requests, as well as with POST requests. It is similar to the Referer header, but, unlike this header, it doesn't disclose the whole path.

 

CORS (Cross-Origin Resource Sharing): HTTP헤더를 사용하여 브라우저에게 한 출처에서 살행중인 웹 응용프로그램의 다른 출처의 선택된 자원에 대한 접근을 알려주는 매커니즘. 즉, 애플리케이션이 다른 출처(cross-origin)에 있는 리소스를 요청할 때 사용하는 매커니즘임. 올바른 CORS헤더가 있는 요청과 same-origin request만 가능

 

 

3) 응답 헤더

Access-Control-Allow-Origin: 크로스 도메인 Ajax요청을 통해 리소스를 가져올 수 있는지 여부를 나타냄

Cache-Control: 캐시에 대한 지시를 브라우저에게 전달하는 역할 (ex) 값: no-cache, no-store, public, private, max-age)

Etag: 엔티티 태그. 클라이언트는 같은 자료를 요청할 때 If-None-Match 헤더에서 Etag를 보내어 현재 브라우저의 캐시에 있는 자료의 버전을 서버에게 알릴 수 있음. (앞장 참고)

Expires: Expires에 지정된 시간까지 요청한 리소스의 복사본을 브라우저의 캐시에 저장해두고 사용함

Location: 재전송하는 응답에서 목적지를 나타내는데 쓰임. 상태코드 3부터 시작(3**)

  *새로 생성된 리소스의 경우; HTTP 상태코드 201 Created 반환

  *300번대 응답의 경우: HTTP/1.1 302 Found Location: /

  --> 이 응답이 왔을 경우 브라우저는 /주소로 재전송(redirect)함

Pragma: 브라우저에게 캐싱 지시를 보내기 위해 사용 (ex. no-cache)

Server: 사용하는 웹 서버 소프트웨어에 대한 정보

Set-Cookie: 쿠키를 생성하고 브라우저에 보냄. 이 쿠키 값은 서버에 다시 보내짐

www-Authenticate: 401 상태 코드와 함께 응답할 때 사용함. 서버로부터 제공받은 인증서의 종류와 상세 내용

X-Frame-Options: 현재 응답이 브라우저 프레임에 로드되는지 여부+어떻게 로드되는지

 

 

G. 쿠키

웹 애플리케이션이 사용자를 구분할 때 사용. 서버로 페이지를 요청할 때마다 사용.
공격자가 웹 애플리케이션의 취약점을 찾을 때 쿠키를 많이 사용함. 다른 사용자를 직접 공격 할 수 있기 때문.
Set-Cookie 헤더를 여러 번 사용해서 추가할 수 있고, 똑같은 HTTP 헤더에서 각 쿠키를 세미콜론으로 구분해서 다시 서버로 보내기도 함.
 
*Set-Cookie 헤더에 추가할 수 있는 속성*
Expires: 쿠키의 유효기간. 이 속성이 없으면 쿠키는 현재 작업 세션에서만 사용됨.
domain: 쿠키를 사용할 수 있는 도메인. 쿠키를 받은 도메인이나 근원지 컴퓨터와 같아야 함.
path: 쿠키가 사용할 수 있는 URL 경로
secure: HTTPS 요청으로만 쿠키 전송 가능
HttpOnly: 쿠키가 클라이언트 쪽의 자바스크립트로 직접 접근할 수 없음

 

H.상태 코드

HTTP응답의 첫번째 줄에 요청 결과를 나타내는 상태 코드를 포함
첫번째 숫자에 따라 다섯가지로 구분.

1) 1xx : 정보를 제공
100 Continue: 클라이언트가 서버에게 메시지 바디를 포함한 요청을 보냈을 때 받음.  클라이언트가 보낸 요청이 문제가 없으니 다음 요청을 이어서 보내도 된다는 뜻.

2) 2xx : 요청 성공
200 OK: 요청 성공. 서버의 응답은 클라이언트가 요청한 내용에 대한 결과를 포함함.
201 Created: 클라이언트의 PUT 요청 성공 (Location header)

 

3) 3xx : 요청한 자원이 다른 곳에 있음

301 Moved Permanently: 브라우저의 요청을 다른 URL로 항시 전달한다는 의미. 다른 URL에 대한 정보는 Location 헤더에 나타남. 클라이언트는 바뀐 URL을 통해 자원을 찾음.

302 Found: 브라우저의 요청을 임시 URL로 바꾸고 Location 헤더에 임시로 변경한 URL에 대한 정보를 적음. 클라이언트가 다음에 같은 요청을 하면 기존의 URL로 돌아감.

304 Not Modified: 서버는 If-Modified-Since, If-None-Match 요청 헤더로 클라이언트가 최신 리소스를 가지고 있는지 확인함.

4) 4xx : 요청(클라이언트)에 문제

400 Bad Request: 잘못된 HTTP 요청

401 Unauthorized: 서버가 요청에 대해 HTTP 인증 확인 요청. www-authenticate 헤더에 인증과 관련된 정보

403 Forbidden: 요청에 대한 접근 차단

404 Not Found: 요청한 자료가 존재하지 않음

405 Method Not Allowed: 요청에 사용한 메소드가 해당 URL에 지원이 불가함

413 Request Entity Too Large: 요청한 바디를 서버에서 처리하기에 너무 큼

414 Request URI Too Long: 요청에 사용한 URL이 서버에서 처리하기엔 너무 긺

5) 5xx: 서버에 에러가 있음

500 Internal Server Error: 서버가 클라이언트의 요청을 실행할 수 없음. 보통 서버가 예상하지 못하는 요청을 보내서 앱이 처리하지 못할 때 발생. 서버의 응답 내용을 살펴야 함.

503 Service Unavailable: 서버는 요청에 응답할 수 있지만, 애플리케이션이 응답하지 못할 때. 요청이 문제인지 앱이 문제인지 확인해야 함.

 

 

I. HTTPS

HTTP와 같은 애플리케이션 계층 프로토콜. SSL(Secure Socket Layer)을 이용해 클라이언트와 서버 사이 정보를 보호함.
필요 이유: HTTP 프로토콜은 암호화 되지 않은 TCP를 사용하기 때문에 공격자가 중간에 정보를 가로챌 수 있음
SSL -> TLS (Transport Layer Security)로 바뀌고 있음.

 

--> 참고(OSI모형): https://namu.wiki/w/OSI%20%EB%AA%A8%ED%98%95#s-2.4

OSI 모형 - 나무위키

J. HTTP 프록시

HTTP 프록시 서버: 클라이언트 브라우저와 웹 서버 간 중개. 캐싱, 인증, 접근 통제 서비스 제공

*작동 방식*
1) HTTP 요청 시 브라우저가 보내는 URL의 호스트명을 목적지 웹 서버를 찾는 데 직접적으로 사용
2) TCP 레벨의 릴레이로 프록시 서버를 사용해야 함
-브라우저가 CONNECT 메소드로 프록시에 요청 à 프록시가 200 OK 응답 à 프록시가 TCP 레벨 릴레이로 요청을 웹서버에게 보냄

특수하게 조작된 프록시 서버는 웹 애플리케이션을 공격할 때 사용하는 가장 유용한 도구임. HTTPS를 뚫고 모든 요청과 응답을 조작할 수 있는 환경을 만들 수 있기 때문.

 

K. HTTP 인증

다양한 사용자 인증 방법
Basic: 요청 헤더에 Base64로 암호화 한 문자열을 사용자 자격증명으로 보냄 à 간단한 인증 방법
NTLM: 시도/응답 방법. 윈도우 NTLM 프로토콜 사용
Digest: 시도/응답 방법. MD5 체크섬 사용