[Normaltic 웹해킹 입문] 2강 관련 복습&리뷰-①

HTTP 요청 / 응답 구조 정리 (복습용)

웹 요청이 어떻게 생겼는지, 서버가 어떻게 응답하는지 기본만 정확히 이해하면
와이어샤크나 웹 프록시(버프 스위트 등)로 트래픽 분석할 때 훨씬 편해진다.

1. HTTP Request (클라이언트 → 서버)

브라우저나 클라이언트(예: curl)가 서버에 요청을 보낼 때 HTTP 요청 메시지를 보낸다.
요청은 크게 요청라인(Request Line) + 헤더(Header) + (있을 수도 있는) 바디(Body) 로 구성된다.

1.1 요청라인 (첫 줄)

요청의 첫 줄은 이런 식으로 생겼다:

GET /login.php HTTP/1.1

구조:

• 메서드(Method): GET, POST 등
• 경로(Path): /login.php, /api/users, /images/logo.png 같은 리소스 위치
• 프로토콜 버전: HTTP/1.1, HTTP/2 등

즉 "무엇을 어떻게 요청하느냐"를 첫 줄에서 선언한다.

1.2 HTTP 메서드(= 웹 메서드)

자주 쓰는 메서드들을 목적과 함께 정리하면 아래와 같다.

1. GET
   • 서버에서 정보를 가져온다 (조회)
   • 예: 페이지 열기, 이미지 가져오기 등
   • Body(요청 본문)는 일반적으로 없음
2. POST
   • 서버로 데이터를 보낸다 (등록, 로그인 시 아이디/비번 전송 등)
   • 예: 로그인 요청, 회원가입 요청, 글쓰기
   • Body에 실제 전송 데이터가 담긴다 (폼 데이터, JSON 등)
3. HEAD
   • GET과 거의 같지만 응답에서 Body 없이 헤더만 받는다
   • 주로 "이 URL 살아있나?", "파일 크기 얼마나 되지?" 같은 사전 확인용
4. OPTIONS
   • "이 서버(또는 이 URL)는 어떤 메서드를 허용하나요?" 를 물어본다
   • CORS(크로스 도메인 요청)에서 많이 등장
5. PUT
   • 리소스를 "전체 교체"하는 개념
   • 예: /users/123에 대해 PUT을 보내면, 그 사용자의 정보를 통째로 이걸로 바꿔라 라는 의미
6. PATCH
   • 리소스의 "일부만 수정"
   • 예: 사용자 닉네임만 바꾼다든지 부분 업데이트
7. DELETE
   • 리소스를 삭제해 달라는 요청

※ 정리하면:

• GET: 읽기
• POST: 새로 만들기 / 서버에 전달하기
• PUT: 전체 수정
• PATCH: 부분 수정
• DELETE: 삭제
• HEAD / OPTIONS: 부가정보용

이 조합은 나중에 "RESTful API"랑 같이 이해하면 훨씬 깔끔해진다.

1.3 RESTful 개발이란?

쉽게 말해서:

URL만 보면 어떤 데이터(대상)를 다루는지 알 수 있고,
HTTP 메서드만 보면 무슨 동작(조회/수정/삭제)인지 알 수 있게 깔끔하게 만든 스타일.

예를 들어 /users 라는 주소가 있다고 하자.

• GET /users
  → "사용자 목록 좀 줘"
• POST /users
  → "새 사용자 하나 만들어줘"

그리고 /users/10 이라고 하면 id=10인 특정 사용자.

• GET /users/10
  → "10번 사용자 정보 줘"
• DELETE /users/10
  → "10번 사용자 지워줘"

중요한 점:

• URL은 무엇(users라는 리소스) 을 나타내는 "명사형"으로 둔다.
• "무엇을 할지(조회, 생성, 수정…)"는 URL 이름이 아니라 메서드(GET, POST, DELETE...) 로 표현한다.

이런 스타일로 API를 만들면

• 프론트엔드(웹화면)
• 모바일앱
• 다른 백엔드 서비스
  전부 똑같은 규칙으로 서버와 통신할 수 있어서 유지보수가 쉬워진다.

1.4 HTTP 헤더들

요청에는 여러 헤더가 따라간다. 대표적으로 자주 보는 것들:

• Host:
  • 어떤 호스트로 요청하는지(도메인)를 나타낸다.
  • 예: Host: www.example.com
  • HTTP/1.1부터는 필수 헤더다.
  • ※ 이건 "접속하는 사람"의 IP가 아니라 "요청받을 서버" 정보를 말하는 거다.
    • 예: 같은 서버 IP 안에 여러 도메인을 호스팅하는 경우, 어느 도메인으로 요청 왔는지 구분하기 위해 필요.
• User-Agent:
  • 누가 요청 보냈는지의 "클라이언트 정보"
  • 예: 브라우저 종류, 버전, OS
  • 보안 점검할 때 "이 요청은 진짜 크롬에서 나온 게 맞아 보이냐?" 같은 식으로 참고 가능
• Referer: (정확한 표준 철자는 오타 때문에 Referer로 굳어짐)
  • 이 요청이 어느 페이지에서부터 왔는지(이전 페이지 주소)
  • 예: 로그인 폼을 login.php에서 제출했으면 그 페이지 URL이 들어갈 수 있음
  • 분석/추적/광고/보안 점검(어디서 넘어온 요청인지 확인)에 유용
• 그 외 실무에서 자주 보는 것:
  • Content-Type:
    • 보낸 Body(본문)의 데이터 형태
    • 예: application/json, application/x-www-form-urlencoded, multipart/form-data 등
  • Cookie:
    • 세션 정보나 로그인 토큰 같은 게 들어간다 (사용자 식별 가능 포인트)
  • Authorization:
    • 토큰 기반 인증에 많이 쓰임 (예: Authorization: Bearer <토큰>)

요약하면,

• 첫 줄 = 누가 뭘 어떻게 요청하는가
• 헤더 = 추가 정보 (누구인지, 어디서 왔는지, 어떤 형식인지 등)
• Body = 실제 보내는 데이터 (POST 등에서 주로 등장)

---

2. HTTP Response (서버 → 클라이언트)

서버는 요청을 받고 응답을 돌려준다.
응답도 구조가 있다: 상태라인(Status Line) + 헤더(Header) + Body(본문)

2.1 응답 첫 줄 (상태라인)

예시:

HTTP/1.1 200 OK

구조:

• 프로토콜 버전 (HTTP/1.1, HTTP/2 등)
• 상태 코드 (200, 404, 500...)
• 상태 메시지 (OK, Not Found 등)

이 상태 코드를 보고 "요청이 성공했는지/실패했는지/리다이렉트인지"를 알 수 있다.

2.2 상태 코드 대역별 의미

2xx: 성공(Success)

• 200 OK : 정상적으로 처리됨
• 201 Created : 새로 생성 성공 (POST로 새 리소스 만들 때 자주 사용)

3xx: 리다이렉션(Redirection)

• 요청한 리소스가 다른 위치로 이동했거나, 다른 URL로 가라고 알려줄 때
• 예: 302 Found, 301 Moved Permanently
• 보통 여기에 Location: 헤더가 같이 온다.
  브라우저는 그걸 보고 자동으로 다음 위치로 이동한다.

4xx: 클라이언트 에러(Client Error)
"너(클라이언트)가 뭔가 이상하게 보냈어" 라는 의미.

• 400 Bad Request : 요청 형식 자체가 잘못됨
• 401 Unauthorized : 인증 필요 (로그인/토큰 없음)
• 403 Forbidden : 접근 권한 없음 (너는 봐도 되는 사람이 아님)
• 404 Not Found : 그런 URL/리소스 없음 (잘못된 주소)

5xx: 서버 에러(Server Error)
"내(서버) 쪽에서 문제 났다"

• 500 Internal Server Error : 서버 코드 에러 등
• 502 Bad Gateway, 503 Service Unavailable 등도 자주 본다 (서버 다운, 중간 게이트웨이 문제 등)

보안적으로 중요한 점:

• 에러 페이지가 너무 자세하면 안 된다.
  • 예: 500 Internal Server Error인데, 화면에 "PHP Warning in /var/www/html/login_proc.php on line 12" 라고 그대로 찍히면?
    • 내부 경로, 파일명, 버전 정보까지 유출
• 특히 서버 버전(Apache/2.x.x (Ubuntu) 등)을 그대로 노출하는 건 공격자에게 힌트를 줄 수 있다.
  • 운영환경에서는 이런 노출을 최소화하도록 웹서버 설정을 조정하는 게 일반적이다.

---

3. 요약 (외워둘 것)

1. Request 첫 줄
   • 예: GET /index.html HTTP/1.1
   • "무슨 메서드로", "어떤 경로를", "어떤 프로토콜로" 요청했는지
2. Request 헤더
   • Host: 어느 사이트로 가는 요청인지 (서버 쪽 식별)
   • User-Agent: 누가 보냈는지(클라이언트 정보)
   • Referer: 어떤 페이지에서 넘어왔는지
   • Content-Type / Cookie / Authorization 등도 중요
3. Response 첫 줄
   • 예: HTTP/1.1 200 OK
   • 상태코드로 성공/실패/우회지시(리다이렉트)/에러를 판단
4. 상태코드 범위
   • 2xx: 성공
   • 3xx: 다른 곳으로 가라 (Location 헤더랑 같이 자주 등장)
   • 4xx: 요청 보낸 쪽 문제
   • 5xx: 서버 쪽 문제
5. RESTful 느낌
   • URL은 "무슨 데이터(무슨 리소스)인지"를 나타내는 명사처럼 쓰고
   • 동작(조회/등록/수정/삭제)은 HTTP 메서드(GET/POST/PUT/PATCH/DELETE)로 구분
   • 그래서 /users/123에 DELETE라고만 해도 "아 이 유저 지우는 거구나"라고 알 수 있게 만드는 방식

---

이 정도만 이해하고 있으면

• 웹서버 로그를 읽을 때
• WAF / 보안 로그 볼 때
• Burp나 Fiddler 같은 툴로 패킷 까볼 때
• "왜 403이 떴지?" 같은 상황에서

훨씬 빨리 상황 파악 가능하다.