웹 해킹을 공부하려면 먼저 웹이 정상적으로 어떻게 동작하는지 알아야 한다.
많은 초보자가 SQL Injection, XSS, CSRF 같은 취약점 이름부터 외우기 시작하지만, 실제로는 그보다 먼저 이해해야 할 것이 있다.
웹 브라우저가 서버에 어떻게 요청을 보내는지, 서버는 어떤 방식으로 응답하는지, 사용자는 왜 도메인 이름을 입력하고 서버는 왜 IP 주소를 사용하는지, 그리고 HTML과 JavaScript는 어디에서 실행되는지를 이해해야 한다.
웹 해킹은 결국 정상적인 웹 동작의 틈을 이해하는 공부다.
따라서 첫 번째 목표는 단순하다.
브라우저에 주소를 입력한 순간부터 웹페이지가 화면에 표시될 때까지 어떤 일이 일어나는지 설명할 수 있어야 한다.
이 흐름이 잡히면 이후 HTTP, Cookie, Session, 인증, 인가, API, SQL Injection, XSS 같은 주제들이 서로 연결되기 시작한다.
1. 웹이란 무엇인가
웹은 인터넷 위에서 동작하는 서비스 중 하나다.
여기서 먼저 구분해야 할 것이 있다.
인터넷과 웹은 같은 것이 아니다.
인터넷은 여러 네트워크와 장치가 서로 연결되어 통신할 수 있게 만든 거대한 네트워크 인프라다.
반면 웹은 그 인터넷을 이용해 문서와 서비스를 주고받는 하나의 시스템이다.
인터넷 위에는 웹 말고도 여러 서비스가 존재한다.
예를 들어:
웹
이메일
SSH
FTP
게임 서버
메신저
DNS같은 것들이 모두 인터넷을 이용할 수 있다.
즉:
Internet
↓
여러 서비스 중 하나
↓
Web이라고 이해하면 된다.
웹은 주로 HTTP 또는 HTTPS라는 프로토콜을 이용해 동작한다.
2. 웹의 가장 기본적인 구조
웹은 크게 두 부분으로 나누어 생각할 수 있다.
Client
ServerClient
Client는 서비스를 요청하는 쪽이다.
웹에서는 보통 브라우저가 Client 역할을 한다.
대표적인 브라우저는 다음과 같다.
Chrome
Edge
Firefox
Safari사용자가 브라우저에 주소를 입력하면 브라우저가 서버에 요청을 보낸다.
Server
Server는 요청을 받아 처리하고 결과를 돌려주는 쪽이다.
예를 들어 사용자가 쇼핑몰에 접속한다면 서버는 다음과 같은 일을 할 수 있다.
상품 목록 조회
로그인 처리
주문 정보 저장
회원 정보 조회
결제 요청 처리그리고 처리한 결과를 Client에게 응답한다.
가장 기본적인 구조는 다음과 같다.
Client
브라우저
↓ Request
Server
↓ Response
Client
브라우저이 Request와 Response 구조가 앞으로 웹 해킹 공부의 핵심이 된다.
3. 브라우저는 단순히 화면을 보여주는 프로그램이 아니다
브라우저를 단순히 인터넷 페이지를 보는 프로그램이라고 생각하기 쉽다.
하지만 브라우저는 실제로 굉장히 많은 일을 한다.
예를 들어 사용자가:
https://example.com을 입력하면 브라우저는 내부적으로 여러 작업을 수행한다.
대표적으로:
도메인 이름 확인
DNS 조회
서버와 네트워크 연결
HTTPS 연결
HTTP 요청 생성
서버 응답 수신
HTML 분석
CSS 적용
JavaScript 실행
화면 렌더링
Cookie 저장
추가 리소스 요청같은 작업들이 이어진다.
즉 우리가 화면에서 보는 웹페이지는 수많은 통신과 처리의 결과다.
4. URL이란 무엇인가
브라우저에 입력하는 웹 주소를 보통 URL이라고 부른다.
URL은 Uniform Resource Locator의 약자다.
예를 들어:
https://example.com/products?id=10이라는 주소가 있다고 해보자.
이 URL은 여러 부분으로 나누어 볼 수 있다.
https://example.com/products?id=10여기에서:
https는 Protocol 또는 Scheme이다.
example.com은 Host 또는 Domain Name이다.
/products는 Path다.
?id=10은 Query String이다.
이 구조는 앞으로 웹 해킹에서 매우 중요하게 사용된다.
5. Scheme
URL의 가장 앞부분은 어떤 통신 방식을 사용할지를 나타낸다.
예:
http://
https://웹에서는 대표적으로 HTTP와 HTTPS가 사용된다.
HTTP는 웹에서 데이터를 주고받기 위한 기본 프로토콜이고, HTTPS는 HTTP 통신을 암호화해서 보호하는 방식이다.
예:
http://example.com과
https://example.com은 통신 방식이 다르다.
현대 웹에서는 대부분 HTTPS를 사용한다.
6. Domain Name
사람은 숫자로 이루어진 IP 주소보다 이름을 기억하기 쉽다.
그래서 웹에서는 Domain Name을 사용한다.
예:
google.com
naver.com
example.com하지만 네트워크 통신은 최종적으로 IP 주소를 사용한다.
따라서 브라우저는 먼저 Domain Name에 해당하는 IP Address를 알아내야 한다.
이 과정에서 DNS가 사용된다.
7. DNS는 왜 필요한가
사용자가:
example.com에 접속한다고 가정해보자.
브라우저는 서버의 실제 IP Address를 알아야 한다.
그래서 DNS에게 질문한다.
example.com의 IP 주소가 무엇인가?DNS는 해당 Domain과 연결된 IP Address를 알려준다.
구조를 단순화하면:
사용자
↓
example.com 입력
↓
DNS 조회
↓
IP Address 확인
↓
해당 서버와 통신이전 정보보안 공부에서 DNS를 배웠다면, 이제 웹과 연결해서 이해할 수 있다.
8. 브라우저가 서버 IP를 알아냈다면
DNS를 통해 서버 IP를 알아냈다고 해보자.
예:
example.com
↓
203.0.113.10이제 브라우저는 이 IP 주소의 서버와 네트워크 연결을 시도한다.
HTTPS 웹사이트라면 보통 TCP 443 Port를 사용한다.
따라서 개념적으로는:
203.0.113.10:443과 통신하는 것이다.
여기서:
203.0.113.10은 Server IP,
443은 Port다.
9. Port가 필요한 이유
하나의 서버는 여러 서비스를 동시에 운영할 수 있다.
예를 들어 하나의 컴퓨터에서:
웹 서버
SSH 서버
데이터베이스
DNS가 동시에 실행될 수도 있다.
그러면 IP 주소만으로는 어떤 서비스와 통신해야 하는지 구분하기 어렵다.
그래서 Port 번호를 사용한다.
대표적으로:
80 → HTTP
443 → HTTPS
22 → SSH같은 Port를 자주 볼 수 있다.
즉:
IP
→ 어떤 컴퓨터인가
Port
→ 그 컴퓨터의 어떤 서비스인가라고 이해하면 된다.
10. 웹 서버란 무엇인가
브라우저가 요청을 보내는 대상은 웹 서버다.
웹 서버는 HTTP 요청을 받아 적절한 응답을 돌려주는 프로그램이다.
대표적으로:
Apache
Nginx
Microsoft IIS같은 웹 서버 소프트웨어가 있다.
하지만 현대 웹 서비스에서는 단순히 웹 서버 하나만 있는 경우보다 여러 구성요소가 함께 동작하는 경우가 많다.
예를 들어:
Browser
↓
Web Server
↓
Application Server
↓
Database같은 구조가 매우 흔하다.
11. Web Server와 Application Server
초보자가 가장 헷갈리는 부분 중 하나다.
Web Server와 Application Server는 역할이 조금 다르다.
Web Server
정적인 파일을 제공하거나 HTTP 요청을 받아 뒤쪽 서버로 전달하는 역할을 할 수 있다.
예:
HTML
CSS
JavaScript
Image같은 파일을 제공할 수 있다.
Application Server
실제 서비스 로직을 처리한다.
예를 들어:
로그인 정보 확인
회원가입 처리
게시글 작성
상품 주문
권한 확인같은 작업이다.
현대 웹에서는 이 둘의 역할이 겹치기도 하지만 개념적으로 구분해두면 좋다.
12. Database는 왜 필요한가
웹 서비스는 데이터를 저장해야 한다.
예를 들어 쇼핑몰이라면 다음 정보가 필요하다.
회원 정보
상품 정보
주문 정보
배송 정보
결제 기록이러한 정보를 저장하고 조회하기 위해 Database를 사용한다.
대표적인 Database로는:
MySQL
PostgreSQL
Microsoft SQL Server
Oracle
MongoDB등이 있다.
웹 애플리케이션은 Database에 질문을 보내고 결과를 받아 사용자에게 보여준다.
13. 전체 서버 구조
웹 서비스를 아주 단순화하면 다음과 같다.
Browser
↓
Web Server
↓
Application
↓
Database사용자가 로그인한다고 생각해보자.
브라우저가 서버에 ID와 Password를 보낸다.
Browser
↓
Login Request
↓
Application ServerApplication은 Database에서 해당 사용자를 찾는다.
Application
↓
Database 조회그리고 비밀번호가 올바른지 확인한다.
결과에 따라:
Login Success또는:
Login Failed응답을 브라우저에 보낸다.
이 구조가 앞으로 SQL Injection, Authentication Bypass 같은 취약점을 이해하는 기반이 된다.
14. 정적 웹과 동적 웹
웹페이지는 크게 정적인 형태와 동적인 형태로 생각할 수 있다.
Static Content
미리 만들어진 파일을 그대로 제공한다.
예:
HTML
CSS
Image사용자가 누구든 같은 파일을 받는다.
Dynamic Content
사용자의 요청이나 데이터에 따라 결과가 달라진다.
예를 들어:
내 프로필
내 주문 목록
검색 결과
게시판
추천 상품같은 페이지는 사용자마다 내용이 다를 수 있다.
Application Server와 Database가 이런 동적 처리를 담당한다.
15. HTML
HTML은 웹페이지의 구조를 표현한다.
HTML은 HyperText Markup Language의 약자다.
예를 들어:
<h1>Hello</h1>
<p>Welcome</p>같은 형태다.
브라우저는 서버에서 HTML을 받아 해석하고 화면을 구성한다.
HTML은 프로그램 언어라기보다는 문서 구조를 표현하는 Markup Language다.
16. CSS
CSS는 웹페이지의 디자인을 담당한다.
CSS는 Cascading Style Sheets의 약자다.
예를 들어:
h1 {
font-size: 30px;
}처럼 HTML 요소의 크기, 위치, 글꼴, 배치 등을 지정한다.
구조를 아주 단순화하면:
HTML
→ 구조
CSS
→ 디자인이다.
17. JavaScript
JavaScript는 웹페이지에 동작을 추가한다.
예를 들어:
버튼 클릭
팝업 표시
API 요청
입력값 검사
화면 내용 변경같은 기능을 구현할 수 있다.
JavaScript는 브라우저 안에서 실행될 수 있다.
웹 해킹에서 JavaScript가 중요한 이유는 매우 크다.
특히:
XSS
DOM
API 요청
Client-side Validation
Token
Local Storage같은 개념들이 JavaScript와 연결된다.
18. Frontend란
사용자가 브라우저에서 보고 상호작용하는 영역을 흔히 Frontend라고 부른다.
Frontend에서 주로 사용되는 기술은:
HTML
CSS
JavaScript다.
현대 웹에서는 React, Vue, Angular 같은 Framework도 많이 사용된다.
Frontend는 사용자에게 화면을 보여주고 사용자의 입력을 서버에 전달한다.
19. Backend란
Backend는 서버 쪽에서 동작하는 영역이다.
예를 들어:
로그인 처리
권한 검사
데이터 조회
데이터 저장
API 제공같은 작업을 한다.
Backend에서는 다양한 언어와 Framework가 사용된다.
예:
Java
Spring
Python
Django
Flask
Node.js
PHP
.NET
Go웹 해킹에서는 Backend 로직을 이해하는 것이 매우 중요하다.
대부분의 심각한 취약점은 서버가 사용자의 요청을 어떻게 처리하는지와 관련되어 있다.
20. Client-side와 Server-side
이 두 개념은 웹 해킹에서 매우 중요하다.
Client-side
사용자의 브라우저에서 실행되는 영역이다.
예:
HTML
CSS
JavaScript브라우저 개발자 도구를 통해 내용을 볼 수도 있다.
Server-side
서버에서 실행되는 영역이다.
예:
Database Query
Authentication
Authorization
Business Logic사용자는 서버 내부 코드를 직접 볼 수 없는 경우가 일반적이다.
21. 중요한 보안 원칙
여기서 아주 중요한 보안 원칙이 하나 나온다.
Client는 신뢰할 수 없다.
왜냐하면 사용자는 자신의 브라우저에서 보내는 요청을 수정할 수 있기 때문이다.
예를 들어 웹페이지에서 가격을:
10000원으로 표시한다고 해보자.
사용자가 브라우저 개발자 도구에서 화면을:
100원으로 바꿀 수도 있다.
하지만 단순히 화면을 바꾸는 것 자체는 서버 데이터가 바뀐 것이 아니다.
문제는 서버가 사용자가 보내는 값을 그대로 신뢰할 때 발생한다.
예를 들어 주문 요청이:
price=10000형태로 서버에 전송되고 서버가 이를 검증하지 않는다면 사용자가:
price=100으로 수정할 가능성이 생긴다.
그래서 중요한 보안 원칙은:
중요한 검증은 Server-side에서 해야 한다.
이다.
이 원칙은 앞으로 웹 해킹 전반에 반복해서 등장한다.
22. 브라우저에 주소를 입력했을 때 전체 과정
이제 전체 과정을 연결해보자.
사용자가 브라우저에 다음 주소를 입력했다.
https://example.com/products먼저 브라우저는 URL을 분석한다.
Scheme
→ HTTPS
Domain
→ example.com
Path
→ /products그다음 DNS 조회를 한다.
example.com
↓
DNS
↓
Server IPIP 주소를 얻으면 서버와 연결한다.
Browser
↓
TCP Connection
↓
ServerHTTPS라면 암호화 연결 과정도 진행된다.
그 후 HTTP 요청을 보낸다.
예:
GET /products서버는 요청을 처리한다.
필요하다면 Application Server가 Database를 조회한다.
Web Server
↓
Application
↓
Database결과를 다시 HTTP Response로 보낸다.
Server
↓
HTTP Response
↓
Browser브라우저는 응답받은 HTML을 분석한다.
그리고 필요한 CSS와 JavaScript, Image 등을 추가로 요청한다.
마지막으로 화면을 렌더링한다.
전체 흐름은 다음과 같다.
사용자 URL 입력
↓
DNS 조회
↓
Server IP 확인
↓
Server와 연결
↓
HTTP Request
↓
Web / Application Server 처리
↓
Database 조회 가능
↓
HTTP Response
↓
HTML / CSS / JS 수신
↓
Browser Rendering
↓
웹페이지 표시이 흐름이 웹 해킹에서 가장 기본적인 그림이다.
23. Request와 Response
웹은 대부분 요청과 응답의 반복으로 동작한다.
Client가 Request를 보낸다.
Client
↓
Request
↓
ServerServer는 Response를 보낸다.
Server
↓
Response
↓
Client예를 들어 사용자가 게시판을 연다.
게시판 보여줘라는 요청을 서버에 보낸다.
서버는 Database에서 게시글을 조회하고 결과를 응답한다.
사용자가 글을 작성하면 또 새로운 Request가 발생한다.
즉 웹사이트를 사용하는 동안 수많은 Request와 Response가 계속 발생한다.
이후 웹 해킹에서는 거의 항상 이 질문을 하게 된다.
어떤 Request를 보냈는가?
사용자가 어떤 값을 변경할 수 있는가?
Server는 이 값을 검증하는가?
Response에는 어떤 정보가 포함되어 있는가?24. 개발자 도구
웹 해킹을 공부하면 브라우저의 Developer Tools를 자주 사용한다.
Chrome이나 Edge에서 보통:
F12를 누르면 열 수 있다.
여기에는 여러 기능이 있다.
대표적으로:
Elements
Console
Network
Application
Sources가 있다.
25. Elements
Elements에서는 현재 웹페이지의 HTML 구조를 확인할 수 있다.
웹페이지에 표시된 글자나 버튼의 HTML을 볼 수 있다.
내용을 임시로 변경할 수도 있다.
다만 여기서 변경한 것은 대부분 내 브라우저 화면에만 영향을 준다.
서버 데이터가 변경된 것은 아니다.
이 차이는 매우 중요하다.
26. Network Tab
웹 해킹 공부에서 가장 중요한 기능 중 하나다.
Network Tab에서는 브라우저가 서버와 주고받는 HTTP 요청을 볼 수 있다.
예를 들어 페이지를 새로고침하면:
document
css
js
image
api등 수많은 요청이 나타날 수 있다.
각 요청을 클릭하면:
URL
Method
Status Code
Request Headers
Response Headers
Request Body
Response Body같은 정보를 볼 수 있다.
앞으로 HTTP 공부를 할 때 계속 사용하게 된다.
27. Application Tab
Application Tab에서는 웹 브라우저가 저장하고 있는 여러 데이터를 확인할 수 있다.
대표적으로:
Cookies
Local Storage
Session Storage등을 볼 수 있다.
이것들은 이후 로그인, Session, Token과 연결된다.
28. 웹 해킹은 무엇을 보는 공부인가
웹 해킹은 무작정 서버를 공격하는 공부가 아니다.
핵심은 Client와 Server 사이의 신뢰 관계를 분석하는 것이다.
예를 들어 정상적인 사용자는 다음 요청을 보낸다고 하자.
/user?id=100서버는 ID 100 사용자의 정보를 보여준다.
그렇다면 공격자는 생각한다.
id=101로 바꾸면 어떻게 될까?이때 서버가 권한을 제대로 확인하지 않으면 다른 사용자의 데이터가 노출될 수 있다.
이것이 나중에 배우게 될 IDOR 같은 취약점과 연결된다.
즉 웹 해킹의 사고방식은 다음과 같다.
정상 Request 확인
↓
사용자가 변경 가능한 값 찾기
↓
값 변경
↓
Server가 어떻게 반응하는지 확인
↓
검증 또는 권한 통제가 제대로 되어 있는지 분석29. Client는 조작할 수 있다
웹 해킹에서 가장 중요한 전제 중 하나는:
사용자가 보내는 데이터는 조작될 수 있다.
라는 점이다.
웹페이지에서:
<input type="hidden" value="admin">처럼 숨겨진 값이 있어도 사용자는 개발자 도구를 이용해 볼 수 있다.
JavaScript에서:
if (user == "admin")같은 검사를 하더라도 사용자는 JavaScript를 분석하거나 수정할 수 있다.
Request에:
role=user가 포함되어 있다면:
role=admin으로 변경하려는 시도를 할 수도 있다.
따라서 서버는 Client가 보내는 값을 그대로 신뢰하면 안 된다.
30. 웹 해킹의 핵심 질문
앞으로 모든 취약점을 공부할 때 아래 질문을 계속 반복하게 된다.
사용자가 무엇을 입력할 수 있는가?
어떤 Request가 서버로 전달되는가?
사용자가 Request를 수정할 수 있는가?
Server는 입력값을 검증하는가?
Server는 사용자의 권한을 확인하는가?
Response에 필요 이상의 정보가 포함되어 있는가?
Client-side 검증만 존재하는가?
Server-side 검증도 존재하는가?취약점 이름은 달라도 결국 많은 웹 취약점이 이 질문들에서 출발한다.
31. 정상 웹 구조와 공격 지점
웹 구조를 다시 보자.
Browser
↓
Web Server
↓
Application
↓
Database이 각각의 위치에서 서로 다른 문제가 발생할 수 있다.
예를 들어 Browser와 관련해서는:
XSS
CSRF같은 문제가 나타날 수 있다.
Application Logic에서는:
Authentication Bypass
Authorization Failure
IDOR같은 문제가 발생할 수 있다.
Database와 연결되는 과정에서는:
SQL Injection같은 문제가 발생할 수 있다.
Server가 외부 시스템과 통신하는 과정에서는:
SSRF같은 취약점이 생길 수 있다.
파일을 처리하는 과정에서는:
File Upload
Path Traversal같은 취약점이 발생할 수 있다.
즉 취약점은 무작위로 존재하는 것이 아니라 웹 시스템의 각 구성 요소와 데이터 흐름에서 발생한다.
32. 앞으로 HTTP를 깊게 공부해야 하는 이유
웹 해킹에서는 HTTP를 제대로 알아야 한다.
왜냐하면 웹 해킹 도구들이 결국 HTTP Request를 보고 수정하는 도구이기 때문이다.
예를 들어 Burp Suite 같은 도구를 사용하면 다음과 같은 Request를 직접 보게 된다.
GET /account?id=100 HTTP/1.1
Host: example.com
Cookie: session=abcdef처음에는 낯설어 보이지만 HTTP를 이해하면 다음처럼 읽을 수 있다.
/account 요청
id=100 전달
example.com 서버
session Cookie 전달그리고 공격자는 여기서:
id=100을:
id=101로 바꾸거나,
Cookie를 변경하거나,
Header를 추가하거나,
Body를 변경하면서 서버의 동작을 분석한다.
즉 HTTP를 읽을 수 있다는 것은 웹 해킹의 기본 언어를 읽을 수 있다는 뜻이다.
33. 웹페이지와 웹 애플리케이션의 차이
예전 웹은 주로 정보를 보여주는 정적인 페이지가 많았다.
현대 웹은 단순한 페이지라기보다 프로그램에 가깝다.
예를 들어:
YouTube
Netflix
Gmail
Instagram
온라인 쇼핑몰
은행 서비스
회사 ERP같은 서비스는 모두 복잡한 웹 애플리케이션이다.
사용자 입력을 받고, Database와 통신하고, 권한을 관리하며, API를 호출한다.
그래서 현대 웹 보안에서는 단순 HTML보다:
HTTP
API
Authentication
Authorization
Session
Token
Database
Business Logic을 이해하는 것이 훨씬 중요하다.
34. 웹 해킹에서 가장 중요한 두 개념
앞으로 계속 반복되는 두 가지 개념이 있다.
Authentication
Authentication은:
당신이 누구인가?
를 확인하는 과정이다.
예:
ID
Password
OTP
BiometricAuthorization
Authorization은:
당신이 이 작업을 할 권한이 있는가?
를 확인하는 과정이다.
예를 들어 일반 직원과 관리자가 있다고 해보자.
둘 다 로그인할 수 있다.
즉 둘 다 Authentication은 성공했다.
하지만 관리자 페이지에 접근할 수 있는 사람은 관리자뿐일 수 있다.
이것은 Authorization의 영역이다.
앞으로 이 둘은 별도의 Day에서 매우 깊게 공부한다.
35. 웹 해킹에서 URL 하나를 보는 방법
앞으로 웹 주소를 보면 그냥 문자열로 보지 말고 구조적으로 보는 습관을 들이면 좋다.
예를 들어:
https://shop.example.com/product?id=100을 보면:
https
→ Protocol
shop.example.com
→ Host
/product
→ Path
id=100
→ Parameter라고 분석한다.
그리고 보안 관점에서는 다음 생각으로 이어진다.
id 값은 사용자가 변경할 수 있을까?
id=101로 변경하면?
존재하지 않는 id라면?
다른 사용자의 상품 또는 데이터가 나타날까?아직 직접 공격하는 단계가 아니라 이런 분석 사고방식을 만드는 것이 중요하다.
36. 서버는 브라우저를 믿을 수 없다
웹 보안의 핵심을 한 문장으로 표현하면 이 말이 중요하다.
서버는 브라우저가 보내는 데이터를 신뢰해서는 안 된다.
브라우저 화면에서 보이지 않는 값도 바꿀 수 있고, JavaScript 제한도 우회할 수 있고, HTTP Request 자체도 수정할 수 있기 때문이다.
따라서 Server는 항상 다음을 해야 한다.
입력값 검증
Authentication 확인
Authorization 확인
데이터 타입 확인
허용 범위 확인이 검증 중 하나가 빠지면 취약점으로 이어질 수 있다.
37. 웹 해킹을 공부하면서 기억해야 할 관점
웹사이트를 사용자 입장에서 보면:
버튼
메뉴
검색창
게시판
로그인이 보인다.
하지만 보안 관점에서는 다음처럼 봐야 한다.
Request는 무엇인가?
Parameter는 무엇인가?
Server는 어떤 값을 받는가?
어떤 Database Query가 발생할까?
사용자 권한은 어디서 확인할까?
Session은 어떻게 유지될까?
Response에는 어떤 데이터가 포함될까?즉 화면보다 데이터 흐름을 보는 습관을 만들어야 한다.
해킹 1 핵심 요약
Web
인터넷 위에서 HTTP/HTTPS를 이용해 정보를 주고받는 서비스다.
Client
서비스를 요청하는 쪽이다.
웹에서는 주로 Browser가 Client 역할을 한다.
Server
Client의 요청을 받아 처리하고 결과를 반환한다.
Request / Response
웹 통신의 기본 구조다.
Client
↓ Request
Server
↓ Response
ClientURL
웹 리소스의 위치를 표현한다.
예:
https://example.com/product?id=10구조:
https
→ Scheme
example.com
→ Domain
/product
→ Path
id=10
→ Query ParameterDNS
Domain Name을 IP Address로 변환한다.
example.com
↓
DNS
↓
Server IPPort
하나의 서버에서 어떤 서비스와 통신할지를 구분한다.
대표적으로:
80 → HTTP
443 → HTTPSWeb Server
HTTP Request를 받고 Response를 제공하는 서버 프로그램이다.
Application Server
로그인, 게시글, 주문, 권한 처리 같은 실제 서비스 로직을 수행한다.
Database
서비스가 사용하는 데이터를 저장하고 조회한다.
Frontend
사용자의 Browser에서 보여지고 실행되는 영역.
대표 기술:
HTML
CSS
JavaScriptBackend
Server에서 실행되는 영역.
대표적으로:
Authentication
Authorization
Database Access
Business Logic
API등을 처리한다.
Client-side
사용자의 Browser에서 실행된다.
사용자가 분석하거나 변경할 수 있다는 전제로 생각해야 한다.
Server-side
Server에서 실행된다.
중요한 보안 검증은 Server-side에서 이루어져야 한다.
가장 중요한 보안 원칙
Client는 신뢰할 수 없다.사용자는 Browser에서 보내는 값을 변경할 수 있기 때문에 Server는 반드시 입력값과 권한을 검증해야 한다.
웹 요청 전체 흐름
오늘 내용 중 가장 중요한 흐름이다.
사용자
↓
Browser에 URL 입력
↓
Domain 확인
↓
DNS 조회
↓
Server IP 확인
↓
Server와 Network 연결
↓
HTTP Request 전송
↓
Web Server
↓
Application
↓
필요하면 Database 조회
↓
HTTP Response
↓
Browser
↓
HTML / CSS / JavaScript 처리
↓
화면 표시앞으로 배우게 될 웹 취약점들은 대부분 이 흐름 어딘가에서 발생한다.
Browser
↓
HTTP
↓
Application
↓
Database따라서 웹 해킹을 공부할 때 중요한 것은 취약점 이름을 많이 외우는 것이 아니라 웹 시스템의 데이터가 어디에서 어디로 이동하고, 그 과정에서 무엇을 신뢰하며, 어디에서 검증하는지를 이해하는 것이다.
해킹 1에서는 이 전체 구조를 먼저 잡았다.
다음 해킹 2에서는 웹 해킹의 핵심 언어인 HTTP Request 자체를 아주 깊게 다룬다. Request Line, Method, Path, Query Parameter, Header, Body, Host, Content-Type 등이 실제로 어떤 의미인지 하나씩 분해해서 이해하게 된다.
'쓰윽터디 > 정보 보안' 카테고리의 다른 글
| [IT Security] 보안 공부 Day.05 (0) | 2026.10.09 |
|---|---|
| [IT Security] 정보 보안 공부 하기 Day.02 (0) | 2026.09.28 |
| [IT Security] 정보 보안 공부 하기 Day.01 (0) | 2026.09.26 |