min8282

[공통과정] 웹 해킹/HTTP의 이해 본문

K-Shield.Jr

[공통과정] 웹 해킹/HTTP의 이해

min8282 2024. 7. 14. 18:19

HTTP란?

  • 브라우저와 웹 서버 간의 통신을 위한 프로토콜
  • HTTP Request : 클라이언트가 서버에게 보내는 요청
  • HTTP Response : 서버가 클라이언트에게 보내는 응답

HTTP Response는 요청이 있어야 응답이 올 수 있다. 응답만 있는 경우X

그림1. HTTP 프로토콜

HTTP 구조

  • Request Message : 웹 브라우저가 서버에게 요청할 때 보내는 메시지
  • Response Message : 웹 서버가 HTTP Request를 받고 응답할 때 보내는 매시지

그림2. HTTP 구조1
그림3. HTTP 구조2

  • 개행문자(\r\n) 라인으로 구분하여 데이터를 식별한다.
  • 공백라인은 요청 또는 응답의 메타데이터가 모두 전송되었음을 알리는 빈 줄

HTTP Requset

  • 클라이언트가 서버에게 보내는 데이터 패킷(클라이언트  -> 서버)
  • HTTP Method : 서버가 수행해야 할 동작
  • Path + (Query String) : 주로 URL 또는 프로토콜 등 절대 경로
  • HTTP Version : 메시지의 남은 구조 결정, 응답 시 사용해야 할 HTTP 버전을 알려주는 역할

HTTP Method

구분 내용
GET 특정한 리소스를 가져오도록 요청
파라미터가 URL에 입력됨
POST 주로 데이터 등록, 수정 시 사용
PUT 요청 페이로드를 사용해 새로운 리소스를 생성하거나, 대상 리소스를 나타내는 데이터를 대체
DELETE 리소스 제거 시 사용

 

GET vs. POST

구분 GET POST
기록 파라미터들은 URL의 일부이기 때문에 브라우저 히스토리에 기록 파라미터들이 브라우저 히스토리에 기록되지 않음
재전송 재실행되더라도 브라우저 캐시에 HTML이 저장되어 있다면 서버에 다시 전송 되지 않음 브라우저가 보통 사용자에게 데이터가 다시 전송 되어야 한다고 알려줌
파라미터 URL에 넣을 수 있는 파라미터 데이터 제한 서버에 파일 업로드하는 것을 포함하여 파라미터 전송 가능

 

GET은 데이터가 저장된 곳이 Header 부분, POST는 body 부분으로 기억하면 좋다.

HTTP Request(Header)

  • 클라이언트의 요청에 대한 부가적인 정보
  • 대소문자 구분 없이 문자열 다음에 콜론(:)이 붙으며, 그 뒤에 오는 값은 헤더에 따라 다르게 명시
  • Header Field
    • Host : 요청하는 호스트에 대한 호스트명 및 포트번호
    • User-Agent : 사용자 웹 브라우저 종류 및 버전 정보
    • Accept : 클라이언트가 원하는 콘텐츠 타입 및 우선순위 명시
    • Connection : 클라이언트와 서버 간 연결에 대한 옵션


HTTP Response

  • 클라이언트가 요청한 데이터에 대한 응답(서버 -> 클라이언트)
  • Start Line : protocol version, status code, status text
  • Response Header : Response 정보
  • Response Body : 실제 응답 데이터

HTTP Response(Start Line)

  • Version : 프로토콜 버전
  • Status Code : 요청의 성공 여부
  • Phrase : 상태코드에 대한 설명을 글로 표현하여 HTTP Message 이해 시 도움을 줌

그림3. Start Line

HTTP Response(Header)

  • 서버의 응답에 대한 부가적인 정보
  • Header Field
    • Connection : 현재의 전송이 완료된 후 네트워크 접속 여부
    • Keep-Alive : 송신자가 연결에 대한 타임아웃과 요청 최대 개수
     

그림4. Header

HTTP Response(Body)

  • 실제 응답 데이터

그림5. Body

HTTP Response(Status Code)

구분 내용
1XX(Information) 요청을 받으면 기존 작업 처리 계속 진행
2XX(Successful) 요청을 성공적으로 받음
3XX(Redirect) 요청 완료를 위해 추가적인 동작 수행
4XX(Client Error) 400(Bad Request) 요청 메시지의 문법 오류
403(Forbidden) 클라이언트 요청에 대한 접근 차단
404(Not Found) 클라이언트가 서버에 요청한 자료가 존재하지 않음
5XX(Server Error) 서버가 유효한 요청에 대한 작업 수행 불가

HTTPS(HyperText Transfer Protocol over Secure Socket Layer)

  • 클라이언트/서버 환경에서 데이터를 안전하게 전송하기 위한 인터넷 암호화 통신 프로토콜
  • 클라이언트가 접속한 서버가 신뢰할 수 있는 서버임을 보장

그림6. HTTP vs. HTTPS


SSL 인증서 발급 과정

SSL 인증서 발급 과정을 서버와 CA(Certificate Authority)를 중심으로 간단하게 설명하면 다음과 같습니다.

1. 키 쌍 생성 (서버 측)

  1. 비공개 키 (Private Key) 생성: 서버는 비공개 키를 생성합니다. 이 키는 서버에 안전하게 저장되며 절대 외부로 유출되지 않습니다.
  2. 공개 키 (Public Key) 생성: 비공개 키와 쌍을 이루는 공개 키를 생성합니다. 이 공개 키는 나중에 SSL 인증서에 포함됩니다.

2. CSR (Certificate Signing Request) 생성 (서버 측)

  1. CSR 생성: 서버는 공개 키와 함께 도메인 정보, 조직 정보 등을 포함한 CSR을 생성합니다. 이 CSR은 CA에게 제출됩니다.

3. CSR 제출 (서버 → CA)

  1. CSR 제출: 서버 관리자는 생성한 CSR을 CA에 제출합니다. 이 과정은 CA의 웹사이트나 API를 통해 이루어집니다.

4. 검증 (CA 측)

  1. 도메인 검증: CA는 서버가 소유하고 있는 도메인이 CSR에 명시된 도메인과 일치하는지 확인합니다. 이는 이메일 확인, DNS 레코드 추가, 또는 웹 서버에 파일 업로드 등의 방법을 통해 이루어집니다.
  2. 조직 검증 (필요시): 특정 인증서 종류(OV 또는 EV)의 경우, CA는 추가로 조직의 존재를 검증합니다. 이 과정은 조직의 법적 서류를 확인하거나 전화 통화를 통해 이루어질 수 있습니다.

5. 인증서 발급 (CA 측)

  1. 인증서 생성: 검증이 완료되면, CA는 서버의 공개 키와 도메인/조직 정보를 사용하여 SSL 인증서를 생성합니다.
  2. 인증서 발급: 생성된 SSL 인증서를 서버에 발급합니다.

6. SSL 인증서 설치 (서버 측)

  1. 인증서 설치: 서버 관리자는 CA로부터 받은 SSL 인증서를 서버에 설치합니다. 이 과정에서 인증서 파일과 CA 번들 파일을 서버 설정에 추가합니다.
  2. 서버 구성: 서버 설정 파일을 수정하여 SSL/TLS가 활성화되도록 합니다. 예를 들어, HTTPS를 통해 접속을 허용하고 적절한 포트(보통 443)를 사용하도록 설정합니다.

7. SSL 설정 테스트 (서버 측)

  1. 테스트 및 확인: SSL 인증서가 올바르게 설치되었는지 확인합니다. 이는 웹 브라우저에서 확인하거나 온라인 SSL 도구를 사용하여 테스트할 수 있습니다.

요약

  • 서버: 비공개 키와 공개 키를 생성하고, CSR을 만들어 CA에 제출합니다.
  • CA: 도메인과 조직을 검증한 후, 서버의 공개 키를 포함한 SSL 인증서를 발급합니다.
  • 서버: CA로부터 받은 SSL 인증서를 설치하고, SSL/TLS 설정을 완료합니다.

 

그림7. HTTPS 접속 과정


Proxy

원격 프록시

  • 외부에 프록시 서버가 존재
  • 클라이언트의 IP 주소를 숨기는 것이 가능

그림8. 프록시

로컬 프록시

  • 클라이언트 PC 내에 설치
  • 클라이언트와 서버 간의 HTTP 통신을 분석 및 변조할 때 사용 가능

Reference