HTTP Protocol⭐

유서정·2024년 4월 4일

웹 구조 및 보안

목록 보기

1/4

HTTP Protocol

WWW에서 웹 브라우저(클라이언트)와-웹 서버가 서로 HTML 문서를 주고 받기 위한 표준 프로토콜

HTTPS (HTTP over SSL)

HTTP의 보안 버전
HTTP 계층 아래의 SSL 서브 계층을 제공하여 사용자 페이지 요청을 암호화·복호화하여 데이터를 전송하는 웹 프로토콜

웹 동작 순서

① 사용자가 웹 브라우저에 특정 사이트의 주소www.naver.com를 입력한다.

② 웹 브라우저가 DNS 서버에 해당 도메인의 IP 정보를 조회

③ DNS서버에서 IP주소125.209.222.142로 변환 후 응답

④ 웹 브라우저가 IP 주소를 이용하여 웹 서버에게 웹 페이지(html 문서)를 요청한다.

[WAS서버 있는 경우]
⑤ 웹 서버는 바로 웹 페이지를 공급하지 못하고, 웹 애플리케이션 서버와 데이터 베이스에서 웹 페이지 작업을 처리한다.

⑥ 작업 처리 결과를 웹 서버로 보낸다.

⑦ 웹 서버는 웹 브라우저에게 웹 페이지(html 문서)를 응답한다.

⑧ 웹 브라우저는 화면에 웹 페이지를 출력한다.

[참고] https://all-young.tistory.com/21

웹 프로세스 구조

WEB 서버
웹 브라우저로부터 HTTP 요청을 받아 정적인 컨텐츠를 제공하는 기능
WAS 서버 (Web Application Server)
DB 조회나 다양한 로직 처리를 요구하는 동적인 컨텐츠를 제공하기 위해 만들어진 Application Server
→ 웹서버와 DB의 중간다리 역할 (미들웨어)
⇉ 기능을 분리하여 성능을 높이는 정도의 용도 (효율적인 분산처리)
WAS는 기본적으로 동적인 컨텐츠 제공을 위해 존재하는 서버
▪ 정적인 컨텐츠 제공 : WAS를 거치지 않고 바로 제공
▪ 동적인 컨텐츠 제공 : WAS에 클라이언트 요청을 보내고 WAS가 처리한 결과를 클라이언트에게 전달

[참고] https://dar0m.tistory.com/244

웹 어플리케이션 이해

컴퓨터에 설치해서 사용해야 했던 애플리케이션과 달리 (Word, Wireshark)
웹 브라우저를 통해 응용 소프트웨어의 기능을 이용할 수 있도록 만든 웹 서비스 (쇼핑몰, 벨로그..)

[참고] 웹 애플리케이션 https://better-together.tistory.com/230

SSS (Server Side Script)

서버 측에서 실행되는 스크립트
CSS에서 받아온 정보를 처리하는 역할

웹페이지가 각기 다른 요구에 따라 능동적으로 변할 수 있도록 함 (좀더 동적인 페이지 제공)
CSS에 비해 데이터 위조의 가능성을 줄일 수 있음 (보안 ↑)
ASP, PHP, JSP ...
CSS (Client Side Script)

서버가 아닌 클라이언트 측의 웹브라우저에 의해 해석되고 실행
웹 서버의 부담을 줄이면서 다양한 기능을 수행할 수 있음
HTML, JavaScript, VisualBasic Script, JScript ...

C:\Windows\System32\drivers\etc

`nslookup`

네임서버 아래에 있는 정보를 바탕으로 도메인 서버를 받고 ip정보 조회

❗ip 주소가 여러개인 이유 → 부하 분산

버추얼 호스트
개념 알아만 두기

URL Scheme

URL 구조의 프로토콜

https - 통신 프로토콜
www - 서브도메인
example.com - 서버 도메인
:80 - 포트번호
/file.html - 서버 내, 경로

문자	인코딩
`?`	파라미터 시작 지점
`=`	파라미터 값 대입
`&`	다음 파라미터 식별자
`+`	공백
`#`	현재 페이지 내 특정 섹션 의미

등등..

HTTP 패킷 분석⭐

HTTP Request 구조

status-line (시작 라인)
header
CRLF (공백 라인)
헤더의 끝을 의미하는 개행
message body

HTTP Request 메소드⭐

(클라이언트 → 서버)

Method	설명
GET	리소스 조회
POST	리소스 생성, 요청 내역 처리 ex.로그인
PUT	리소스를 업데이트, 해당 리소스가 없으면 생성
DELETE	리소스 삭제 ...
OPTIONS	서버에서 지원되는 HTTP 메서드에 대한 정보를 요청
HEAD	GET 메서드와 유사하지만, 응답 본문을 제외한 헤더 정보만 가져옴 주로 검색엔진에서 URL/링크의 유효성을 검증하기 위한 목적으로 사용
TRACE	서버에게 클라이언트로부터 받은 요청 메시지를 되돌려 받아 디버깅 및 진단 목적으로 사용
CONNECT	프록시 서버를 통해 터널링 연결을 설정

GET

리소스를 요청(조회)하는 메서드

서버에 전달하고 싶은 데이터는 query (= 쿼리 파라미터, 쿼리 스트링)를 통해서 전달

GET /search?q=hello&hl=ko HTTP/1.1
Host: www.google.com

GET 방식을 통한 URL 파라미터 전달

기본적으로 데이터베이스에 대한 질의와 같은 요청을 할 때 사용

데이터를 URL의 끝에 쿼리 스트링(Query String)의 일부로써 서버로 전달한다.
⑴ 데이터가 주소 입력란에 표시되므로 보안성 X
⑵ 데이터 조회에 성공한다면 Body 값에 데이터 값을 저장하여 성공 응답을 보낸다.

GET 방식으로 보낼때는 같이 딸려가는 글자수에 제한이 있다 텍스트(255자).
⑴ 이를 초과하는 데이터는 절단된다.

일반적인 HTTP 호출은 모두 GET 방식으로 이루어진다.

변수 넘기지 않는 일반 호출도 GET 이다.

같은 요청을 여러 번 하더라도 변함없이 항상 같은 응답을 받는다. (멱등성)

사용이 간편하다.

POST

주로 새로운 리소스 생성에 이용

메시지 바디를 통해 서버로 요청 데이터 전달
=> 보안상 우수
=> 메세지 길이에 제한 X
POST로도 리소스 요청(조회)가 가능함
※ GET 메서드는 캐싱을 이용하므로 조회 속도가 POST보다 우수

POST /members HTTP/1.1
Content-Type: application/json
{
 "username": "hello",
 "age": 20
}

POST 방식을 통한 URL 파라미터 전달

이 방식은 서버에 값을 넘기기 위해 만들어진 방식입니다.
⑴ 데이터베이스에 대한 갱신 작업과 같은 서버측에서의 정보 갱신 작업을 원할 때 사용
⑵ 새 리소스 생성(등록), 요청 데이터 처리, 다른 메서드로 처리하기 애매한 경우 등에 사용

메시지 바디를 통해 서버로 요청 데이터 전달.
⑴ 다음과 같이 브라우저의 주소창에는 실행 파일명만 나타납니다.
http://www.victim.com/hackers/post_meth_view.jsp
⑶ 데이터가 외부적으로 드러나지 않아 GET 방식에 비해 비.교.적 보안성이 좋다
(크롬의 개발자 도구, Burpsuite와 같은 툴로 요청 내용을 확인이 가능하므로 중요데이터는 암호화 필수)

일반적으로 HTML의 FORM을 이용해서 넘기는 방식입니다.

일정한 크기 이상의 데이터를 전송할 때에는 POST 방식을 사용

내부의 구분자가 각 파라미터(이름과 값)를 구분

POST 방식을 사용하면 GET 방식에 비해 상대적으로 처리 속도가 늦어짐

클라이언트측에서 데이터를 인코딩 → 서버측에서 디코딩 클라이언트와 서버갂에 상호 정의되어있는 형식대로 값을 인코딩한 다음 서버로 전송
서버 : 전달된 스트릿을 디코딩 → 각 파라미터를 구분 → 필요한 값들을 추출

나 보기 편하게 만들어 놓은 GET, POST 차이

http get, post 메소드의 차이

[사용목적]
GET은 리소스를 요청할때 주로 사용되는 메소드이고
POST는 리소스를 생성하기 위해 사용되는 메소드이다
[데이터 전송 방식]
GET은 서버로 전송할 데이터를 url 끝부분에 쿼리스트링 형식으로 포함하여 전송하는데
POST는 전송할 데이터를 http message body에 담아 서버로 보낸다.
따라서 비교적 대량의 데이터를 전송할 때 POST 방식을 많이 사용한다.
[보안성]
POST 방식은 데이터가 외부적으로 드러나지 않아 GET 방식에 비해 보안성이 좋긴하지만, 버프스위트나 피들러와 같은 프록시 툴로 요청 내용을 확인할 수 있으므로 중요 데이터는 꼭 암호화하여 전송하는 것이 안전
[멱등성]
GET은 리소스를 조회한다는 점에서 여러 번 요청하더라도 응답이 같다.
반대로 POST는 리소스를 새로 생성하거나 처리하는 과정에서 서버의 상태가 달라질 수 있기 때문에 호출 결과가 달라질 수 있다.

※ 멱등성 : 같은 요청을 여러 번 반복하더라도 그에 대한 결과가 같은 것

HTTP 상태코드⭐

1xx , Informational 처리중 (임시응답)
요청이 수신되어 처리중
2xx , Successful 정상처리
클라이언트 요청 정상 처리
3xx , Redirection 추가동작필요
요청을 완료하기 위해서는 추가 행동이 필요
주로 주소가 이전되어 리다이렉션한 주소로 다시 시도하라는 의미
4xx , Client Error
없는 페이지를 요청하는 등 클라이언트의 요청이 잘못된 경우를 의미
5xx , Server Error
정상적인 요청을 서버 사정으로 처리하지 못한 경우.
서버의 부하, DB 처리 과정 오류, 서버에서 익셉션이 발생했을 경우

2xx (Successful)

상태 코드	상태 텍스트	서버 측면에서 의미
200	OK	서버가 요청을 성공적으로 처리
201	Created	원격지 서버에 파일 생성 요청이 처리되어 새로운 리소스가 생성됨
202	Accepted	요청이 접수되었으나, 처리가 완료되지 않았음
204	No Content	요청이 성공적으로 처리되었지만, 응답 페이로드 본문에 보낼 데이터가 없음(==클라이언트에게 돌려준 콘텐츠가 없다) DELETE 요청에 대한 응답에 많이 사용

3xx (Redirection)

상태 코드	상태 텍스트	서버 측면에서 의미
300	Multiple Choices	지정한 URI에 대해 서버에서 콘텐츠를 결정하지 못하고 클라이언트에게 여러 개의 링크를 응답할 때 사용
301	Moved Permanently	지정한 리소스가 새로운 URI로 이동 리다이렉트시 요청 메서드가 GET으로 변하고, 본문이 제거될 수 있음(MAY)
302	Found	페이지 이동 브라우저의 요청을 다른 url로 바꾸고 Location헤더에 임시로 변경한 url에 대한 정보 적음 클라이언트가 다음에 같은 요청을 하면 기존의 url로 돌아감
303	See Other	클라이언트가 요청한 리소스를 다른 URI에서 GET 요청을 통해 얻어야함
304	Not Modified	로컬 캐쉬정보 이용 요청한 자원에 대해 변경된 사항이 없으므로 캐시되어있는 자원으로 리디렉션 즉, 브라우저로부터의 최초 요청 시에는 200번 응답을 받지만 이후에 자원에 변화가 없다면 일정 시간 동안은 304번 응답을 받음
307	Temporary Redirect	일시적인 컨텐츠 이동
308	Permanent Redirect	영구적인 컨텐츠 이동

4xx (Client Error)

상태 코드	상태 텍스트	서버 측면에서 의미
400	Bad Request	요청 구문이 잘못됨 클라이언트가 잘못된 요청을 해서 서버가 요청을 처리할 수 없음
401	Unauthorized	인증 실패 클라이언트가 해당 리소스에 대해 인증되지 않았거나, 유효한 인증 정보가 부족 (클라이언트의 인증부족-로그인)
403	Forbidden	지정한 리소스에 대한 액세스가 금지됨 서버가 요청을 이해했지만 승인을 거부함 (인증은 됐지만, 권한 없음)
404	Not Found	요청 리소스를 찾을 수 없음 (또는 클라이언트가 권한이 없는 리소스에 접근하는 경우에 해당 리소스를 숨기고 싶을 때)

5xx (Server Error)

상태 코드	상태 텍스트	서버 측면에서 의미
500	Internal Server Error	서버 에러 서버 문제로 오류 발생, 애매하면 500 오류
502	Bad Gateway	불량 게이트웨이
503	Service Unavailable	서버의 일시적인 점검 또는 과부하로 잠시 요청을 처리할 수 없음

텔넷으로 구글에 연결 요청

telnet www.google.com 80 
GET / HTTP/1.1

HTTP의 "connectionless", "stateless"한 특성을 보완하기 위해서 쿠키와 세션을 사용

connectionless : 클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어 버리는 특징
stateless : 통신이 끝나면 상태를 유지하지 않는 특징

웹사이트 접속 시, 웹 브라우저에 저장되는 데이터

Key=Value 형태로 사용
웹페이지의 사용자 상태나 동작에 대한 정보를 저장
세션 유지, 상태정보 저장 등에 사용
서버 부하를 줄이는 용도
사용자 웹 브라우저에 저장하기 때문에, 조작 가능
Set-Cookie 헤더를 통해 전송

ex.
팝업창 '오늘 이 창을 다시 보지 않기' 체크
로그인 시 아이디와 비밀번호 저장 및 자동 입력
쇼핑몰의 장바구니 등

쿠키 동작 방식

▪ Client(브라우저)가 사이트에 접속
▪ 서버는 정보를 저장한 쿠키를 생성하여 Client로 전송
▪ Client는 서버로부터 받은 쿠키를 파일에 저장한다.
▪ Client는 서버에 데이터 요청(조회, 수정, 삭제 등)을 전송할 때 마다 쿠키를 포함하여 전송
▪ 전송된 쿠키는 서버에서 데이터베이스에 저장된 이용자정보를 조회 및 식별해 결과를 반환
▪ 할당 받은 쿠키값으로, 데이터 요청시 인증 정보로 사용

쿠키 조작 방식

쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 가능성 有

쿠키 변조를 통해, 서버에 요청 전송해 임의 이용자 정보 탈취

=> 쿠키 변조에 의해, 클라이언트가 인증 정보를 변경할 수 없도록 세션을 사용

Session🖥️

클라이언트가 웹 서버에 접속(연결)해있는 상태

서버에 사용자 인증 정보를 저장하고, 세션 ID를 생성(난수값)하여 각 클라이언트에 전달
=> 클라이언트는 서버에 요청을 전송할 때 마다 할당 받은 세션 ID로 인증

로그인 상태 유지, 이용자별 정보 저장 등에 사용
서버 측에서 정보 저장
key는 쿠키로 전송
인증정보에 많이 사용
Session Key는 Cookie(Set-Cookie)를 통해 전달
세션 변조 불가능 (단, 세션 원문을 탈취할 경우 세션 변조 가능)

ex.
로그인 같이 보안상 중요한 작업을 수행할 때 사용

세션 동작 방식

▪ Client 최초 로그인 과정을 통해, 서버에서 이용자 계정에 대한 세션ID를 할당받아 인증에 사용
▪ Client는 서버에 요청(조회, 수정, 삭제등)을 전송할때마다 할당받은 세션ID로 인증

세션 변조 방식(X)

세션 변조를 통해, 서버에 요청 전송해 임의이용자 정보 탈취할 수 없음
※ 단, 세션 원문을 탈취할 경우 세션 변조를 이용한 요청 전송 가능

위에서 말하는 세션 변조는 공격자의 세션 ID를 정상적으로 사용하는 사람의 세션 ID로 변조하여 사용한다는 뜻
(서버 내부에 저장되어 있는 세션 정보는 변조 불가)

쿠키 vs. 세션

[정보가 저장되는 위치]
쿠키: 클라이언트, 세션: 서버
[보안성]
쿠키는 클라이언트 로컬에 저장되기 때문에 request에서 스니핑의 위험, 변질 등 보안에 취약하지만
세션은 쿠키를 이용해 세션 ID 만 저장하고 서버에서 처리하기 때문에 비교적 보안성이 좋다.
[만료 시기]
쿠키 저장시 설정 (브라우저를 종료되어도, 만료 시점이 지나지 않으면 자동 삭제되지 않음)
세션은 브라우저가 종료되면 만료 (기간 지정 가능)
ㄴ> 크롬은 램이 기억해줘서, 브라우저 종료해도 로그인 유지되는 경우 多

쿠키 vs. 캐시

둘 다 데이터를 임시로 저장해두어 필요할 때 사용
웹 애플리케이션의 성능 및 사용자 경험 개선을 위해 사용되는 도구

※ 캐시
이미지나 css, js파일 등을 브라우저나 서버 앞 단에 저장해놓고 사용하는 것
웹 페이지의 리소스(이미지, CSS, 자바스크립트 파일 등)를 저장하여 매번 서버에서 다운로드하지 않고도 빠르게 로드할 수 있게 합니다. 캐시는 네트워크 트래픽을 줄이고 페이지 로딩 속도를 향상시키는 데 사용

[저장 위치]
쿠키: 클라이언트 / 캐시: 브라우저 내부

[데이터의 사용 목적]
쿠키는 사용자 상태 정보를 추적하고 유지하는 데 사용 (사용자의 수고를 덜어줌)
캐시는 리소스 로딩 속도를 향상시키는 데 사용

Chrome 캐시 위치 : Windows 10의 C:\Users\Username\AppData\Local\Google\Chrome\User Data\Default\Cache

참고
https://velog.io/@rimmz/%EC%BF%A0%ED%82%A4%EC%99%80-%EC%84%B8%EC%85%98-%EC%B0%A8%EC%9D%B4-Cookie-Session#-%EC%84%B8%EC%85%98session-

유서정

information security

HTTP Protocol⭐

웹 구조 및 보안

HTTP Protocol

HTTPS (HTTP over SSL)

웹 동작 순서

[참고] https://all-young.tistory.com/21

웹 프로세스 구조

WEB 서버

WAS 서버 (Web Application Server)

WAS는 기본적으로 동적인 컨텐츠 제공을 위해 존재하는 서버

[참고] https://dar0m.tistory.com/244

웹 어플리케이션 이해

[참고] 웹 애플리케이션 https://better-together.tistory.com/230

SSS (Server Side Script)

CSS (Client Side Script)

nslookup

❗ip 주소가 여러개인 이유 → 부하 분산

URL Scheme

HTTP 패킷 분석⭐

HTTP Request 구조

status-line (시작 라인)

header

CRLF (공백 라인)

message body

HTTP Request 메소드⭐

GET

GET 방식을 통한 URL 파라미터 전달

POST

POST 방식을 통한 URL 파라미터 전달

http get, post 메소드의 차이

[사용목적]

[데이터 전송 방식]

[보안성]

[멱등성]

※ 멱등성 : 같은 요청을 여러 번 반복하더라도 그에 대한 결과가 같은 것

HTTP 상태코드⭐

1xx , Informational 처리중 (임시응답)

2xx , Successful 정상처리

3xx , Redirection 추가동작필요

4xx , Client Error

5xx , Server Error

2xx (Successful)

3xx (Redirection)

4xx (Client Error)

5xx (Server Error)

텔넷으로 구글에 연결 요청

Cookie & Session ⭐

connectionless : 클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어 버리는 특징stateless : 통신이 끝나면 상태를 유지하지 않는 특징

Cookie🍪

ex. 팝업창 '오늘 이 창을 다시 보지 않기' 체크 로그인 시 아이디와 비밀번호 저장 및 자동 입력 쇼핑몰의 장바구니 등

쿠키 동작 방식

쿠키 조작 방식

쿠키는 클라이언트 로컬에 저장되기 때문에 변질되거나 request에서 스니핑 당할 가능성 有

Session🖥️

ex. 로그인 같이 보안상 중요한 작업을 수행할 때 사용

세션 동작 방식

세션 변조 방식(X)

위에서 말하는 세션 변조는 공격자의 세션 ID를 정상적으로 사용하는 사람의 세션 ID로 변조하여 사용한다는 뜻(서버 내부에 저장되어 있는 세션 정보는 변조 불가)

쿠키 vs. 세션

쿠키 vs. 캐시

Chrome 캐시 위치 : Windows 10의 C:\Users\Username\AppData\Local\Google\Chrome\User Data\Default\Cache

0개의 댓글

`nslookup`

connectionless : 클라이언트가 요청을 한 후 응답을 받으면 그 연결을 끊어 버리는 특징
stateless : 통신이 끝나면 상태를 유지하지 않는 특징

ex.
팝업창 '오늘 이 창을 다시 보지 않기' 체크
로그인 시 아이디와 비밀번호 저장 및 자동 입력
쇼핑몰의 장바구니 등

ex.
로그인 같이 보안상 중요한 작업을 수행할 때 사용

위에서 말하는 세션 변조는 공격자의 세션 ID를 정상적으로 사용하는 사람의 세션 ID로 변조하여 사용한다는 뜻
(서버 내부에 저장되어 있는 세션 정보는 변조 불가)

Chrome 캐시 위치 : Windows 10의 `C:\Users\Username\AppData\Local\Google\Chrome\User Data\Default\Cache`