1. 웹 통신 기초
1-1. 클라이언트 서버 구조
웹 클라이언트는 웹 서버에 페이지를 요청하고, 서버가 응답한 결과를 화면에 출력한다. 쉽게 말해서 요청하는 것이 클라이언트이다. 클라이언트는 브라우저(웹 애플리케이션)라고도 부른다. 웹 서버는 클라이언트로부터 요청을 받은 페이지를 찾아서 CGI를 해석하거나 수행하고, 그 결과를 html,javascript,css 등을 클라이언트에게 전송한다. 여기서도 쉽게 말해서 요청을 받아 응답을 클라이언트에게 보내는 걸 서버라고말한다.
❓ 웹에서 서버와 클라이언트 관계
- 웹에서 클라이언트는 서버에게 요청을 보내고, 서버는 그 요청을 받아 응답을 보낸다.
💻 CGI(Common Gateway Interface: 공통 게이트웨이 인터페이스로 웹 서버와 프로그램을 연결해주는 규칙이다.
1-2. HTTP 프로토콜 이해
HTTP(Hyper Text Transfer Protocol)는 클라이언트와 서버 간에 데이터를 주고받기 위한 프로토콜로 기본적으로 데이터를 평문으로 전송하며, 이후 이미지·파일·JSON 등 다양한 데이터 형태를 주고받을 수 있도록 발전하였고, HTTP 프로토콜을 이용해 파일을 주고 받는 서버는 요청과 응답 구조로 동작하며, 서버와 클라이언트의 연결 상태를 유지하지 않는 stateless한 프로토콜이여서 서로의 연결 상태를 기억하지 않지만, 이를 보완하기 위해 쿠키와 세션을 사용해 상태를 유지한다.
❓ HTTP와 HTTPS의 차이점
- HTTP는 80번 포트를 사용하며, 데이터를 평문으로 전송하지만 HTTPS는 443번 포트를 사용하고 HTTP에 SSL을 적용해 암호화하여 전송한다.
💻 하이퍼링크를 포함한 텍스트
💻 JSON : HTTP 통신에서 요청과 응답 바디에 포함되어 데이터를 구조적으로 표현하는 데 사용되는 경량 데이터 포맷
1-3. HTTP 요청(Request)구조
✅ 요청 메소드 : 서버에 어떤 방식으로 자원을 처리할지 알려주는 역할(요청 방식)
✅ GET,POST,HEAD,OPTIONS,PUT 등이 있음
✅ 자원(Resource): URL로 식별 가능한 모든 대상으로 정적인 파일뿐만 아니라 사용자, 게시글과 같은 논리적인 데이터까지 포함
✅ ?직전까지나 파일 경로까지는 URL(자원 위치), 전체는 URI(자원 식별자)
✅ 요청 헤더: 키와 값 방식
✅ Host : 호스트 주소(IP 혹은 도메인)
✅ Accept: 클라이언트가 받을 수 있는 컨텐츠
✅ user-agent: 요청을 보낸 클라이언트의 브라우저 및 실행 환경 정보
✅ cookie: 쿠키
✅ 요청 바디(엔터티) : 기타 정보 전달
💻 HTTP여도 포트번호가 다르면 도메인 뒤에 포트번호 붙여야됨(예:8080)
💻 %20은 공백 - URL은 공백이 있으면 짤림
💻 #(태그)은 현재 페이지에서의 특정 위치 - 목차가 있는 경우 보통 #이 붙음
💻 &는 파라미터가 한개 이상
💻 파라미터가 URL에 보이는 경우 GET 요청 방식
| 요청 메소드 | |
| GET | - 자원을 요청할 때 사용하는 메소드 - 서버의 자원을 조회(요청)하는 용도로 사용 - 요청 메시지에 Body가 없음 - 응답하는 Body가 존재하며 요청한 데이터를 전달 받음 - 요청 데이터가 URL 파라미터로 노출됨 - 서버의 데이터를 변경하지 않음 - 암호화 통신을 해도 GET 요청을 보임 |
| POST | - 서버에 데이터를 전달하고 처리를 요청하는 메소드 - 요청 Body의 엔터티(Entity)를 자원으로 전달함 - 요청과 응답 모두 Body를 가질 수 있음 - 서버에 데이터 저장 또는 처리를 요청할 때 사용 - URL에 데이터가 노출되지 않고 Body에 포함 - 서버의 상태나 데이터를 변경할 수 있음 - 요청 바디에 데이터를 넣었을 때 파라미터 값이 안보임 - 파일 업로드할 때 사용 |
| HEAD | - 서버의 응답 헤더 정보만 요청하는 메소드 - 요청과 응답 모두 Body가 없음 - 응답에서 Header만 전달 - 서버 측 데이터의 존재 여부 및 메타 정보를 확인 - 실제 데이터(Body)는 전송되지 않음 - 리소스 크기, 수정 여부 등을 사전 확인할 때 사용됨 |
| OPTIONS | - 서버에서 지원하는 HTTP 메소드를 확인하는 메소드 - 서버가 어떤 HTTP 메소드를 지원하는지 확인 - 요청 Body는 선택사항 - 응답에는 Body가 포함될 수 있음 - Allow 헤더를 통해 허용된 메소드 목록을 제공 |
| PUT | - 자원의 전체를 수정하는 메소드 - 서버의 자원을 전체 수정(덮어쓰기) 함 - 요청과 응답 모두 Body를 가질 수 있음 - 전달된 데이터로 자원을 완전히 대체 - 서버의 데이터를 직접 변경 - 잘못 사용될 경우 보안 취약점이 발생할 수 있음(제일 취약) |
1-4 . HTTP 응답(Response) 구조
✅ Body는 데이터가 들어감
✅ 응답 헤더
- date: 통신한 날짜
- server : 서버 애플리이션
- content-type : 바디 데이터의 유형
- content-length : 바디 데이터의 크기
- 예) <html>
<head>
...
...
✅ 서버가 응답하는 데이터를 추가적으로 설명하는 데이터를 헤더
✅ 데이터의 데이터를 메타데이터(대표적으로 헤더)
✅ 응답 라인: 버전, 상태 코드, 상태 메시지(예: http/1.1 200 ok - 응답 코드)
✍️1xx - Informational : 요청이 수신되어 처리중
✍️2xx - Success : 요청 성공, 요청을 받았는데 요청이 이상없고 잘 응답했다는 코드
- 200(OK) : 잘 응답한거면 200이 응답코드에 뜸
✍️3xx - Redirection(방향 바꿈) : 요청은 잘 받아서 해석했는데 너가 원하는 응답은 다른곳에 있어
- 301(Moved Permanently) : 요구한 데이터는 변경된 URL에서 찾음(서버에 요청을 했는데 요구한 응답이 다른 서버에 있음), 영구적으로 이동(영구 리다이렉션)
- 302(Found): 다른 URL이 있음, 웹 사이트에 잘 방문함, 일시 리다이렉션
✍️4xx - Client Error : 클라이언트 오류, 요청에 문제가 있음
- 403(Forbidden) : 요청 거부, 요청은 알아들었지만 응답은 안함(접근 권한이 불충분), 정상적인 페이지에 안 들어가지면 아이피 차단됨
- 404(Not Found) : 리소스가 없는 상태, 못 찾겠다!, 에러가 뜨는 가장 큰 이유는 오타일 수 있음, 요청은 잘 알아들었지만 내 서버에서 자원을 찾는 과정에서 자원이 없다(디렉터리가 없다)
✍️5xx - Server Error : 서버 오류, 응답에 오류가 있음
- 500(Internal Server Error) : 서버가 요청을 처리 못하고 서버안에서 에러가 난거임, 에러메시지가 뜨면 더 취약하고 에러가 나면 공격자 입장에선 너무 좋다.
- 503(Service Unavailable) : 서비스가 불가능한 상태이며 서비스 구축과정에서 일어남, 서버가 내려가거나 종료 또는 재시작할때 뜰 수 있음
1-5. Web Server와 Web Application Server의 차이점
웹 서버는 정적인 콘텐츠를 제공하고, 웹 애플리케이션 서버는 연산과 데이터베이스 연동을 통해 사용자 별로 다른 동적 콘텐츠를 제공한다. 웹 서버 같은 경우는 아파치나 엔진엑스등이 있고, 웹 애플리케이션 서버는 톰켓이 있다.
Web APPlication Server(Tomcat,WebLogic) : 정적,동적 다함, 연산을 해야됨, 데이터베이스랑 연동하고 동적은 누가 들어오는지에 따라서 페이지가 다르다. 또한 로그인 페이지나 회원가입이 있으면 무조건 데이터베이스랑 연동되어있다.
- 서버가 요청받고 계산해서 결과 생성 > 동적-예: board.php, 서버 입장에서 PHP를 실행하고 DB조회
Web Server(Apache,NGinx) : 정적인 콘텐츠, 누가 들어오든 똑같은 페이지, 서버가 그냥 파일 전달(정적-예: index.html)
※ DB 연동은 이론적으로 웹 서버에서도 가능하지만(소규모일경우), 거의 WAS에서 담당함
구조 : [Client] 👉 [Web Server-정적파일, 프록시 서버역할] 👉 [WAS-비즈니스 로직, DB 연동] 👉 [DB]
1-6. 클라이언트 언어(HTML, Javascript, CSS)
- 사용자의 브라우저가 처리하는 언어
- 사용자와 서버 간의 인터페이스로 동작
- 사용자와 서버 사이 대화형 웹 페이지 제공
- 서버 요청을 보내고 데이터를 가져옴
- HTML : 브라우저에 의해 해석되어 구조를 만드는 언어
- Javascript : 연산이 없는 HTML을 대신 연산을 수행하는 동적 행위를 하는 언어
- CSS: 디자인용, HTML을 아름답게 표현하는데 사용
- 클라이언트 측 언어는 클라이언트에서 보임(브라우저)
- 서버측 언어의 결과가 브라우저에 보여짐
- 서버측 언어는 클라이언트에 안보임
- 브라우저가 해석하고 화면에 표시
1-7. 서버측 언어(PHP,ASP.net,JSP,Python)
- 서버에서 동작하는 언어
- 사용자의 입력(파라미터) 처리
- 요청한 페이지를 전달
- 데이터베이스와 상호작용
- 처리된 데이터를 사용자 측 언어로 변환(클라이언트 언어)
- 사용자에게 연산하는 과정은 보이지 않음
- 결과를 클라이언트 언어로 줌
2. 인코딩(Encoding)
정보의 형태나 형식을 변환하는 처리 방식이며, 암호화와는 다르다. 이유는 암호화는 보안을 위해 데이터를 숨기는 것이고, 인코딩은 데이터를 전송이나 저장하기 위한 형식으로 변환하는 과정이다. 데이터의 길이를 줄이는 용도로 사용되고 기본 인증에도 사용된다.
○ 문자형 인코딩
- 문자를 컴퓨터가 이해할 수 있는 0과 1형태로 변환
- EBCDIC, ASCII, Unicode
○ 오디오형 인코딩
- 음성이나 음악 데이터를 디지털 신호로 변환
- MP3, WAV
○ 웹 관련 인코딩
- 웹 환경에서 데이터를 안전하게 전달하기 위해 사용
- URL 인코딩, Base64 인코딩
3. URL 인코딩 - 웹만 있음
특정 문자나 구분자 기호인 % 뒤에 16진수 값을 붙여서 URL에 표현하는 방식이며 문자를 안전하게 웹 서버에 전달한다. 즉 특수한 기능을 가진 문자인 메타문자를 브라우저가 인코딩하여 전달한다.
예) 공백 > %20
& > %26
https://example.com/search?q=hello world
아래가 URL 인코딩 됨
https://example.com/search?q=hello%20world
4. Base64 인코딩
64개의 문자(A-Z, a-z, 0-9, +, /)로 데이터를 표현하며, 바이너리 데이터를 텍스트로 안전하게 전달한다.
예) Hello > Base64 인코딩 > SGVsbG8=
- =은 패딩이고 6비트 단위를 맞추기 위해 사용됨
※ 디코딩(Decoding) : 변환된 데이터를 원래 값으로 되돌려줌
5. 쿠키와 세션
우선 쿠키와 세션이 등장하게된 배경은 HTTP 서버와 클라이언트의 연결 상태를 유지하지 못하는 stateless 프로토콜이어서 로그인 등 상태 유지를 위해 쿠키가 등장했지만, 클라이언트에 데이터를 저장하는 보안 문제를 해결하기 위해 세션이 등장하여 서버에 데이터를 저장하고 클라이언트에는 세션 ID만 전달하도록 발전하였다.
쿠키
- 쿠키는 상태를 유지함(stateful) 서비스를 지원하기 위해서 고객에게 상태가 유지되게 보이게 함
- 상태를 유지함(stateful), 서버가 클라이언트의 상태를 보존
- 웹 서비스에 방문할 때 마다 수시로 정보가 변경될 수 있음
- 웹 서버가 클라이언트 컴퓨터에 저장하는 작은 기록 정보
- 요청을 보낼때마다 쿠키정보가 전송됨
- 단점 : 많은 트래픽 발생, 쿠키 유출에 따른 보안 문제
세션
- 쿠키의 문제와 보안적 이슈(쿠키가 클라이언트에 저장되기 떄문에)를 해결하기 위해 등장
- 서버 데이터베이스에 정보를 저장
- 클라이언트는 쿠키로 전달 받아 메모리에 저장
- 단점 사용자 방문이 많은 서버의 경우 데이터베이스를 이용하기에 많은 비용 발생
- 세션 ID(서버와 클라이언트를 연결하는 열쇠)는 브라우저에 쿠키형태로 저장됨 > 클라이언트가 요청할 때마다 세션ID를 보내야 서버가 클라이언트의 세션 데이터를 찾아서 응답하기 때문이다. 쉽게 말해 “클라이언트가 세션 ID를 보내야 서버가 해당 세션 데이터와 연결해서 응답을 줄 수 있다”
- 서버는 상태를 유지하지 않기때문에 요청마다 클라이언트가 자기 ID를 보내야됨
※ 쿠키는 클라이언트에 저장되고 세션은 서버에 저장된다.
'Web 취약점' 카테고리의 다른 글
| Web 취약점 진단 - 취약한 패스워드 복구 (0) | 2026.01.04 |
|---|---|
| Web 취약점 진단 - 불충분한 인증 (0) | 2026.01.04 |
| Web 취약점 진단 - 크로스사이트 스크립팅 (0) | 2025.12.30 |
| Web 취약점 진단 - 약한 문자열 강도 (0) | 2025.12.30 |
| Web 취약점 진단 - 악성 콘텐츠 (0) | 2025.12.30 |