نویسنده: SINISTER | رضا فروزان
برند: صفر و یک سایبر
سطح: متوسط تا پیشرفته
حوزه: Web & API Security
محیط تمرین: آزمایشگاه محلی و مجاز
ابزارها: Burp Suite، DevTools، curl

۱. API چیست؟

تا اینجا بیشتر با صفحات وب و Requestهای مرورگر کار کردیم.

اما بسیاری از برنامه‌های مدرن بدون API عملاً کار نمی‌کنند.

وقتی داخل یک سایت:

• وارد حساب می‌شوی؛
• محصولی را جست‌وجو می‌کنی؛
• پروفایل را تغییر می‌دهی؛
• سفارشی ثبت می‌کنی؛
• یا اطلاعاتی را بدون Refresh صفحه دریافت می‌کنی؛

احتمال زیادی وجود دارد که مرورگر در پشت صحنه با یک API ارتباط برقرار کرده باشد.

یک معماری ساده:

Browser
   ↓
HTTP Request
   ↓
API
   ↓
Application Logic
   ↓
Database

بنابراین در تست نفوذ، API خودش یک Attack Surface مستقل است.

۲. API Endpoint چیست؟

فرض کن برنامه چنین Endpointهایی دارد:

GET    /api/products
GET    /api/products/15
POST   /api/orders
PATCH  /api/profile
DELETE /api/address/7

هر Endpoint یک نقطه ورود به منطق برنامه است.

برای هر Endpoint باید بتوانیم پاسخ این سؤال‌ها را پیدا کنیم:

• چه کسی می‌تواند آن را فراخوانی کند؟
• چه Methodهایی مجاز هستند؟
• چه داده‌ای دریافت می‌کند؟
• چه داده‌ای برمی‌گرداند؟
• چه مجوزی لازم دارد؟
• چه محدودیت‌هایی روی آن اعمال شده؟
• در صورت خطا چه اطلاعاتی افشا می‌کند؟

۳. API را مثل یک Pentester ببین

یک اشتباه رایج این است که API را فقط به شکل URL ببینیم.

در واقع باید Endpoint را به‌صورت یک قرارداد امنیتی در نظر بگیریم:

Endpoint
   +
Method
   +
Authentication
   +
Authorization
   +
Input Validation
   +
Business Logic
   +
Rate Limit
   +
Response

اگر یکی از این لایه‌ها درست طراحی نشده باشد، ممکن است سطح حمله ایجاد شود.

۴. Authentication در API

اولین سؤال:

آیا API می‌داند درخواست متعلق به چه کاربری است؟

ممکن است API از:

• Session Cookie
• Token
• JWT
• API Key

استفاده کند.

برای مثال:

GET /api/profile HTTP/1.1
Host: localhost:3000
Cookie: session=...

یا:

Authorization: Bearer <token>

در تست نفوذ، نحوه احراز هویت باید مستند شود.

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

Authentication فقط می‌گوید چه کسی هستی.

این هنوز جواب نمی‌دهد که:

چه کاری اجازه داری انجام بدهی؟

این موضوع مربوط به Authorization است.

۵. Authorization؛ مهم‌تر از چیزی که به نظر می‌رسد

فرض کن کاربر وارد حساب خودش شده است.

او می‌تواند:

GET /api/profile

را اجرا کند.

اما آیا باید بتواند:

GET /api/admin/users

را هم اجرا کند؟

احراز هویت موفق به معنی مجوز دسترسی به همه Endpointها نیست.

پس در هر API باید این رابطه را بررسی کنیم:

Identity
   ↓
Role / Ownership
   ↓
Allowed Action
   ↓
Resource

۶. Object-Level Authorization

یکی از موضوعات مهم در API، کنترل دسترسی به Objectهاست.

فرض کن:

GET /api/orders/100

به کاربر اجازه می‌دهد سفارش خودش را مشاهده کند.

سؤال:

اگر همان کاربر شناسه دیگری را درخواست کند چه اتفاقی می‌افتد؟

در یک سیستم امن، سرور باید بررسی کند که آن Object واقعاً متعلق به کاربر است یا کاربر مجوز دسترسی به آن را دارد.

شناسه در URL نباید به‌تنهایی مجوز دسترسی باشد.

این مفهوم یکی از مهم‌ترین بخش‌های API Pentesting است.

۷. Horizontal و Vertical Access Control

Horizontal Access Control

دو کاربر در یک سطح دسترسی قرار دارند، اما نباید به منابع یکدیگر دسترسی داشته باشند.

مثلاً:

User A → Order A
User B → Order B

کاربر A نباید بتواند سفارش خصوصی B را مشاهده کند.

Vertical Access Control

سطح دسترسی کاربران متفاوت است.

مثلاً:

User
Admin
Moderator

یک User عادی نباید بتواند Endpointهای مخصوص Admin را اجرا کند.

۸. Mass Assignment چیست؟

فرض کن API برای ویرایش پروفایل چنین داده‌ای دریافت می‌کند:

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

حالا برنامه بدون کنترل دقیق، هر فیلدی را که کاربر ارسال کند به Object داخلی منتقل کند.

اگر مدل برنامه فیلدهایی مانند:

role
isAdmin
accountStatus

داشته باشد، این طراحی می‌تواند خطرناک شود.

اصل امنیتی:

سرور باید دقیقاً مشخص کند چه فیلدهایی از کاربر قابل تغییر هستند.

نباید تصور کنیم:

«اگر UI این فیلد را نشان نمی‌دهد، کاربر نمی‌تواند آن را ارسال کند.»

UI مرز امنیتی نیست.

Authorization و Field-Level Validation باید در سمت سرور اعمال شوند.

۹. Excessive Data Exposure

گاهی API اطلاعات بیشتری از نیاز واقعی کاربر برمی‌گرداند.

مثلاً UI فقط این موارد را نمایش می‌دهد:

{
  "name": "Ali",
  "avatar": "..."
}

اما API ممکن است اطلاعات بسیار بیشتری ارسال کند.

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

در تست API بررسی کن:

• چه فیلدهایی برگردانده می‌شوند؟
• کدام فیلدها برای کاربر لازم هستند؟
• آیا اطلاعات داخلی یا حساس وجود دارد؟
• آیا UI همه Response را مصرف می‌کند یا فقط بخشی از آن را؟

۱۰. Rate Limiting

فرض کن یک Endpoint حساس وجود دارد:

POST /api/login

اگر برنامه هیچ محدودیتی روی تعداد درخواست‌ها نداشته باشد، ممکن است در برابر حجم بالای درخواست آسیب‌پذیر شود.

Rate Limiting می‌تواند برای مواردی مانند:

• Login
• Password Reset
• OTP
• Search
• Expensive API Operations

اهمیت داشته باشد.

اما Rate Limit باید متناسب با عملکرد واقعی برنامه طراحی شود.

یک عدد ثابت برای همه Endpointها همیشه مناسب نیست.

۱۱. HTTP Methods

در API به Methodها توجه کن:

GET
POST
PUT
PATCH
DELETE

مثلاً:

GET /api/profile

برای دریافت اطلاعات استفاده می‌شود.

و:

PATCH /api/profile

ممکن است برای تغییر بخشی از آن باشد.

Pentester باید بررسی کند که:

• آیا Method غیرضروری فعال است؟
• آیا Endpoint با Method نامناسب پاسخ می‌دهد؟
• آیا Authorization برای هر Method جداگانه بررسی می‌شود؟
• آیا عملیات حساس فقط با Method مورد انتظار انجام می‌شود؟

۱۲. API Enumeration

در مرحله Recon، API را نیز Map کن.

منابع مفید:

• DevTools → Network
• Burp → HTTP History
• JavaScript Files
• API Documentation
• OpenAPI/Swagger در صورت مجاز بودن
• Responseها
• Error Messageها

یک جدول بساز:

Endpoint	Method	Auth	Role	Resource	Risk
/api/profile	GET	Yes	User	Own	Low
/api/orders/{id}	GET	Yes	User	Own	Medium
/api/admin/users	GET	Yes	Admin	All	High

این جدول یکی از ارزشمندترین ابزارهای ذهنی Pentester است.

۱۳. سناریوی عملی امن؛ Zero API Lab

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

معماری:

┌───────────┐
│ Browser   │
└─────┬─────┘
      │
      ▼
┌──────────────┐
│ Local API    │
│ localhost    │
└─────┬────────┘
      │
      ▼
┌──────────────┐
│ Test Database│
└──────────────┘

هدف:

ساخت نقشه امنیتی API و بررسی کنترل‌های Authentication و Authorization.

۱۴. مرحله اول؛ پیدا کردن APIها

برنامه آزمایشگاهی را اجرا کن.

DevTools را باز کن:

F12 → Network

حالا چند عملیات عادی انجام بده:

• Login
• مشاهده Profile
• جست‌وجو
• مشاهده محصول
• تغییر یک داده آزمایشی

در Network درخواست‌هایی را که به API می‌روند پیدا کن.

برای هر درخواست ثبت کن:

Endpoint
Method
Parameters
Authentication
Response

۱۵. مرحله دوم؛ انتقال درخواست به Burp Repeater

یک Request آزمایشگاهی را انتخاب کن و آن را در Burp Suite به Repeater منتقل کن.

در Repeater بدون تغییر مخرب، Request را دوباره ارسال کن.

هدف:

آیا رفتار API قابل تکرار است؟

موارد زیر را ثبت کن:

• Status Code
• Response Length
• Content-Type
• Response Body
• Headers

۱۶. مرحله سوم؛ بررسی Authentication

در محیط آزمایشگاهی، یک Request مجاز را با Session معتبر ارسال کن.

سپس همان Request را بدون اطلاعات Authentication بررسی کن.

مثلاً:

With Authentication → Expected Response
Without Authentication → Expected Denial

اگر Endpoint خصوصی بدون Authentication اطلاعات خصوصی برگرداند، نیازمند بررسی جدی است.

۱۷. مرحله چهارم؛ بررسی Authorization با دو حساب آزمایشی

اگر آزمایشگاه اجازه ساخت دو حساب دارد:

Test User A
Test User B

ایجاد کن.

با User A یک Resource متعلق به خودش بساز.

مثلاً:

Order A

سپس با User B بررسی کن که آیا همان Resource طبق سیاست برنامه قابل دسترسی است یا خیر.

این آزمایش فقط با داده‌های ساختگی حساب‌های آزمایشگاهی انجام شود.

هدف:

User B → Order A → Expected: DENY

اگر برنامه اجازه دسترسی بدهد، نتیجه را مستند کن و برای تأیید علت، کنترل Authorization سمت سرور را بررسی کن.

۱۸. مرحله پنجم؛ بررسی Field-Level Authorization

یک Request ویرایش پروفایل خودت را در Repeater بررسی کن.

مثلاً:

{
  "name": "Test User",
  "email": "test@example.local"
}

فقط در آزمایشگاه، بررسی کن که سرور چه فیلدهایی را واقعاً اجازه تغییر می‌دهد.

اگر API مستندات یا Schema دارد، آن را با رفتار واقعی مقایسه کن.

اصل:

Client Input
     ↓
Server Validation
     ↓
Allowed Fields
     ↓
Database

نه:

Client Input
     ↓
Database

۱۹. مرحله ششم؛ بررسی Response

یک Response واقعی API را بخوان.

سؤال‌ها:

• آیا اطلاعات اضافی وجود دارد؟
• آیا Internal IDها نمایش داده می‌شوند؟
• آیا اطلاعات حساس در Response قرار گرفته؟
• آیا Error Message بیش از حد جزئیات دارد؟
• آیا Stack Trace نمایش داده می‌شود؟

هر مورد را با Context ارزیابی کن.

۲۰. مرحله هفتم؛ بررسی Rate Limit

برای یک Endpoint آزمایشگاهی و کم‌خطر، تعداد محدودی درخواست ارسال کن.

هدف، ایجاد فشار روی سرور نیست.

فقط بررسی کن آیا برنامه:

• محدودیت درخواست دارد؟
• پاسخ مناسبی هنگام عبور از حد می‌دهد؟
• Header مربوط به محدودیت ارائه می‌کند؟
• برای Endpointهای حساس سیاست جداگانه دارد؟

هیچ تست حجمی یا DoS انجام نده.

۲۱. API Security Checklist

Discovery

• API Endpointها را شناسایی کردم.

• Methodهای هر Endpoint را ثبت کردم.

• پارامترها را مستند کردم.

Authentication

• Endpointهای خصوصی Authentication دارند.

• Session/Token رفتار قابل انتظار دارد.

• Logout باعث پایان Session می‌شود.

Authorization

• User فقط Resource خودش را می‌بیند.

• Roleها به‌درستی محدود شده‌اند.

• Endpointهای Admin برای User عادی قابل استفاده نیستند.

• Fieldهای حساس سمت سرور کنترل می‌شوند.

Input

• ورودی‌ها اعتبارسنجی می‌شوند.

• Mass Assignment کنترل شده است.

• نوع و محدوده داده‌ها مشخص است.

Response

• داده اضافی افشا نمی‌شود.

• Errorها اطلاعات حساس ندارند.

• Response با نیاز واقعی Client متناسب است.

Availability

• Endpointهای حساس Rate Limit دارند.

• عملیات پرهزینه محدود شده‌اند.

۲۲. گزارش‌نویسی

برای هر Finding این ساختار را استفاده کن:

Title

مثلاً:

Broken Object-Level Authorization در Endpoint آزمایشگاهی سفارش

Description

توضیح بده چه اتفاقی رخ می‌دهد.

Affected Endpoint

GET /api/orders/{id}

Preconditions

چه سطح دسترسی یا شرایطی برای مشاهده رفتار لازم است؟

Evidence

Request و Response مربوط به آزمایش.

Impact

اگر این رفتار در محیط واقعی وجود داشته باشد، چه اثری می‌تواند داشته باشد؟

Remediation

راهکار اصلاحی مشخص و قابل اجرا.

Severity

با توجه به Impact و شرایط واقعی تعیین شود.

۲۳. اشتباهات رایج هنگام تست API

اشتباه اول

فقط Endpointهایی را بررسی کنیم که UI به ما نشان می‌دهد.

اشتباه دوم

تصور کنیم UI مرز امنیتی است.

اشتباه سوم

Authentication را با Authorization اشتباه بگیریم.

اشتباه چهارم

فقط Status Code را بررسی کنیم.

اشتباه پنجم

Response را بدون بررسی داده‌های حساس رها کنیم.

اشتباه ششم

برای پیدا کردن Rate Limit تست حجمی انجام دهیم.

اشتباه هفتم

بدون مجوز API واقعی یک سازمان را تست کنیم.

۲۴. طرز فکر حرفه‌ای

وقتی یک API می‌بینی، این زنجیره را در ذهن داشته باش:

Who?
 ↓
Authentication

What can they access?
 ↓
Authorization

What can they change?
 ↓
Field-Level Controls

What can they send?
 ↓
Input Validation

What can they receive?
 ↓
Response Security

How often can they call?
 ↓
Rate Limiting

اگر بتوانی برای هر Endpoint این شش سؤال را پاسخ بدهی، عملاً داری API را مثل یک Pentester تحلیل می‌کنی.

جمع‌بندی

API فقط یک URL نیست.

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

امنیت API یعنی بررسی هم‌زمان:

Authentication + Authorization + Input Validation + Business Logic + Response Security + Rate Limiting

در این قسمت یاد گرفتیم که یک Pentester باید API را Map کند، جریان Authentication را بفهمد، مالکیت Resourceها را بررسی کند، Fieldهای قابل تغییر را شناسایی کند و Responseها را از نظر افشای اطلاعات تحلیل کند.

به خاطر داشته باش:

اگر UI چیزی را نشان نمی‌دهد، به این معنی نیست که API آن را قبول نمی‌کند.

و مهم‌تر:

امنیت واقعی باید در سمت سرور enforce شود؛ نه در ظاهر برنامه.

قسمت بعدی

قسمت ۱۵ — Business Logic & Race Conditions

این بار وارد بخشی می‌شویم که همیشه با یک Payload قابل مشاهده نیست:

منطق خودِ برنامه.

جایی که ممکن است تک‌تک Requestها کاملاً معتبر باشند، اما ترکیب یا ترتیب آن‌ها باعث ایجاد یک رفتار غیرمجاز شود.

صفر و یک سایبر | آموزش فارسی امنیت سایبری و هک قانونمند

تمام تمرین‌ها را فقط روی آزمایشگاه محلی، سیستم شخصی یا اهدافی که مجوز صریح تست آن‌ها را داری انجام بده.