تا اینجا مسیر ما این بوده:

Scope
   ↓
Recon
   ↓
Enumeration
   ↓
HTTP Analysis
   ↓
Burp Suite

حالا وقت آن رسیده یک سؤال مهم‌تر بپرسیم:

داده از کجا وارد برنامه می‌شود؟

یک Web Application فقط صفحه و دکمه نیست.

کاربر دائماً اطلاعاتی وارد برنامه می‌کند:

Username
Password
Search
ID
Email
File
JSON
Cookie
Query Parameter
Path Parameter

هرکدام از این‌ها می‌تواند بخشی از Attack Surface باشد.

۱. Input چیست؟

Input یعنی داده‌ای که برنامه از یک منبع خارجی دریافت می‌کند.

مثلاً:

User
  ↓
Input
  ↓
Application
  ↓
Processing
  ↓
Response

این Input می‌تواند از Browser، API، Cookie یا حتی Header دریافت شود.

مثلاً:

GET /search?q=phone HTTP/1.1

اینجا:

q=phone

یک Input است.

۲. چرا Input برای Pentester مهم است؟

چون برنامه باید تصمیم بگیرد با این داده چه کار کند.

مثلاً:

Input
  ↓
Validate
  ↓
Process
  ↓
Database
  ↓
Response

اگر برنامه ورودی را به شکل نادرست مدیریت کند، بسته به Context ممکن است زمینه‌ای برای آسیب‌پذیری ایجاد شود.

اما یک نکته مهم:

وجود Input به معنی وجود Vulnerability نیست.

ما ابتدا Input را پیدا می‌کنیم، بعد رفتار برنامه را بررسی می‌کنیم.

۳. انواع Input

در Web Application ورودی‌ها می‌توانند در نقاط مختلف قرار داشته باشند.

Query Parameter

مثلاً:

/search?q=phone

در اینجا:

q

پارامتر است.

Path Parameter

مثلاً:

/api/products/15

عدد:

15

ممکن است شناسه یک Resource باشد.

Body

مثلاً:

{
  "email": "user@example.test",
  "name": "Ali"
}

داده داخل Request Body قرار گرفته است.

Header

مثلاً:

User-Agent: Browser

Header هم می‌تواند داده‌ای باشد که برنامه آن را پردازش می‌کند.

Cookie

مثلاً:

Cookie: session=example

Cookie نیز بخشی از داده‌های ارسالی Client است.

۴. Input Map بسازیم

یک Pentester حرفه‌ای برای برنامه Input Map می‌سازد.

مثلاً:

Application
│
├── Authentication
│   ├── email
│   └── password
│
├── Search
│   └── q
│
├── Product
│   └── id
│
├── Account
│   └── user identifier
│
└── API
    ├── JSON fields
    └── Query parameters

این نقشه به ما نشان می‌دهد:

کجاها باید رفتار برنامه را بررسی کنیم؟

۵. Input Surface با Attack Surface فرق دارد

این دو مفهوم را قاطی نکن.

Input Surface

جاهایی که داده وارد برنامه می‌شود.

Attack Surface

مجموعه نقاطی که می‌توانند در معرض تعامل یا سوءاستفاده امنیتی قرار بگیرند.

به شکل ساده:

Input Surface
      ↓
بخشی از
      ↓
Attack Surface

Attack Surface بسیار گسترده‌تر است.

۶. پیدا کردن Inputها با Burp

Juice Shop را اجرا کن:

docker run --rm -p 3000:3000 bkimminich/juice-shop

سپس Browser را از Burp عبور بده.

در:

Proxy
   ↓
HTTP History

شروع به بررسی Requestها کن.

به دنبال این موارد باش:

?
=
/api/
/{id}
JSON
Cookie
Authorization

۷. مثال اول — Search

در برنامه یک جست‌وجوی معمولی انجام بده.

مثلاً:

phone

حالا در Burp بررسی کن چه Requestی ایجاد شده است.

ممکن است چیزی شبیه این ببینی:

GET /rest/products/search?q=phone HTTP/1.1
Host: localhost:3000

حالا Input را مشخص کن:

Input:
q

Value:
phone

Location:
Query Parameter

Endpoint:
/rest/products/search

این را در Input Map ثبت کن.

۸. مثال دوم — Path

فرض کن Requestی شبیه این مشاهده کردی:

GET /api/products/15 HTTP/1.1

اینجا:

15

احتمالاً یک Identifier است.

ثبت کن:

Input:
15

Location:
Path

Context:
Product Identifier

حالا یک سؤال مهم:

آیا تغییر این شناسه باعث تغییر Resource می‌شود؟

در این مرحله فقط رفتار برنامه را مشاهده و مستند می‌کنیم.

۹. مثال سوم — JSON Body

فرض کن یک Request داری:

POST /api/example HTTP/1.1
Content-Type: application/json

و Body:

{
  "name": "test",
  "quantity": 1
}

حالا دو Input داریم:

name
quantity

ثبت:

Input:
name

Location:
JSON Body

Input:
quantity

Location:
JSON Body

۱۰. Inputهای پنهان

همه Inputها روی صفحه دیده نمی‌شوند.

ممکن است برنامه Inputهایی داشته باشد که فقط در HTTP Traffic دیده شوند.

مثلاً:

Hidden Parameter
API Parameter
JSON Field
Cookie
Custom Header
Path Identifier

اینجاست که Burp ارزش زیادی پیدا می‌کند.

Browser به تو می‌گوید:

«چه چیزی روی صفحه وجود دارد.»

Burp کمک می‌کند ببینی:

«چه چیزی واقعاً بین Client و Server ردوبدل می‌شود.»

۱۱. Input Validation

حالا یک مفهوم بسیار مهم:

Input Validation

برنامه باید داده دریافتی را مطابق نیاز خودش بررسی کند.

مثلاً اگر برنامه انتظار دارد:

age

یک عدد باشد، باید بررسی کند که مقدار دریافت‌شده واقعاً در قالب مورد انتظار است.

مدل ساده:

User Input
   ↓
Validation
   ↓
Processing

اگر Validation وجود نداشته باشد یا اشتباه پیاده‌سازی شده باشد، بسته به Context می‌تواند ریسک امنیتی ایجاد کند.

۱۲. Validation فقط نوع داده نیست

بررسی امنیتی Input می‌تواند شامل موارد مختلفی باشد:

Type
Length
Format
Range
Allowed Values
Encoding
Business Rules
Authorization Context

مثلاً:

quantity = 5

ممکن است از نظر Type صحیح باشد.

اما آیا:

quantity = 999999

هم منطقی است؟

اینجا موضوع فقط Type نیست.

Business Logic هم اهمیت دارد.

۱۳. Client-Side و Server-Side Validation

یک اشتباه رایج:

«اگر Browser مقدار را قبول نمی‌کند، پس برنامه امن است.»

نه لزوماً.

Validation می‌تواند در Client انجام شود:

Browser
   ↓
Client-Side Validation
   ↓
Server

اما کنترل امنیتی مهم باید در Server هم اعمال شود:

Client
   ↓
Server
   ↓
Server-Side Validation
   ↓
Application Logic

چون Client تحت کنترل کاربر است.

۱۴. یک مثال ساده

فرض کن فرم خرید داریم:

Product:
Laptop

Quantity:
1

Browser اجازه نمی‌دهد مقدار Quantity کمتر از 1 باشد.

اما سؤال امنیتی:

آیا Server هم این قانون را بررسی می‌کند؟

اگر Server فقط به Browser اعتماد کند، طراحی امنیتی مناسبی ندارد.

این مفهوم در تست Business Logic بسیار مهم می‌شود.

۱۵. Input و Authentication

حالا Authentication را به Input وصل کنیم.

Login:

POST /login

{
  "email": "...",
  "password": "..."
}

Inputها:

email
password

اما اینجا علاوه بر Input Validation، موضوعات دیگری هم داریم:

Authentication
Session
Rate Limiting
Credential Handling
Authorization

پس یک Input می‌تواند در چند لایه امنیتی اهمیت داشته باشد.

۱۶. Input و Authorization

فرض کن:

GET /api/profile/100

و:

100

شناسه کاربر است.

این Input از نوع Identifier است.

سؤال امنیتی:

آیا کاربر فعلی اجازه دارد Resource مربوط به 100 را مشاهده کند؟

اینجا دیگر فقط Validation مطرح نیست.

Authorization وارد می‌شود.

پس:

Input
  ↓
Application Logic
  ↓
Authorization
  ↓
Resource

۱۷. دسته‌بندی Inputها

برای پروژه خودمان Inputها را دسته‌بندی می‌کنیم:

INPUT MAP
│
├── Query Parameters
│
├── Path Parameters
│
├── Form Data
│
├── JSON Body
│
├── Cookies
│
├── Headers
│
├── File Uploads
│
└── Authentication Data

این دسته‌بندی را در تمام پروژه‌های Web Pentesting می‌توانی استفاده کنی.

۱۸. Input Inventory

حالا یک جدول ساده بساز:

Input	Location	Type	Function	بررسی
q	Query	String	Search	انجام نشده
id	Path	Identifier	Product	انجام نشده
email	JSON	String	Login	انجام نشده
password	JSON	String	Login	انجام نشده
session	Cookie	Session	Authentication	انجام نشده

این جدول را می‌توانی برای هر Target توسعه بدهی.

۱۹. سؤال حرفه‌ای

هر Input را که پیدا کردی، این سؤال‌ها را بپرس:

1. این Input برای چیست؟
2. چه نوع داده‌ای دریافت می‌کند؟
3. کجا پردازش می‌شود؟
4. آیا Validation وجود دارد؟
5. آیا Authentication لازم است؟
6. آیا Authorization بررسی می‌شود؟
7. آیا مقدار Input روی Response تأثیر دارد؟
8. آیا رفتار برنامه با تغییر کنترل‌شده Input تغییر می‌کند؟

این دقیقاً همان جایی است که تفکر Pentesting شکل می‌گیرد.

۲۰. تمرین عملی قسمت ۰۶

در Juice Shop حداقل ۱۰ Input پیدا کن.

آن‌ها را در این قالب ثبت کن:

================================
INPUT #01
================================

Name:
Location:
Endpoint:
Method:
Type:
Purpose:
Authentication:
Authorization:
Observed Behavior:
Open Questions:

برای مثال:

================================
INPUT #01
================================

Name:
q

Location:
Query Parameter

Endpoint:
/rest/products/search

Method:
GET

Type:
String

Purpose:
Search

Authentication:
Unknown

Authorization:
Unknown

Observed Behavior:
Changes search results

Open Questions:
How is input processed?

۲۱. قانون طلایی این قسمت

وقتی یک Input پیدا کردی، فوراً دنبال Payload نرو.

اول:

Discover
   ↓
Understand
   ↓
Document
   ↓
Hypothesize
   ↓
Validate

این ترتیب بسیار مهم است.

Pentesting حرفه‌ای یعنی:

فرضیه → شواهد → آزمایش کنترل‌شده → نتیجه

نه:

Payload → Payload → Payload

چالش قسمت ۰۶

برای Juice Shop یک Input Map بساز.

حداقل این موارد را پیدا کن:

2 Query Parameters
2 Path Parameters
2 JSON/Form Inputs
2 Cookies
2 Authentication-related Inputs

برای هرکدام بنویس:

Input
Location
Endpoint
Purpose
Expected Type
Authentication
Authorization
Observed Behavior
Open Question

سپس Inputها را بر اساس اهمیت و Context دسته‌بندی کن.

جمع‌بندی

در این قسمت یاد گرفتیم:

Application
     ↓
Input Discovery
     ↓
Input Mapping
     ↓
Validation
     ↓
Application Logic
     ↓
Authentication
     ↓
Authorization

و مهم‌تر از همه فهمیدیم:

هر Input یک آسیب‌پذیری نیست؛ اما هر Input یک نقطه برای درک بهتر رفتار برنامه است.

وقتی Inputهای برنامه را بشناسی، Attack Surface برایت از یک مفهوم مبهم به یک نقشه واقعی تبدیل می‌شود.

قسمت بعد — ۰۷

در قسمت بعد وارد مرحله مهم‌تری می‌شویم:

Authentication و Session

یاد می‌گیریم Login واقعاً چه اتفاقی پشت صحنه ایجاد می‌کند، Session چگونه شکل می‌گیرد، Cookie چه نقشی دارد و یک Pentester هنگام بررسی فرآیند احراز هویت باید چه چیزهایی را مستند و تحلیل کند.

از اینجا وارد یکی از حساس‌ترین بخش‌های Web Security می‌شویم.