انكشاف البيانات الحساسة

لماذا يهم

بالنسبة إلى المنتج، كثيراً ما يكون التسرّب هو الاختراق كله: سجل وصول مليء برموز الجلسات، أو نقطة نهاية قائمة تعيد رقم هاتف كل عميل لأي مستخدم مسجّل دخوله، لا يحتاجان إلى أي سلسلة استغلال. وللبيانات الشخصية وزن قانوني أيضاً؛ فنظام حماية البيانات الشخصية السعودي (PDPL) يسري على البيانات الشخصية المعالَجة في بيئات الاختبار وملفات السجلات كما يسري عليها في الإنتاج، ويشترط أن تقتصر البيانات المجموعة على الحد الأدنى الذي يحتاجه الغرض؛ فالحقل الذي لا يستخدمه أحد عبء لا ميزة.

وبالنسبة إلى المختبِر، هذه من أسهل العيوب الأمنية اكتشافاً: لا أدوات هجوم، بل قراءة ما يرسله التطبيق ويخزّنه أصلاً، وهو ما يراه المختبِر الوظيفي كل يوم. لكن المختبِر قد يكون أيضاً مصدراً للانكشاف، عبر لقطات الشاشة وتقارير الأخطاء وبيانات الاختبار المنسوخة من الإنتاج، ولهذا يتناول هذا الدرس اكتشاف الانكشاف من دون التسبب فيه.

ما الذي يُعدّ حساساً، ولماذا الترميز ليس حماية

ابدأ بتسمية البيانات. أربع فئات تهمّ في كل منتج تقريباً، ولكل منها قاعدتها الخاصة في أين يجوز أن تظهر، وهي تتداخل: فرابط إعادة تعيين كلمة المرور سرّ، وعنوان البريد الإلكتروني الذي أُرسل إليه بيانات شخصية.

ومهما كانت الفئة، فالترميز (Encoding) ليس حماية. فـ Base64 والترميز بالنسبة المئوية والنظام الست عشري وحمولة رمز JWT كلها قابلة للعكس لدى كل من يحمل السلسلة، كما تُظهر أداتا Base64 Decoder وJWT Decoder في ثانية. لا يحمي البيانات إلا التشفير (Encryption) بمفتاح لا يملكه القارئ، أو التجزئة (Hashing) أحادية الاتجاه لكلمات المرور؛ ويشرح الدرس التالي عن أساسيات التشفير الفرق بينهما. والإخفاء الجزئي (Masking) قاعدة عرض لا حماية: فـ **** 4242 آمن فقط عندما لا يرسل الخادم الرقم الكامل أبداً.

• بيانات الاعتماد والأسرار: كلمات المرور، ومعرّفات الجلسة، ورموز الوصول والتحديث، ورموز إعادة التعيين والتحقق، ومفاتيح API، والمفاتيح الخاصة. القاعدة: لا تُعرض مرة أخرى بعد إدخالها أو إصدارها، ولا تُسجَّل أبداً، ولا توضع في رابط إلا رمز عشوائي قصير الأجل ذو استخدام واحد، مثل الرمز في رابط إعادة تعيين مُرسل بالبريد.
• البيانات الشخصية: كل ما يحدد هوية شخص أو يصفه؛ الاسم مع الهاتف أو البريد الإلكتروني، ورقم الهوية الوطنية أو الإقامة، وتاريخ الميلاد، والعنوان، والموقع، والصور. ويعرّف نظام PDPL فئة أشد هي «البيانات الحساسة»، وتشمل البيانات الصحية، والبيانات الجينية والحيوية، والبيانات التي تكشف الأصل العرقي أو المعتقد الديني. القاعدة: لصاحبها أو لدور مخوَّل فقط، وللحقول التي تحتاجها الشاشة فقط.
• بيانات الدفع: رقم البطاقة وتاريخ انتهائها ورمز التحقق منها، ورقم IBAN. القاعدة: الرقم مُخفى جزئياً في كل مكان، ورمز التحقق لا يُخزَّن ولا يُعاد أبداً.
• التفاصيل الداخلية: تتبّع المكدس، ونص SQL، ومسارات الملفات، وأسماء المضيفات وعناوين IP الداخلية، وإصدارات البرمجيات، وأعلام التصحيح. القاعدة: رسالة عامة للمستخدم، والتفاصيل في سجل الخادم تحت رقم مرجعي.

جرّبها: مفكّك ترميز Base64 جرّبها: مفكّك ترميز JWT

أين تتسرّب البيانات: الروابط والاستجابات ورسائل الخطأ والسجلات

الروابط صُنعت لتُشارك، ولهذا بالذات يحذّر RFC 9110 من حمل معلومات حساسة فيها. فسلسلة الاستعلام (Query String) في طلب GET تُنسخ إلى سجل المتصفح وإشاراته المرجعية، وإلى سجلات الوصول في خادم الويب وموازن الحمل وشبكة توصيل المحتوى (CDN)، وإلى التحليلات ولقطات شاشة الدعم وأي سكربت خارجي في الصفحة، إذ يستطيع قراءة العنوان كاملاً، وإلى مواقع أخرى عبر ترويسة Referer إذا سمحت سياسة Referrer-Policy في الصفحة بإرسال الرابط كاملاً. لذلك فإن ?sessionId= و?email= و?nationalId= في الروابط والمرشّحات والأزرار المرسلة بالبريد تسرّبات حتى عبر HTTPS، الذي يحمي الاتصال لا النسخ. ومكان البيانات الشخصية والأسرار هو جسم الطلب أو ترويسة؛ والاستثناء المقبول عادةً هو رمز عشوائي قصير الأجل ذو استخدام واحد، مثل الرمز في رابط إعادة التعيين أو التأكيد، على صفحة ترسل Referrer-Policy: no-referrer.

وتتسرّب الاستجابات عندما يعيد الخادم الكائن بدلاً من العرض. فشاشة الملف الشخصي تعرض اسماً، لكن /api/users/42 يحمل passwordHash وotpSecret وnationalId وisAdmin؛ ونقطة نهاية قائمة تعيد هاتف كل عميل لأي مستخدم مسجّل دخوله؛ وحزمة JavaScript تشحن مفتاح API؛ واستجابة تحوي بيانات شخصية بلا Cache-Control: no-store قد تبقى في ذاكرة المتصفح المؤقتة، كما يشرح درس التخزين المؤقت في HTTP. والفحص دائماً للجسم الخام، لا للشاشة.

وتكشف رسائل الخطأ التفاصيل الداخلية. فصفحة ⁦500⁩ فيها تتبّع للمكدس، أو خطأ من قاعدة البيانات يحمل نص SQL، أو مسار ملف، أو إصدار إطار عمل، أو صفحة تصحيح تُركت مفعّلة في بيئة الاختبار، تخبر المهاجم بما يجرّبه بالضبط؛ وتسجيل دخول يجيب «المستخدم غير موجود» لعنوان و«كلمة المرور خاطئة» لآخر يؤكد أي الحسابات موجود. يجب أن يرى المستخدم رسالة عامة مع رقم مرجعي، والتفاصيل مكانها سجل الخادم.

وتتسرّب السجلات بصمت. فالتطبيق الذي يسجّل أجسام الطلبات كاملة يسجّل كل كلمة مرور ورقم بطاقة أُرسلا إليه؛ وسجلات الوصول تحتفظ بكل رابط من الفقرة الأولى؛ ومتعقّبات الأخطاء والتحليلات ومبلّغات الأعطال أطراف ثالثة تتلقى نسخاً؛ ومقتطفات السجلات الملصقة في الدردشة والتذاكر تسافر أبعد. وتسرد ورقة OWASP الإرشادية للتسجيل (Logging Cheat Sheet) بيانات يجب إبقاؤها خارج السجلات، منها كلمات المرور، ومعرّفات الجلسة، ورموز الوصول، ومفاتيح التشفير، وبيانات بطاقات الدفع، والبيانات الشخصية الحساسة مثل البيانات الصحية والمعرّفات الحكومية.

جرّبها: محلّل عناوين URL

تقليل البيانات: السؤال وراء كل حقل

تقليل البيانات (Data Minimisation) يعني جمع البيانات التي يحتاجها الغرض المعلن فقط، ومعالجتها وعرضها والاحتفاظ بها فقط. يشترطه نظام PDPL، ويسمّيه نظام GDPR الأوروبي مبدأً، وهو أقوى دفاع ضد الانكشاف، لأن البيانات التي لا يحتفظ بها النظام أصلاً لا يمكن أن تتسرّب. وبالنسبة إلى المختبِر يتحول إلى سؤال واحد لكل حقل، يُطرح عند أربع نقاط.

• الجمع: هل يطلب النموذج بيانات لا تحتاجها الميزة، مثل تاريخ الميلاد لنشرة بريدية؟ كل حقل زائد شرط اختبار وسؤال لمالك المنتج.
• الإعادة: هل يظهر كل حقل في الاستجابة على شاشة ما لهذا الدور؟ قارن JSON الخام بالواجهة، بما في ذلك نقاط نهاية القوائم والبحث والتصدير و«me»، وهي عادةً الأوسع.
• التسجيل: أي الحقول يكتبها التطبيق في سجلاته، وأيها مُخفى جزئياً؟ اسأل المطور، ثم تحقق بقيم الاختبار الخاصة بك.
• الاحتفاظ: بعد أن يحذف مستخدم حسابه، هل تظل البيانات تظهر في البحث والتصديرات والنسخ الاحتياطية للسجلات؟ وهل تحوي بيئة الاختبار نسخة من بيانات الإنتاج أصلاً؟ هذه النسخة بموجب PDPL بيانات شخصية تُعالَج؛ والبيانات الاصطناعية هي الخيار الافتراضي، كما يشرح دليل اختبار قواعد البيانات.

مثال تطبيقي: واجهة API لتتبّع الطلبات

تتضمن خطة اختبار تطبيق توصيل فحصاً للانكشاف في ميزة تتبّع الطلبات الجديدة، بنطاق أكّده مسؤول الأمان كتابةً: بيئة الاختبار، وحسابا العميل والمندوب التجريبيان الخاصان بالمختبِر، ومدخلات غير ضارة فقط. يتلقى العملاء رابط التتبّع برسالة SMS، وتستدعي صفحة التتبّع وتطبيق الجوال كلاهما GET /api/orders/{id}.

الرابط هو https://track.shop.example/t?order=1042&phone=0551234567: رقم هاتف في رابط GET، يُنسخ إلى سجلات مزوّد SMS وسجل المتصفح وسكربت مزوّد الخرائط الذي تضمّنه صفحة التتبّع، إذ يستطيع قراءة العنوان كاملاً. والاستجابة أدناه، عند قراءتها بوصفها JSON خاماً، تحمل رقم البطاقة الكامل ورمز التحقق، ورقم الهوية الوطنية للعميل، وعنوان منزل المندوب، وملاحظة داخلية ومضيف قاعدة بيانات، ولا تعرض شاشة التتبّع أياً منها، وليس فيها ترويسة Cache-Control. ويعيد /api/orders/abc استجابة ⁦500⁩ يذكر جسمها مسار ملف ونص SQL. وأخيراً، يلصق مطور سُئل عمّا تسجّله الواجهة سطراً من سجل التطبيق يحوي جسم POST /login كاملاً، بما فيه كلمة المرور.

يبلّغ المختبِر، مع إخفاء كل قيمة جزئياً، بترتيب الخطورة: أولاً بيانات البطاقة في الاستجابة، لأن رمز التحقق يجب ألا يُحتفظ به بعد اعتماد الدفع، وكلمة المرور في السجل، التي يقرؤها كل من يصل إلى السجلات؛ ثم رقم الهاتف في الرابط، ثم رقم الهوية وعنوان المندوب والملاحظة الداخلية، ثم نص SQL ومسار الملف في جسم الخطأ، ثم غياب Cache-Control: no-store. وتُتفق الخطورة مع فريق الأمان، ويُؤكَّد الإصلاح في كل مكان ظهرت فيه البيانات، لا في شاشة التتبّع وحدها.

GET /api/orders/1042 HTTP/1.1
Host: api.test.shop.example
Authorization: Bearer eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiI3NzMxIn0.x

HTTP/1.1 200 OK
Content-Type: application/json

{
  "id": 1042,
  "status": "out_for_delivery",
  "customer": { "name": "Test Customer", "phone": "0551234567",
                "nationalId": "1098765432" },
  "payment": { "card": "4242424242424242", "expiry": "12/27", "cvv": "123" },
  "courier": { "name": "Test Courier", "phone": "0509876543",
               "homeAddress": "Al Olaya, Riyadh" },
  "internal": { "note": "complained twice", "dbHost": "10.0.3.12" }
}

GET /api/orders/abc HTTP/1.1
Host: api.test.shop.example

HTTP/1.1 500 Internal Server Error
Content-Type: application/json

{ "error": "invalid input syntax for type integer: \"abc\"",
  "query": "SELECT * FROM orders WHERE id = 'abc'",
  "at": "/srv/app/src/orders/service.ts:88" }

جرّبها: عارض شجرة JSON

كيف تختبر الانكشاف بأمان

اختبار الانكشاف قراءة لا هجوم: تنظر فيما يرسله التطبيق ويخزّنه لحسابات الاختبار الخاصة بك، في نظام تملكه أو لديك إذن كتابي باختباره. وبيانات العملاء الحقيقية ليست بيانات اختبار أبداً؛ فإذا صادفتها مصادفةً فتوقف ولا تنسخها وأبلغ مسؤولك. واحتفظ بالأدلة مع إخفاء القيم جزئياً، مثل 05512*****.

• الجرد: من المتطلبات ونموذج البيانات، اكتب الحقول الحساسة في الميزة، ولكل حقل من يجوز له رؤيته وأين يجوز أن يظهر: الشاشة أو API أو السجل أو التصدير أو البريد أو SMS.
• الروابط: امشِ في كل مسار ولوحة الشبكة مرشّحة بـ ?، وافتح كل رابط مُرسل بالبريد أو SMS، وحلّل الروابط المشبوهة. المتوقع: لا بيانات شخصية ولا كلمات مرور ولا معرّفات جلسة ولا مفاتيح في أي سلسلة استعلام، ولا شيء في رابط البريد سوى رمز قصير الأجل ذي استخدام واحد.
• الاستجابات: لكل نقطة نهاية تستدعيها شاشة، اقرأ الجسم الخام وعلّم كل حقل لا تعرضه الشاشة؛ وكرر ذلك لنقاط نهاية القوائم والبحث والتصدير و«me» ولمصدر HTML وحزم JavaScript.
• الأخطاء: أرسل قيمة مشوّهة واحدة لكل نوع مدخل، وحقلاً مطلوباً مفقوداً، وطريقة غير مدعومة، واقرأ أجسام استجابات 4xx و5xx؛ ويجب أن تجيب عمليات تسجيل الدخول وإنشاء الحساب وإعادة التعيين بالرسالة نفسها للحسابات الموجودة والمجهولة.
• السجلات والأطراف الثالثة: مع المطور، ابحث في سجلات التطبيق وسجلات الوصول في بيئة الاختبار عن قيم الاختبار الخاصة بك بتعبير نمطي، واكتب أي متعقّبات أخطاء وتحليلات تتلقى الطلبات.
• جانب العميل: Cache-Control: no-store في الاستجابات التي تحوي بيانات شخصية، وترويسة Referrer-Policy، ومحتوى التخزين المحلي وتخزين الجلسة، وما تطبعه وحدة تحكم المتصفح.

جرّبها: أداة اختبار Regex جرّبها: محلّل مخاطر استجابات API بالذكاء الاصطناعي

أسئلة شائعة

المراجع

• OWASP Top 10:2025OWASP Foundation · 2025أخطر عشرة مخاطر أمنية لتطبيقات الويب، مع كيفية اختبار كل منها والوقاية منه.
• OWASP API Security Top 10 (2023)OWASP Foundation · 2023أكثر عشر نقاط ضعف شيوعاً في واجهات API: خلل التفويض على مستوى الكائن، وخلل التوثيق، والاستهلاك غير المقيد للموارد، وغيرها.
• OWASP Cheat Sheet Series: LoggingOWASP Foundationما يُسجَّل وما لا يُسجَّل أبداً (كلمات المرور والرموز والبيانات الشخصية)، وكيف تُبقى السجلات قابلة لكشف العبث.
• Personal Data Protection Law (English translation)الهيئة السعودية للبيانات والذكاء الاصطناعي (سدايا) · 2023النظام السعودي لحماية البيانات الشخصية — ولماذا ينبغي أن تستخدم بيئات الاختبار بيانات اصطناعية بدلاً من نسخ سجلات العملاء الحقيقية.