본문 바로가기
Web Hacking

[Web Hacking] 요청과 응답 (Request, Response)

by spareone 2026. 1. 30.

[그림 1] 웹 작동 방식 구상도

[그림 1] 조직도의 흐름대로 실제로 브라우저를 통해 네이버에 접속한다고 가정합니다.

 

[그림 2] Burp Suite로 확인한 Request / Response

사용자는 브라우저를 통해 요청Request을 보내고, 서버는 이에 맞는 응답Response을 보내 줍니다.

 

 

[그림 3] Network로 확인한 서버에서 응답한 자원

웹은 주로 HTTP를 사용하며, HTTP는 기본적으로 stateless 이기 때문에, 사용자의 상태를 저장하지 않습니다.

사용자가 각각 요청을 보내면 다 별개로 응답을 해 줍니다.

 

네이버의 메인 페이지 html 코드를 응답받았는데, css가 다른 경로에 존재한다. -> 서버에게 다시 CSS를 요청해서 받습니다.

html 코드를 또 확인하니 사진 경로가 보인다 -> 서버에게 해당 경로에 있는 사진을 요청해서 받습니다.

[그림 3]처럼 개발자 도구의 Network 탭에서 요청/응답해서 받은 자원들을 확인할 수 있습니다.

 

브라우저는 위의 요청/응답 과정을 여러 번 거쳐 코드를 렌더링하여 하나의 웹 페이지가 로딩됩니다.

 

지금은 인터넷 속도가 빨라서 더 많은 요소로 사이트를 이쁘게 꾸밀 수 있지만

과거에는 느렸기 때문에, 속도를 위해 투박한 디자인의 사이트가 많았습니다.

특히 과거 피쳐폰에서 인터넷을 하면 스크롤을 내릴 때마다 0.5초정도 기다려야 했습니다.

 

HTTP 특징

- 1회성 연결

- 상태 저장 안함stateless

- 서버에서 클라이언트로 먼저 전송하지 않는다 (요청을 받아야 응답)

 

하지만 사용자가 권한도 없는데 서버에게 달라고 요청할 수도 있습니다.

서버는 이를 잘 걸러내어 줄 사람에게만 주어야 합니다.

근데 서버는 클라이언트 상태를 저장하지 않는다면서요???

 

그래서 세션과 쿠키를 사용합니다.

서버는 세션과 쿠키를 통해 사용자의 신원이나 정보를 확인합니다.

 

- Session: 서버에 저장

- Cookie: 클라이언트에 저장

 

 

반면 클라이언트의 상태를 서버가 알아야 할 필요가 있고, 실시간 통신이 필요한 경우 TCP를 사용합니다.

웹보다는 게임 클라이언트 등에서 많이 사용합니다.

 

TCP 특징

- 3 way handshaking으로 안정적인 연결 보장

- 로그인을 하면 서버에서 일방적으로 클라이언트로 전송 (클라이언트 상태를 알기 때문에 가능)

 


 

서버가 응답할 때는 응답 상태에 따른 응답 코드Response Code를 제공합니다.

 

[그림 2]의 응답 패킷 1번 라인을 보면 HTTP/[버전] 200 OK 를 확인할 수 있습니다.

이는 응답이 제대로 되었다는 이야기입니다.

 

[그림 4] 404 Not Fount

다른 상태를 응답하는 경우도 있습니다. [그림 4]에서는 없는 경로를 나타내는 404 에러를 응답으로 받았습니다.

 

코드 이름 의미
100 Continue 요청 계속 보내도 됨
101 Switching Protocols 프로토콜 전환(예: WebSocket)
102 Processing 처리 중(WebDAV)
200 OK 정상 처리
201 Created 생성 완료
202 Accepted 접수됨(비동기 처리 예정)
204 No Content 성공, 본문 없음
206 Partial Content 일부만 전송(Range)
301 Moved Permanently 영구 이동(캐시 가능)
302 Found 임시 이동(전통적 의미)
303 See Other 다른 URL로 GET 유도
304 Not Modified 캐시 사용(변경 없음)
307 Temporary Redirect 임시 리다이렉트(메서드 유지)
308 Permanent Redirect 영구 리다이렉트(메서드 유지)
400 Bad Request 잘못된 요청
401 Unauthorized 인증 필요(로그인/토큰)
403 Forbidden 권한 없음
404 Not Found 리소스 없음
405 Method Not Allowed 메서드 불가
406 Not Acceptable Accept 조건 불만족
408 Request Timeout 요청 시간 초과
409 Conflict 충돌(중복/버전)
410 Gone 영구 삭제됨
413 Payload Too Large 요청 본문 큼
415 Unsupported Media Type Content-Type 미지원
418 I’m a teapot (농담/테스트용)
429 Too Many Requests 요청 과다(레이트리밋)
500 Internal Server Error 서버 내부 오류
501 Not Implemented 미구현
502 Bad Gateway 게이트웨이/프록시 오류
503 Service Unavailable 서비스 불가(과부하/점검)
504 Gateway Timeout 게이트웨이 타임아웃

 

주요 응답코드 테이블입니다.

200, 403, 404, 500 등의 주요 코드들을 알아놓으면 편리합니다.

 


 

500에러를 주목해야 합니다.

Internal Server Error -> 서버 내부 오류를 의미합니다.

접속하자마자 500이 나오면 개발자가 코드를 오류낸 것인데,

특정 액션을 취한 뒤 (이상한 것으로 검색 등) 500이 나오면 공격 포인트가 될 수 있습니다.

 

EX) 검색 영역에서 ' 입력하고 검색했는데 500 에러 -> SQL 처리하는 것에 오류 발생 -> 어라

 

이를 방지하기 위해 개발할 때 사용자를 전적으로 믿지 말고,

사용자 입력 값을 확인하여 예외처리와 필터링을 확실하게 해야 합니다.

 

사용자가 시키는 대로 사용할 것이라는 생각을 하면 안 됩니다.

'Web Hacking' 카테고리의 다른 글

[Web Hacking] 웹의 작동 원리와 개발 방식  (0) 2026.01.30

댓글