Spaces:
Sleeping
Sleeping
| [ | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 1, | |
| "text": "مر حبا بكم ز ملائي الأعز اء، نبدأ معكم عاما در اسيا جديدا وأخيرا في رحلتنا الجامعية، سائلين الله تعالى أن يكون عام ا مليئا بالخير والتوفيق، وأن ي كلل جهودنا بالنجاح والتميز في سنة التخرج. نرافقكم اليوم في محاضر ات مادة أمن المعلومات للقسم العملي، وهي من المواد الممتعة والمهمة في اختصاصنا كونها تجمع بين الجانب النظري والتطبيقي، وتشكل أساسا لفهم حماية البيانات والأنظمة والموارد الرقمية. نرجو من خلال هذه المحاضر ات أن ن قدم محتوى واضح وسهل يساعدكم على متابعة الشرح والاستفادة منه بأفضل صور ة بإذن الله. ## بسم الله نبدأ. ## مقدمة في الأمن السيبراني", | |
| "chunk_id": 0 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 1, | |
| "text": "ي عد الأمن السيبراني أهم مجالات علوم الحاسوب الحديثة، ويهتم بحماية الأنظمة والبيانات والشبكات من الهجمات الرقمية سواء كانت بهدف التخزين أو السرقة أو تعطيل الخدمات. ويشمل الأمن السيبراني مجموعة من السياسات والتقنيات والممارسات التي تهدف لضمان سلامة المعلومات واستمرارية العمل. محتويات المحاضرة تتناول هذه المحاضرة المحاور التالية: ## 1. مقدمة \n* لمحة تاريخية عن تطور الأمن السيبراني \n* تعريف المصطلحات الأساسية \n* مستويات الحماية \n* مفهوم الأصول (Assets) \n* أهم المصطلحات والمفاهيم الخاصة بالأمن السيبراني \n* 2. خصائص الأمن \n* 3. عملية الأمان \n* 4. البرمجيات الخبيثة (Malware) \n* 5. الهجمات وأنواع المخترقين", | |
| "chunk_id": 1 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 2, | |
| "text": "## تأثير أحداث 2001/9/11 \nأثرت هجمات الحادي عشر من سبتمبر بشكل كبير على مفهوم الأمن الرقمي حول العالم، ويمكن تلخيص ذلك بما يلي: * تحول التركيز إلى تعزيز الأمن باعتباره ضرورة وطنية وليست مشكلة تقنية فقط. * استخدام المهاجمين للإنترنت والشبكة المظلمة لتنفيذ مخططاتهم. * ازدياد الفوضى وشن المتسلل ون العديد من الهجمات عبر البريد الإلكتروني أو التشهير أو رفض الخدمة. * ظهور قوانين صارمة وإجراءات وقائية جديدة تهدف إلى حماية البنى التحتية. ## تأثير جائحة كورونا", | |
| "chunk_id": 2 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 2, | |
| "text": "ساهمت جائحة كورونا في توسيع دور العالم الافتراضي نتيجة العمل والدراسة عن بعد، مما أدى إلى: * 1. زيادة هجمات التصيد الإلكتروني. * 2. ضعف حماية الشبكات المنزلية لعدم استخدام المستخدمين برامج حماية كافية. * 3. انتشار برمجيات الفدية (Ransomware). * 4. ارتفاع مستوى التدريب والتوعية الأمنية لدى المؤسسات والأفراد. ## الذكاء الاصطناعي كعامل تهديد في أمن المعلومات", | |
| "chunk_id": 3 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 2, | |
| "text": "لقد وسع الذكاء الاصطناعي (AI) بشكل كبير وكثف مشهد التهديدات السيبرانية من خلال الأتمتة والتخصيص وقدرات التعلم الذاتي. التهديدات الرئيسية: * التصيد الاحتيالي الذكي والهندسة الاجتماعية: يولد الذكاء الاصطناعي رسائل شخصية ومقنعة للغاية. * البرمجيات الخبيثة التي ي نشئها ال AI: التوليد الآلي وتحسين أكواد الاستغلال. * التزييف العميق: يستخدم لخرق الثقة والتلاعب بالهويات والاحتلال. * الهجمات العدائية وتسميم البيانات: استهداف نماذج الذكاء الاصطناعي نفسها لتعطيل أو خداع أنظمة الكشف. * وفقا لمايكروسوفت و ENISA لعام 2024: أصبح ال AI عامل مضاعفة للقوة للمهاجمين في مجال الأمن السيبراني الحديث. ## الذكاء الاصطناعي كأداة للدفاع والحماية: إلى جانب مخاطر الذكاء الاصطناعي يعد أيضا وسيلة فع الة لحماية الأنظمة ومن أهم استخداماته: * ي ستخدم في التحليل السلوكي والكشف المبكر عن الشذوذ: تحديد نشاط غير المنتظم عبر", | |
| "chunk_id": 4 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 2, | |
| "text": "أهم استخداماته: * ي ستخدم في التحليل السلوكي والكشف المبكر عن الشذوذ: تحديد نشاط غير المنتظم عبر الشبكات والأنظمة. * الاستجابة الآلية (SOAR): تقليل من وقت الاستجابة للحوادث والخطأ البشري. * الكشف المحسن عن التصيد الاحتلالي والاحتيال: يحسن الدقة ويقلل من الإيجابيات الخاطئة. * التعلم المستمر: يكمن الدفاع التكيفي ضد الهجمات المتطورة.", | |
| "chunk_id": 5 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 3, | |
| "text": "* استنادا إلى إطار عمل إدارة المخاطر الذكاء الاصطناعي التابع للمعهد الوطني للمعايير والتكنولوجيا: يعد الذكاء الاصطناعي الآن حجر الزاوية في دفاع الامن السيبراني الحديث. فجوة القوى العاملة العالمية في مجال الأمن السيبراني على الرغم من الرقم العالي الذي يبلغ 5. 5 مليون متخصص، فقد ارتفعت فجوة القوى العاملة في مجال الأمن السيبراني إلى 4. 8 مليون وظيفة شاغرة في عام 2025. ## تعريف المصطلحات \n* Cyber: ي شير المصطلح إلى كل ما يتعلق بالإنترنت، الحواسيب، الأنظمة الرقمية أو أي بيئة افتراضية. * Assets ( ممتلكات: ) \n* ممتلكات ملموسة: مثل المباني، الأشخاص، التجهيزات، الأجهزة. * ممتلكات غير ملموسة: مثل البيانات، الشيفرات البرمجية، معلومات حساسة. ## مستويات الحماية", | |
| "chunk_id": 6 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 3, | |
| "text": "## تقسم الحماية في الأنظمة إلى خمسة مستويات رئيسية: * 1. مستوى العتاد (Hardware Level) \n* 2. مستوى نظام التشغيل (Operating System Level) \n* 3. مستوى الشبكة (Network Level) \n* 4. مستوى التطبيقات (Application Level) \n* 5. مستوى الأشخاص (People Level)", | |
| "chunk_id": 7 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 3, | |
| "text": "## الحماية على مستوى العتاد (Hardware Level) يتضمن هذا المستوى: * وجود نمطين في المعالج: نمط المستخدم، ونمط النواة (Kernel Mode). * استخدام تقنيات حماية الذاكرة، والتي تكون مدمجة جزئيا في بنية المعالج، بهدف منع البرامج من الوصول إلى مناطق غير مصرح بها. ## الحماية على مستوى نظام التشغيل يقدم نظام التشغيل مجموعة من وسائل الأمان، أهمها: * حماية الملفات والعمليات والمنافذ والأجهزة بناء على المستخدم أو المجموعة (User/Group Permissions). * تشفير ملفات كلمات المرور لحمايتها من الوصول غير المصرح. ## الحماية على مستوى الشبكة (Network Level) وتشمل: * استخدام الجدران النارية (Firewalls). * م وج ه التوجيه الذكي (Smart Router Software). * بروتوكولات الأمان مثل: * IPsec على طبقة الشبكة. فائدة اربسيزية: بروتوكول IPsec هو مجموعة من البروتوكولات التي تعمل معا لتوفير خدمات أمنية على مستوى Network Layer. بما", | |
| "chunk_id": 8 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 3, | |
| "text": "IPsec هو مجموعة من البروتوكولات التي تعمل معا لتوفير خدمات أمنية على مستوى Network Layer. بما في ذلك السرية، المصادقة، وسلامة البيانات، مما يجعله أساسيا لإنشاء", | |
| "chunk_id": 9 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 4, | |
| "text": "* SSL/TLS على طبقة النقل. * Secure Ethernet & Wireless Security على طبقة ربط البيانات. * PGP لتأمين البريد الإلكتروني والتطبيقات. * استخدام الشبكات الافتراضية الخاصة (VPNs). ## الحماية على مستوى التطبيقات (Application Level) يجب أن ت صمم التطبيقات بحيث تتضمن آليات أمان واضحة، مثل: * التحقق من الهوية (Authentication). * تحديد الصلاحيات (Authorization) والأدوار. * منع استخدام كلمات المرور الضعيفة. * إدارة استعادة كلمة المرور بطريقة آمنة. * تنفيذ فحوصات النطاق (Range Checks) لضمان صحة المدخلات. * أحيانا ت ستخدم سياسة انتهاء صلاحية كلمات المرور، لكن هذا الإجراء مثير للجدل. الحماية على مستوى الأشخاص (Human Level) ي عد العامل البشري من أضعف نقاط الأمان، وتشمل المخاطر: * هجمات التصيد بأنواعه. * انتحال الشخصية وطلب كلمات المرور أو الأموال. * هذه الهجمات قد تتم عبر الإنترنت أو الهاتف أو حتى وجها", | |
| "chunk_id": 10 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 4, | |
| "text": "الشخصية وطلب كلمات المرور أو الأموال. * هذه الهجمات قد تتم عبر الإنترنت أو الهاتف أو حتى وجها لوجه. ## الأسئلة الكبرى", | |
| "chunk_id": 11 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 4, | |
| "text": "تعتمد عملية الأمن على الإجابة عن أربعة أسئلة أساسية: * 1. ماذا نريد أن نحمي؟ مثل المباني، الأشخاص، البيانات، إلخ. وهي ما ي عرف ب (Assets). * 2. لماذا نريد الحماية؟ لضمان السرية والنزاهة وتوافر المعلومات. * 3. نحمي؟ م م من هجمات مادية أو سرقة بيانات أو اختراقات، وهي ما ي عرف بالتهديدات (Threats). * 4. كيف نحمي؟ من خلال وسائل مثل التشفير والتوثيق وبناء الأنظمة القوية، وهي إجراءات الحماية Security Measures. ## المنظمات والمشاريع في الأمن السيبراني \nمن أهم الهيئات العالمية المختصة بأمن المعلومات: * المعهد الوطني للمعايير والتقنية (NIST) \n* مشروع أمن التطبيقات المفتوح (OWASP) \n* جمعية أمن نظم المعلومات (ISSA)", | |
| "chunk_id": 12 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 5, | |
| "text": "## 1. المعهد الوطني للمعايير والتقنية NIST \n* تأسس المعهد عام 1901 بقرار من مجلس الشيوخ الأمريكي. * هو مختبر و وكالة غير تنظيمية تابعة لوزارة التجارة الأمريكية (وليس الدفاع). * يهدف إلى: * تعزيز الابتكار. * دعم القدرة التنافسية الصناعية. * وضع معايير وأطر عمل تساعد المؤسسات على تحسين أمن المعلومات وإدارة المخاطر. ## 2. منظمة OWASP \n* منظمة غير ربحية تهدف إلى رفع مستوى أمان تطبيقات الويب. * تعتمد على مشاريع مفتوحة المصدر يقودها المجتمع العالمي. * ت عد المرجع الأول للمبرمجين لتأمين التطبيقات. * تقدم: * أدوات وموارد متخصصة. * مجتمعا للتعاون وتبادل المعرفة. * برامج تدريب وتوعية. ومن أشهر مشاريعها OWASP Top 10. ## 3. جمعية ISSA", | |
| "chunk_id": 13 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 5, | |
| "text": "* منظمة غير ربحية تضم محترفي الأمن السيبراني حول العالم. * تهدف إلى: * رفع مهارات الأفراد في مجال الأمن. * إدارة المخاطر السيبرانية. * حماية البنى التحتية والمعلومات الحساسة. * تقدم: * منتديات تعليمية. * منشورات متخصصة. * فرصا للتواصل والتطوير المهني.", | |
| "chunk_id": 14 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 6, | |
| "text": "## خصائص الأمن \nتشير هذه الخصائص إلى العناصر الأساسية التي يجب تحقيقها لضمان أمن المعلومات. يتم التعبير عنها عادة بنموذج CIA Triad و AAA. ثلاثية CIA: هي من أهم نماذج أمن المعلومات وتتكون من: * السرية (Confidentiality): ضمان عدم وصول غير المصرح لهم للبيانات. * السلامة (Integrity): التأكد من أن البيانات لم ت عد ل أو ت خر ب أثناء التخزين أو النقل. * التوافر (، الوجود (Availability: ضمان وصول المستخدمين المصرح لهم إلى البيانات والخدمات عند الحاجة. | ( الأمني البعد Dimension ) | ( الشرح / هو ما What it is ) | التقنيات المستخدمة ( Techniques ) |\n|--------------------------------------|------------------------------------------------------------------------------------------------------|--------------------------------------------------------------------------------------------------------|\n| ( السرية Confidentiality ) | كشفها يتم أن من البيانات منع الخطأ، للأشخاص (تسريبها) عبر أو الخطأ طريق عن سواء الخبيث. التلصص | أو التخزين أثناء (سواء التشفير. ) النقل أثناء |\n| ( السلامة / النزاهة Integrity ) | يتم أن من البيانات منع عن إما تخريبها، أو تعديلها خبيث، بشكل أو الخطأ طريق بها. عبث أي حصل إن ومعرفة | الرسائل من التحقق أكواد ( MACs أكواد )، CRC، ( الفحوصات Checksums )، الآمنة. البرمجة ممارسات |\n| التحقق الهوية من ( Authentication ) | المستخدمين أن التأكد هم المستقبلين) أو (المرسلين هم. أنهم يدعون من فعلا | المرور، عبارات المرور، كلمات ( الرموز Tokens المفاتيح )، ( Keys الرقمية، التواقيع )، الرقمية. الشهادات |\n| الصلاحيات تحديد ( Authorization ) | سمح ي التي العمليات تقييد بتنفيذها. للمستخدمين | ( الأدوار Roles الأذونات )، ( Permissions. ) |\n| التتبع / المحاسبة ( Accountability ) | وربطها الإجراءات تتبع. فعليا بها قام الذي بالشخص | ( السجلات Logs. ) |\n| ( التوافر Availability ) | متاحة الخدمات تكون أن يجب انقطاع. دون الإمكان قدر دائما | الأخطاء، تحمل المراقبة، التشغيل، إعادة / الاستعادة ( التوسع Scaling )، |", | |
| "chunk_id": 15 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 7, | |
| "text": "## نموذج AAA: هو نموذج آخر مكمل للثلاثية ويتكون من: * التحقق من الهوية (Authentication) \n* تحديد الصلاحيات (Authorization) \n* المحاسبة أو التتبع (Accounting) \n* التحقق من الهوية (Authentication) \nهي عملية التأكد من هوية المستخدم وأنه بالفعل الشخص الذي يدعي أنه هو، ويتم ذلك عبر: كلمة مرور، بصمة، رمز يصل للهاتف. . . * تحديد الصلاحيات (Authorization) \nت عرف بمستوى الوصول الذي يمتلكه المستخدم حسب دوره ومسؤولياته. * إعطاء صلاحيات زائدة يؤدي إلى سوء استخدام أو اختراق. * مثال: موظف الموارد البشرية لا يجب أن يرى سجلات المحاسبة. * المحاسبة (Accounting)", | |
| "chunk_id": 16 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 7, | |
| "text": "## تقوم على المبدأ التالي: * تتبع نشاط المستخدمين داخل النظام. * تسجيل الأحداث الهامة (Logs). * مراقبة السجلات لاكتشاف أي أفعال مشبوهة أو محاولات اختراق. ## سؤال: هل نطبق سياسات أمنية تضمن كل المعايير؟ ## مثال يوضح حالة نحتاج فيها: * التحقق من الهوية. * السلامة. * لا نحتاج للسرية فيها. الجواب: التحقق من صحة نتائج الامتحان حيث يجب التأكد من أن الطالب هو نفسه، ليتأكد من أن اسمه موجود. Authentication \nويجب التأكد من أن النتائج لم ت عد ل Integrity ولكنها ليست سرية لأن النتائج معلنة للجميع. \"Don't watch the clock; do what it does. Keep going. \"", | |
| "chunk_id": 17 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 8, | |
| "text": "## عملية الأمن السيبراني (Security Process) \nتتكون عملية الأمن السيبراني من خمسة مراحل أساسية: * 1. التعرف (Identify) \n* 2. الحماية (Protect) \n* 3. الكشف (Detect) \n* 4. الاستجابة (Respond) \n* 5. استعادة العمل (Recover)", | |
| "chunk_id": 18 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 8, | |
| "text": "## 1. التعرف: تطوير فهم تنظيمي لإدارة مخاطر الأمن السيبراني على الأنظمة و Assets والبيانات والقدرات. ## 2. الحماية: تطوير وتنفيذ الضمانات المناسبة لضمان تقديم الخدمات. ## 3. الكشف: تطوير وتنفيذ الأنشطة المناسبة لتحديد وقوع حدث أمن سيبراني. ## 4. الاستجابة \nتطوير وتنفيذ الأنشطة المناسبة لاتخاذ إجراءات بشأن حدث أمن سيبراني تم اكتشافه. ## 5. استعادة العمل (الاسترداد): تطوير وتنفيذ الأنشطة المناسبة للحفاظ على المرونة واستعادة أي بيانات أو خدمات تعطلت بسبب حدث أمن سيبراني. ## نقاط الضعف والتهديدات والمخاطر", | |
| "chunk_id": 19 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 8, | |
| "text": "الثغرة الأمنية: هي ضعف في تدفق نظام التشغيل أو الشبكة أو التطبيق، يمكن أن تنشأ نقاط الضعف لأسباب عديدة بما في ذلك سوء التكوين وعيوب التصميم وإصدارات البرامج القديمة و ضعف بيانات الاعتماد أو المستخدمين الداخلين المعرضين للتصيد الاحتيالي. التهديد: هو حدث ضار يستغل ثغرة أمنية ويمتلك القدرة على إتلاف الممتلكات. فيروس، دودة، برامج خبيثة، هجوم القوة الغاشمة (Brute Force)، رفض الخدمة، رجل في المنتصف (MITM)، التصيد الاحتيالي. الخطر: هو احتمال فقدان أو تلف أصول المؤسسة نتيجة وجود تهديد يستغل ثغرة داخل النظام.", | |
| "chunk_id": 20 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 9, | |
| "text": "## ▪ المخترقون (Hackers): * من هم المخترقون؟ * ما هي أهدافهم؟ * ما هي أنواع المخترقين؟ ## تعريف المخترق (Hackers Definition) المخترق هو: * أي شخص يكتشف طرقا للالتفاف على الدفاعات الأمنية. * يستغل الثغرات ضمن أنظمة وشبكات الحاسوب. * يمتلك معرفة واسعة بالبرمجيات والعتاد. ## دوافع المخترقين (Hackers Motives) أهم الدوافع: * 1. المال (وهو الأكثر شيوعا 81 )% \n* 2. الشهرة أو إثبات المهارات. * 3. الفضول. * 4. أهداف سياسية (اختراقات ترعاها الدول). * 5. أهداف إرهابية. * 6. الانتقام من جهة أو موظفين سابقين. * 7. المنافسة التجارية. ## أنواع المخترقين (Hackers Types) تنقسم فئات المخترقين إلى: * القبعات البيضاء \n* القبعات السوداء \n* القبعات الرمادية \n* القبعات الخضراء \n* القبعات الحمراء \n* القبعات الزرقاء \n* الهاكتفيست (Hacktivists)", | |
| "chunk_id": 21 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 10, | |
| "text": "## القبعات الخضراء (Green Hats) \n* ي سمون Script Kiddies. * يعتمدون على أدوات جاهزة من الإنترنت. * الدروس من يتعلمون والفيديوهات التعليمية. ## القبعات الحمراء (Red Hats) \n* يشبهون القبعات البيضاء، ولكن بطريقة هجومية. * يستهدفون القبعات السوداء تحديدا. * يقومون بهجمات قوية لتدمير أدوات المخترقين السود. * قد يفعلون أفعالا غير قانونية. ## القبعات الزرقاء (Blue Hats) \n* يخترقون لأغراض شخصية. * يسعون للانتقام أو التشهير. * يقومون بسرقة بيانات أو تخريب أنظمة. ## القبعات البيضاء (White Hats) \n* ي عرفون ب \"المخترقين الأخلاقيين \". * يكتشفون الثغرات بهدف إصلاحها. * يعملون لدى الشركات لتعزيز الأمن. * لا يكشفون الثغرات قبل إصلاحها. ## القبعات السوداء (Black Hats)", | |
| "chunk_id": 22 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 10, | |
| "text": "* ي عرفون ب \"Crackers\". * يقومون بأعمال تخريبية أو سرقة بيانات. * ي روجون أدواتهم الخاصة. * يصعب اكتشافهم بسبب خبرتهم العالية. * أفعالهم غير قانونية. ## القبعات الرمادية (Grey Hats) \n* يخترقون بدافع الفضول أو التسلية. * قد يسببون إصلاحا أو تخريبا. * لا يملكون مصلحة شخصية. * ما يفعلونه يبقى غير قانوني. ## الهاكتيفيست (Hacktivists) \n* يخترقون بدافع سياسي أو اجتماعي. * يوجهون الرأي العام لقضية معينة. * مشهورة وصفحات التلفزيون يخترقون ومواقع حكومية.", | |
| "chunk_id": 23 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-1.pdf", | |
| "page": 11, | |
| "text": "ماذا يمكن أن يفعل المهاجمون؟ (What Can Attackers Do?) قد ينفذ المهاجم الأنشطة التالية: * التنصت (Eavesdropping): سرقة البيانات أثناء انتقالها. * الانتحال (Spoofing): تعديل البيانات أو إخفاء الهوية. * هجمات الخدمة (DoS): منع وصول البيانات أو إغراق الأنظمة بحزم ضخمة. * الاختراق (Break In): تثبيت برمجيات مثل Keyloggers للتجسس. ## <The End>", | |
| "chunk_id": 24 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 1, | |
| "text": "## السلام عليكم يا أصدقاء \nفي المحاضرة السابقة تعر فنا على مفهوم الأمن السيبراني وأهميته في حماية البيانات والأنظمة، ومستويات الحماية المختلفة، وأهم المنظمات العالمية، ونماذج CIA و AAA. كما تعرفنا على مراحل العملية الأمنية وأنواع المخاطر والمخترقين ودوافعهم. و في هذه المحاضرة سنقوم بالحديث عن التشفير المتناظر وغير المتناظر وغيرها من المفاهيم إن شاء الله. . ## Secret-Key Encryption (التشفير المتناظر) \nتشفير المفتاح السري هو نوع من أنظمة التشفير التي يستخدم فيها نفس المفتاح لعمليتي التشفير وفك التشفير. بمعنى آخر، المرسل والمستقبل. يجب أن يمتلكا نفس المفتاح السري حتى يتمك نا من التواصل بأمان \nهذا المفتاح سري لا يمكن لأحد الاطلاع عليه فبالتالي هذا المفتاح لا يمكن تداوله عن طريق الشبكة و من أهم خوارزميات: هذا النوع AES (Advanced Encryption Standard).", | |
| "chunk_id": 25 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 2, | |
| "text": "## Encryption Modes \n( وضعيات التشفير Encryption Modes ) أو ما ت عرف ب Modes of Operation، هي الطرق التي نستخدمها لجعل مدخلات خوارزمية التشفير مختلفة في كل مرة، حتى لو كان النص الأصلي نفسه. بمعنى آخر، الوضعية تحدد كيف ت قس م وت شف ر الكتل داخل خوارزمية مثل AES. أشهر أوضاع التشفير هي: * 1. ECB -Electronic Codebook \n* 2. CBC -Cipher Block Chaining \n* 3. PCBC -Propagating CBC \n* 4. CFB -Cipher Feedback \n* 5. OFB -Output Feedback \n* 6. CTR -Counter \nكل وضع له طريقة مختلفة في ربط الكتل ببعضها والتعامل مع البيانات، وهذا يؤثر على مستوى الأمان وكفاءة الأداء. ## 1. Electronic Codebook (ECB) Mode", | |
| "chunk_id": 26 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 2, | |
| "text": "* أبسط وضع من أوضاع التشفير. * يتم ( تجزئة النص الأصلي إلى كتل blocks )، وكل كتلة ت شف ر بشكل مستقل باستخدام نفس المفتاح. * هذا يعني: إذا و جدت كتل متطابقة في النص الأصلي ستكون كتل ciphertext الناتجة متطابقة أيض ا. * هذه الخاصية ت عتبر ضعف ا أمني ا، لأنها تكشف أنماط ا في البيانات. * ملاحظة: في الأنظمة التي تحتاج إلى أمان قوي، مثل \nبسبب هذا الضعف، لا ي نصح باستخدام وضع ECB الصور أو الملفات الحساسة. * أمر openssl المستخدم: * -aes-128-ecb: يحدد خوارزمية AES بمفتاح 128 بت ووضع نمط التشفير ECB. * -e. ': يعني 'تشفير \n* -d. ': يعني 'فك تشفير \n* -K: لتحديد المفتاح المستخدم في التشفير أو فك التشفير.", | |
| "chunk_id": 27 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 3, | |
| "text": "## 2. Cipher Block Chaining (CBC) Mode \n* في وضع CBC، لا ت شف ر كل كتلة بشكل مستقل مثل ECB. * يتم ربط الكتل ببعضها، بحيث يتم خلط كل كتلة من النص الأصلي مع الكتلة المشف رة السابقة قبل التشفير. * تستخدم CBC ( قيمة ابتدائية IV - Initialization Vector )، وهي بيانات عشوائية ت ستخدم مع أول كتلة. * الهدف من IV هو ضمان أن ( حتى لو كان النصان الأصليان متطابقين، فإن الناتج ciphertext ) سيكون مختلف ا بسبب اختلاف ال IV. ## المميزات: * تشفير أكثر أمان ا من ECB. * لا يمكن تنفيذ التشفير بشكل متوازي. ) (لأن كل كتلة تعتمد على السابقة", | |
| "chunk_id": 28 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 3, | |
| "text": "* لكن يمكن تنفيذ فك التشفير بشكل متوازي. ## خطوات التشفير في CBC Mode: * 1. أول كتلة من النص الأصلي ت عمل عليها XOR مع ال IV ال IV (Initialization Vector) ( هي قيمة عشوائية بحجم الكتلة 128. ) بت عادة نستخدمها بدل الكتلة السابقة لأن أول كتلة ما عندها كتلة قبلها. * 2. ثاني كتلة من النص الأصلي ت عمل عليها XOR مع ناتج التشفير للكتلة السابقة. . . وهكذا تستمر العملية لباقي الكتل. كل كتلة جديدة تعتمد على الناتج المشف ر للكتلة اللي قبلها", | |
| "chunk_id": 29 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 4, | |
| "text": "الهدف من التجر بة هو إظهار تأثير تغيير ال IV (Initialization Vector) على ناتج التشفير، حتى مع نفس النص الأصلي ونفس المفتاح. * أمر openssl المستخدم: ## : الشرح \n* الخطوة 1: أمر التشفير الأول -aes-128-cbc: يحدد خوارزمية AES بمفتاح 128 بت وبوضع CBC. ▪ -e ': يعني Encrypt. ) ' (تشفير ▪ -in plain. txt: الملف النصي الأصلي المراد تشفيره. ▪ -out cipher1. txt: اسم الملف الناتج بعد التشفير. ▪ -K: لتحديد المفتاح المستخدم في التشفير (هنا: 00112233445566778899AABBCCDDEEFF. ) ▪ -iv: لتحديد قيمة ال Initialization Vector (IV) ▪: (هنا 000102030405060708090a0b0c0d0e0f. )", | |
| "chunk_id": 30 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 4, | |
| "text": "الخطوة 2: أمر التشفير الثاني نفس كل الإعدادات السابقة بالضبط، لكن لاحظ الفرق الصغير في ال IV: الأخيرة تغي رت من. . . 0f إلى. . . 0e. النتيجة (عند فحص الملفين باستخدام xxd ( ): النص الأصلي plain. txt ) نفسه، ( والمفتاح K ) نفسه، ( لكن الناتج ciphertext ) مختلف تمام ا بين الملفين! السبب: في وضع CBC، كل كتلة من النص الأصلي ت عمل عليها XOR مع ال IV. ) (في أول كتلة) أو مع الكتلة السابقة (في الباقي لذلك أي تغيير بسيط في ال IV -حتى بت واحد فقط -. يجعل الناتج المشف ر كله مختلف بالكامل", | |
| "chunk_id": 31 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 5, | |
| "text": "* 💡 النتيجة المهمة: ال IV يلعب دورا أساسيا في ضمان أن تشفير نفس البيانات مرتين لا يعطي. نفس الناتج \nهذا يجعل CBC أكثر أمانا من ECB لأنه يمنع ظهور أنماط مكررة في ال ciphertext", | |
| "chunk_id": 32 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 5, | |
| "text": "## 3. Cipher Feedback (CFB) Mode \n* يحو ل خوارزمية التشفير الكتلية إلى ( خوارزمية تدفقية Stream Cipher ). * . ) ت ستخدم لتشفير البيانات التي ت رسل بشكل متتابع (مثل البث أو الاتصالات اللحظية \n* لا تحتاج إلى Padding (حشو) لأن التشفير يتم بتدفق مستمر. * يمكن تنفيذ فك التشفير بشكل متوازي، لكن التشفير نفسه يتم تسلسلي ا. ## مميزات: * ( مناسبة للبيانات في الزمن الحقيقي Real-time. ) \n* أكثر كفاءة في حالات تدفق البيانات المستمر. ## آلية العمل خطوة بخطوة \n* نبدأ ب Initialization Vector (IV). * ندخل ال IV ( في خوارزمية التشفير AES ) ( بالمفتاح السري Key. )", | |
| "chunk_id": 33 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 5, | |
| "text": "* نأخذ الناتج من AES ونستخدمه لإجراء عملية XOR ( مع أول كتلة من النص الأصلي Plaintext Block 1 ) → نحصل على Ciphertext Block 1. * الكتلة المشف رة الناتجة ت ستخدم ك input جديد في الجولة التالية بدل ال IV. * نكر ر نفس العملية لكل كتلة لاحقة. التشفير في CFB لا يمكن تنفيذه بشكل متوازي ( sequential فقط)، لأن كل كتلة تعتمد على الناتج المشف ر للكتلة السابقة. لكن فك التشفير ممكن تنفيذه بشكل متوازي.", | |
| "chunk_id": 34 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 6, | |
| "text": "* 4. Comparing encryption with CBC and CFB \n* الغرض هو ( إظهار الفرق في حجم النص المشف ر ciphertext ) عند استخدام نفس النص الأصلي،: لكن بوضعين مختلفين CBC و CFB. * : مثال Plaintext size = 21 bytes (يعني حجم النص الأصلي المراد تشفيره هو 21 ). بايت", | |
| "chunk_id": 35 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 6, | |
| "text": "## عند استخدام CBC Mode: Ciphertext size = 32 bytes السبب: * خوارزمية AES تعمل على كتل حجمها 16 بايت. * ( النص الأصلي 21 بايت) يعني فيه كتلتين: * = الأولى 16 بايت \n* = الثانية 5 بايت فقط (ناقص 11 بايت لتكمل ال 16 ) \n* لذلك النظام يضيف Padding (حشو) ليملأ الكتلة الثانية بالكامل. * × النتيجة النهائية = كتلتين 16 = بايت 32 بايت. * 🔹 بمعنى: CBC دايم ا ينتج حجم ciphertext. ) مضاعف ا لحجم الكتلة (بسبب الحشو", | |
| "chunk_id": 36 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 6, | |
| "text": "## عند استخدام CFB Mode: ## Ciphertext size = 21 bytes \n( ما عنده حاجة لحشو Padding ) لأن كل بايت من النص ي شف ر مباشرة لحاله. السبب: CFB يشتغل ك Stream Cipher. ) (خوارزمية تدفقية بالتالي الناتج بيكون بنفس حجم النص الأصلي بالضبط.", | |
| "chunk_id": 37 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 7, | |
| "text": "## الفكرة الأساسية: وضع OFB يشبه CFB في كونه يحو ل خوارزمية التشفير الكتلية إلى ( خوارزمية تدفقية Stream Cipher )،. ) \nلكن الفرق الجوهري هو كيف يتم توليد ال Key Stream (سلسلة المفاتيح المستخدمة للتشفير: شرح يوضح العملية الحاصلة في الرسم \nفي الرسم بيكون عندك أسهم متتالية بين مربعات AES وعمليات XOR: ، فخلينا نفص لها عملي ا", | |
| "chunk_id": 38 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 7, | |
| "text": "## التشفير: الخطوة 1 -البداية بال IV \n* نبدأ من قيمة ابتدائية اسمها IV (Initialization Vector). * ال IV تدخل إلى خوارزمية AES ( بالمفتاح السري Key. ) \n* ملاحظة: في هذه الخطوة ما في نص أصلي داخل AES، فقط ال IV. الخطوة 2 -توليد أول Key Stream Block \n* نأخذ ناتج AES من الخطوة الأولى (نسميه O1 - ) هذا هو أول Key Stream Block. * الآن نأخذ هذا O1 ونعمل معه XOR ( مع أول كتلة من النص الأصلي P1 ) الناتج من العملية هو Ciphertext ( الأول C1. )", | |
| "chunk_id": 39 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 8, | |
| "text": "## الخطوة 3 -توليد الكتلة التالية \n* بدل ما نستخدم C1 كمدخل (مثل CFB )، نأخذ O1 نفسه (ناتج التشفير السابق) وندخله مرة ثانية في AES مع نفس المفتاح. * AES يول د O2 (الكتلة الثانية من Key Stream. ) \n* نعمل XOR بين O2 و P2 الناتج C2. ## الخطوة 4 -نكر ر نفس الفكرة لباقي الكتل \n* نول د O3 = Encrypt(O2) \n* : ثم C3 = P3 XOR O3 \n* . . . وهكذا لباقي النص", | |
| "chunk_id": 40 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 8, | |
| "text": "## النتيجة \n* ما في تكرار لاستخدام النص المشف ر كمدخل، فقط ناتج التشفير السابق. * ( لذلك التيار الناتج Key Stream ) يمكن حسابه مسبق ا قبل وصول البيانات أصل ا. * التشفير وفك التشفير يتمان بنفس العملية لأن XOR عملية عكسية. ## لفك التشفير: ## تمام ا نفس الخطوات: * نستخدم نفس IV والمفتاح نول د نفس Key Stream (O1, O2, O3. . . ) \n* ثم نعمل XOR مع كل كتلة مشف رة", | |
| "chunk_id": 41 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 9, | |
| "text": "## 6. Counter (CTR) Mode \n* ( هو في الأساس يستخدم عد اد Counter ( ) لتوليد سلسلة المفاتيح Key Stream ) حيث في وضع CTR، بدل ما يستخدم النص المشف ر السابق مثل CBC أو OFB، يتم استخدام ( عداد رقمي Counter ) يبدأ من رقم معي ن ويزيد واحد في كل كتلة. كل قيمة من هذا العداد ت شف ر باستخدام خوارزمية AES لإنتاج Key Stream Block. كل كتلة من Key Stream ت ستخدم لتشفير كتلة من النص الأصلي عبر XOR. * ( لا يجوز إعادة استخدام أي سلسلة مفاتيح Key Stream )، لذلك يتم دمج العد اد مع قيمة عشوائية ت سمى ال nonce. * هذا ال nonce يلعب نفس دور ال IV في أوضاع التشفير الأخرى: ال IV (Initialization Vector) في CBC و CFB و OFB هدفه إنه يغي ر أول كتلة عشان ما تتكرر النتائج. * ال Nonce في CTR بيؤدي نفس الوظيفة", | |
| "chunk_id": 42 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 9, | |
| "text": "* يمنع تكرار النتائج لو تم استخدام نفس المفتاح أو نفس العد اد أكثر من مرة. * : الفرق IV ي ستخدم لمرة واحدة في الجلسة، Nonce ي دمج مع العد اد في كل كتلة. * . عمليتا التشفير وفك التشفير يمكن تنفيذهما بالتوازي \n* ( سلسلة المفاتيح Key Stream ) في وضع CTR يمكن توليدها بالتوازي أثناء عملية التشفير: في الأوضاع الأخرى، لازم تنتظر ناتج الكتلة السابقة حتى تول د التالية (مثل CBC )، لكن في CTR، لأن كل كتلة Key Stream تعتمد فقط على العداد وال Nonce، * فممكن نحسب كل Key Stream Block مسبق ا قبل حتى وصول البيانات. * وهذا يجعل CTR سريع جد ا. ) ومناسب للتطبيقات اللي تحتاج أداء عالي (مثل الشبكات أو الأقراص المشف رة", | |
| "chunk_id": 43 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 10, | |
| "text": "## Modes for Authenticated Encryption \n( كل الأوضاع السابقة ECB، CBC، CFB، OFB، CTR ) توفر السرية فقط، لكنها لا تضمن سلامة البيانات أو أصالتها. * لذلك ظهرت أوضاع جديدة مثل: * 1. GCM (Galois/Counter Mode) \n* يعتمد على CTR ' للتشفير، ويضيف إليه خوارزمية رياضية اسمها Galois ' للتحقق من سلامة البيانات. * ينتج Tag (علامة تحقق) ت ستخدم عند فك التشفير للتأكد إن البيانات ما تم تعديلها. * 2. CCM (Counter with CBC-MAC) \n* يجمع بين CTR للتشفير و CBC-MAC للتحقق من سلامة الرسالة. * 3. OCB (Offset Codebook Mode) \n* وضع متطور وسريع، يدمج التشفير والتحقق بخطوة واحدة. 🔹 الخلاصة: هذه الأوضاع تحقق نوعين من الأمان مع ا: Confidentiality (السرية) Integrity (سلامة البيانات)", | |
| "chunk_id": 44 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 10, | |
| "text": "## Padding \nPadding معناها حشو البيانات ( لتتناسب مع حجم الكتلة Block Size. ) مثلا: * خوارزمية AES تشتغل على كتل حجمها 16 بايت. * إذا كان النص الأصلي طوله 9 بايت فقط لازم نضيف 7 بايت حشو. ## كيف يتم الحشو: يتم ملء الفراغ بالعدد الذي يعب ر عن عدد البايتات المضافة. مثلا: Plaintext = [41 42 43 44 45 46 47 48 49] Padding = [07 07 07 07 07 07 07] = النتيجة 16. ) بايت (كتلة كاملة", | |
| "chunk_id": 45 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 11, | |
| "text": "## PKCS# 5 / PKCS# 7 \n* متشابهتين تقريب ا، والفرق بسيط في أن PKCS# 7 تدعم أحجام كتل مختلفة. * الخوارزمية أثناء فك التشفير تعرف من القيم المضافة أين يبدأ الحشو وتحذفه. ## Padding Experiment \nPlaintext size = 9 bytes Ciphertext size = 16 bytes", | |
| "chunk_id": 46 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 11, | |
| "text": "## الشرح: * النص الأصلي طوله 9 بايت فقط، لذلك لا يكفي كتلة AES الكاملة. * النظام أضاف Padding ب 7 بايت (ليصير 16. ) بايت \n* = بعد التشفير، الكتلة المشف رة الناتجة حجمها 16 بايت. وهكذا دوما في CBC أو أي Block Cipher Mode يحتاج حشو: حجم ciphertext دايم ا مضاعف لطول الكتلة. * عملية نقل المفتاح كانت تمث ل مشكلة في التشفير المتناظر، لأن أي شخص يعترض المفتاح أثناء انتقاله سيستطيع فك تشفير كل البيانات لاحقا. بمعنى آخر، أمن النظام كله كان يعتمد على سرية هذا المفتاح، ونقله عبر قناة غير آمنة كان مخاطرة كبيرة. لذلك ظهر التشفير بالمفتاح الع. ام ليحل هذه المشكلة ويتيح تبادل المفاتيح بشكل آمن", | |
| "chunk_id": 47 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 12, | |
| "text": "## Public Key Cryptography ) (التشفير الغير المتناظر \n( في هذا القسم سنتعرف على مفهوم التشفير بالمفتاح العام Public Key Cryptography )، وهو أحد أهم أساسيات الأمن السيبراني. تكمن الفكرة الأساسية فيه في أنه بدل ا من استخدام الطرفين لنفس المفتاح في التشفير، يكون لكل شخص مفتاح عام ومفتاح خاص. * المفتاح العام: مفتاح ي نشر ويمكن إعطاؤه لأي شخص. * المفتاح الخاص: مفتاح يظل سري ا ولا يجوز لأحد الاطلاع عليه. ي ستخدم هذا النوع من التشفير عادة لتأمين الاتصال، وتبادل المفاتيح، وتوقيع البيانات. ## RSA Algorithm \nخوارزمية RSA هي أشهر خوارزمية مستخدمة بالتشفير غير المتماثل. ( تعتمد على صعوبة تحليل الأعداد الكبيرة لعواملها factoring. )", | |
| "chunk_id": 48 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 12, | |
| "text": "## RSA: Key Generation \nلتوليد مفاتيح RSA، نعمل الخطوات التالية: 1️⃣ اختيار ر قمين أوليين كبيرين جد ا: نسميهم: p q 2️⃣ نحسب n = p × q وال n هو قيمة مهمة لأنها تكون جزء من المفتاح العام والمفتاح الخاص. 3️⃣: حساب دالة أويلر φ ( n) = (p - 1) × (q - 1) 4️⃣ اختيار المفتاح العام e يجب أن يكون: أكبر من 1 وأصغر من φ (n): والأهم أن يكون coprime مع φ (n) (ما في عامل مشترك بينهم غير 1 ) 5️⃣ حساب المفتاح الخاص d وهو العدد الذي يحقق: ( e × d ) mod φ (n) = 1 هذا الشي يعني إن d هو المعكوس الضربي للمفتاح e. النتيجة:", | |
| "chunk_id": 49 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 13, | |
| "text": "( = المفتاح العام e, n ) = المفتاح الخاص d", | |
| "chunk_id": 50 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 13, | |
| "text": "## Hybrid Encryption \n) قوي جد ا، لكنه بطيء لما بدنا نشف ر كمية كبيرة من البيانات. التشفير بالمفتاح العام (مثل RSA لذلك نستخدم طريقة اسمها التشفير الهجين: * نستخدم RSA ( \" فقط لتبادل \"مفتاح جلسة Session Key ) \n* بعدها نستخدم خوارزمية تشفير تماثلية (مثل AES ) لتشفير البيانات لأنها أسرع بكتير. ## يعني: RSA = لحماية مفتاح التشفير فقط AES = لتشفير المحتوى لأنه أسرع", | |
| "chunk_id": 51 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 13, | |
| "text": "## OpenSSL Tools: Generating RSA keys \nExample: generate a 1024-bit public/private key pair openssl genrsa -aes128 -out private. pem 1024", | |
| "chunk_id": 52 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 13, | |
| "text": "## شرح كل جزء \n* openssl. ). . . الأداة الم ستخدمة لإجراء عمليات التشفير المختلفة (مثال: توليد مفاتيح، حساب هاش، تشفير/فك تشفير \n* genrsa الأمر داخل OpenSSL لتوليد زوج مفاتيح RSA (خاص/عام). * -aes128 هذا الخيار يشفر المفتاح الخاص داخل الملف بواسطة خوارزمية AES-128 ويطلب منك عبارة مرور ( passphrase ) لحماية الملف. بمعنى عملي: حتى لو س رق ملف private. pem، لا يمكن استعماله بدون كلمة المرور. * out private. pem يحدد اسم الملف الناتج الذي سي حفظ فيه المفتاح الخاص - هنا اخترنا private. pem (صيغة PEM النص ية المشهورة التي تحتوي بيانات مشفر ة بترميز Base64. )", | |
| "chunk_id": 53 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 14, | |
| "text": "## OpenSSL Tools: Extracting Public Key \nنستخدم أمر OpenSSL لاستخراج المفتاح العام من ملف المفتاح الخاص. الأمر يقوم بقراءة private. pem ( وإنتاج ملف جديد يحتوي على المفتاح العام public. pem. ) \n1024 \n▪ \nهو طول المفتاح (ب ت) - أي حجم المفتاح الذي سيتم توليده. ## private. pem: Base64 encoding of DER generated binary output", | |
| "chunk_id": 54 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 14, | |
| "text": "## Actual Content of private. pem \n( الشكل الفعلي لملف المفتاح الخاص private. pem. ) \nالمحتوى عبارة عن نص طويل م رم ز بصيغة Base64، وهو تمثيل للمفتاح الخاص ولا يحتاج فهم تفاصيله، الهدف فقط. رؤية شكله الداخلي", | |
| "chunk_id": 55 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 15, | |
| "text": "openssl rsa -in private. pem -pubout > public. pem", | |
| "chunk_id": 56 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 15, | |
| "text": "## هذا الأمر: * يقرأ المفتاح الخاص من ملف private. pem \n* يستخرج منه المفتاح العام \n* يحفظه بملف جديد اسمه public. pem \nContent of public. pem: ## OpenSSL Tools: Encryption and Decryption \nالمبدأ الأساسي لعمل خوارزمية RSA، والمتمث ل في عمليتي التشفير و فك التشفير: Plain Text: ) (نص عادي \nEncryption: ) (التشفير \nيتم تشفير النص الأصلي باستخدام المفتاح العام الخاص بالمستلم. وبذلك يمكن لأي شخص يمتلك المفتاح العام أن ي شف ر رسالة، لكن لا يمكنه فك ها. . هذه العملية تضمن أن الرسالة المشف رة لا يستطيع قراءتها إلا صاحب المفتاح الخاص", | |
| "chunk_id": 57 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 16, | |
| "text": "## One-Way Hash Functions \nت عد دوال الهاش أحادية الاتجاه من المكو نات الأساسية في علم التشفير. تتمي ز بأنها تنتج قيمة ثابتة الطول من أي مدخلات، مع خاصيتين مهمتين: * أحادية الاتجاه: من الصعب للغاية استرجاع البيانات الأصلية من قيمة الهاش. * مقاومة التصادم: من الصعب إيجاد مدخلين مختلفين يمتلكان القيمة نفسها. ت ستخدم هذه الدوال في عد ة تطبيقات مثل: * التحق ق من كلمات المرور \n* ( ضمان سلامة البيانات Integrity )", | |
| "chunk_id": 58 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 16, | |
| "text": "## Properties of One-Way Hash Function \n' الفرق بين Hash Function ' العامة و' One-Way Hash Function: دالة الهاش بشكل عام: تحو ل بيانات بأي حجم إلى قيمة ثابتة الطول. مثال بسيط: f(x) = x mod 1000", | |
| "chunk_id": 59 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 16, | |
| "text": "## خصائص دوال الهاش أحادية الاتجاه: * أحادية الاتجاه: إذا كان لدينا h = hash(m)، فمن الصعب إيجاد m من h. * مقاومة التصادم: من الصعب إيجاد m1 و m2 بحيث يكون hash(m1) = hash(m2). Decryption: ) ( فك التشفير \nت فك الرسالة المشف رة باستخدام المفتاح الخاص فقط، وهو مفتاح لا يمتلكه إلا صاحب الرسالة. وبالتالي، حتى لو وصلت الرسالة المشف رة إلى شخص آخر، فلن يتمك ن من استعادتها إلى صورتها الأصلية دون امتلاك. المفتاح الخاص", | |
| "chunk_id": 60 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 17, | |
| "text": "## أشهر دوال الهاش أحادية الاتجاه: * MD series \n* SHA series", | |
| "chunk_id": 61 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 17, | |
| "text": "## صادرة عن معهد NIST وتتضمن عد ة إصدارات: * SHA-0: تم سحبها بسبب وجود ثغرة. * SHA-1: ص م مت بواسطة NSA، وتم إيجاد هجوم تصادم عليها عام 2017. * SHA-2: تشمل SHA-256 و SHA-512. بإصدارات مختلفة، وحتى الآن لا توجد هجمات قوية عليها \n* SHA-3: أ طلق عام 2015 وله بنية مختلفة تماما عن SHA-1 و SHA-2. ## How One-Way Hash Algorithm Works \nتعمل العديد من خوارزميات الهاش (مثل MD5 و SHA-1 و SHA-2 ) اعتمادا على بنية اسمها Merkle -Damg å rd Construction. تقوم هذه البنية بتقسيم البيانات إلى كتل صغيرة، ثم ت عال ج كل كتلة تدريجيا لتكوين قيمة الهاش النهائية. ## One-Way Hash Commands (Contd) \nيعرض استخدام أمر OpenSSL لحساب الهاش. الهدف إظهار طريقة إضافية بجانب أدوات لينكس التقليدية، لإجراء عمليات الهاش عبر: openssl dgst -sha256 file. txt \nهكذا يتم حساب هاش باستخدام خوارزمية SHA-256.", | |
| "chunk_id": 62 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 18, | |
| "text": "## Applications of One-Way Hash Functions \nيوض ح التطبيقين الأساسيين لدوال الهاش: * ( التحقق من سلامة البيانات Integrity Verification ) \n* ( التحقق من كلمات المرور Password Verification ) \n* Integrity Verification \nتتمتع دوال الهاش بحساسية عالية، بحيث يؤدي تغيير بسيط جدا -حتى بت واحد فقط -إلى تغي ر كامل في قيمة الهاش. ت ستخدم هذه الخاصية في: * اكتشاف أي تعديل على ملفات النظام \n* كشف فساد أو تغيير ملف تم تحميله من الإنتر نت \nفالهاش الأصلي ي قارن بالهاش الجديد لمعرفة إذا حدث أي تغيير. ## Password Verification \nلا يمكن تخزين كلمات المرور بصورتها الحرفية، لأن أي اختراق سيكشف جميع كلمات المرور. الحل هو: * تخزين قيمة الهاش لكلمة المرور \n* وعند تسجيل الدخول، ي عاد حساب الهاش لكلمة المرور المدخلة \n* ثم مقار نتها بالهاش المخز ن", | |
| "chunk_id": 63 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 18, | |
| "text": "* وعند تسجيل الدخول، ي عاد حساب الهاش لكلمة المرور المدخلة \n* ثم مقار نتها بالهاش المخز ن \nهكذا يتم التحقق دون معرفة كلمة المرور الفعلية. مثال شهير: ملف / etc/shadow في لينكس.", | |
| "chunk_id": 64 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-2.pdf", | |
| "page": 19, | |
| "text": "## Case Study: Linux Shadow File \nيخز ن نظام لينكس كلمات المرور في ظل حماية قوية عبر ثلاث عناصر: 1. الخوارزمية المستخدمة 2. Salt (سلسلة عشوائية ت ضاف لضمان التفر د) 3. Hash القيمة النهائية وي عاد تطبيق الهاش لعد ة جولات لجعل هجمات ال brute-force أصعب. ## Purpose of Salt \nال Salt يمنع أن يكون نفس الإدخال دائما بنفس الهاش. الحساب النهائي: hash(password || salt) حيث || يعني عملية الدمج. وهذا يضمن أن شخصين لديهما كلمات مرور متطابقة سيحصلان على هاشات مختلفة. ## Attacks Prevented by Salt", | |
| "chunk_id": 65 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 1, | |
| "text": "## مقدمة: في المحاضرة السابقة تعر فنا على أهم أساليب حماية البيانات الحديثة، وناقشنا بالتفصيل الفرق بين التشفير المتناظر الذي يستخدم مفتاح ا واحد ا سر ي ا، وبين التشفير غير المتناظر الذي يعتمد زوج ا من المفاتيح (عام ا وخاص ا). كما رأينا كيف يجمع التشفير الهجين بين السرعة العالية للتشفير المتناظر، وقوة التشفير غير المتناظر في تبادل المفاتيح. اليوم سننتقل خطوة أعمق في عالم الأمن، فبعد أن تعل منا كيف نحمي سر ية البيانات، سنرك ز على كيفية حماية أصالتها وسلامتها. أي: كيف نثبت أن الرسالة جاءت فعلا من المرس ل الحقيقي، وكيف نكتشف أي تعديل حدث عليها أثناء عبورها عبر الشبكة. ولهذا سنبدأ بدراسة مفهوم التوقيع الرقمي، وسنشرح كيف يعتمد على كل ما تعل مناه سابق ا من مفاهيم المفاتيح، التجزئة، والتشفير غير المتناظر. وبعدها سنربط هذه المفاهيم بمثال عملي بين \"أليس\" و\"بوب\" لفهم سير العملية كاملة من لحظة إرسال", | |
| "chunk_id": 66 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 1, | |
| "text": "وبعدها سنربط هذه المفاهيم بمثال عملي بين \"أليس\" و\"بوب\" لفهم سير العملية كاملة من لحظة إرسال الرسالة وحتى التحقق منها. ## ( مراجعة سريعة للتشفير الهجين Hybrid Encryption: )", | |
| "chunk_id": 67 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 1, | |
| "text": "التشفير باستخدام المفتاح العام (Public Key Encryption) بطيء جدا ويحتاج قدرة حسابية كبيرة، لذلك يعتبر غير مناسب لتشفير ملفات كبيرة أو داتا كثيرة فجاء استخدام التشفير الهجين ك حل لهذه المشكلة حيث يدمج بين التشفير بالمفتاح العام (Public-Key Encryption) والتشفير بالمفتاح المتماثل Symmetric Encryption) ( وذلك بهدف الاستفادة من مزايا كل منهما وتجاوز عيوبهما. * Public Key Encryption نستخدمه فقط لتبادل مفتاح جلسة (Session Key) صغير وسري. * Symmetric Key Encryption بعد ان نستلم مفتاح الجلسة نستخدمه لتشفير البيانات الفعلية لأن التشفير المتماثل: * أسرع \n* أخف \n* مناسب للملفات الكبيرة", | |
| "chunk_id": 68 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 2, | |
| "text": "* النتيجة: * Hybrid Encryption = Public Key + Symmetric Key وهذا هو الاسلوب المستخدم في: HTTPS -WhatsApp -TLS -PGP", | |
| "chunk_id": 69 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 2, | |
| "text": "## ( التوقيع الرقمي Digital Signature ) \nالتوقيع الرقمي هو آلية تهدف إلى إثبات أصالة الم رسل والتأكد من أن الرسالة صادرة فعلا عن صاحب المفتاح الخاص، ولم يتم تعديلها أثناء النقل. وهذا التوقيع لا ي نشأ إلا باستخدام المفتاح الخاص للمرسل، لذلك لا يستطيع أحد غيره إنشاء توقيع صحيح. ## الخلفية التاريخية \n* اقترح Diffie -Hellman فكرة التوقيع الرقمي نظريا، لكن دون تقديم خوارزمية عملية جاهزة للاستخدام. * المخترعون الذين قد موا خوارزمية RSA هم أول من قد م تطبيقا عمليا للتوقيع الرقمي.", | |
| "chunk_id": 70 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 3, | |
| "text": "## التوقيع باستخدا م RSA \nكيف يعمل التوقيع باستخدا م RSA؟ ع الرسالة يأخذ الموق 𝒎 ق عليها العملية الآتية ويطب: ## Signature = 𝒎 𝒅 𝐦𝐨𝐝 𝒏 \nتستخدم خوارزمية RSA معادلات رياضية بسيطة في شكلها، لكنها تعب ر عن عمليات تشفير حقيقية. فيما يلي شرح الرموز: * 𝒎: الرسالة أو قيمة التجزئة المراد توقيعها \n* 𝒅: المفتاح الخاص للمرس ل \n* 𝒏: جزء من المفتاح العام والخاص مع ا \n* العملية 𝒎 𝒅 𝐦𝐨𝐝 𝒏 ل تشفير الهاش باستخدام المفتاح الخاص، وهذا هو التوقيع الرقمي تمث \nوبما أن كل شخص يمتلك المفتاح العام يستطيع استخراج الرسالة من التوقيع، فهذا يثبت أن صاحب المفتاح الخاص هو من أنشأ التوقيع. ## مشكلة الرسائل الطويلة \nإذا كانت الرسالة كبيرة، فإن حساب هذه العملية سيؤدي إلى توقيع ضخم، مما يستهلك وقتا كبيرا. لذلك يتم توقيع قيمة تجزئة (Hash) للرسالة بدل توقيع الرسالة كاملة. ## توليد قيمة التجزئة ( Generate message hash )", | |
| "chunk_id": 71 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 3, | |
| "text": "## في هذه الخطوة يتم: * تمرير الرسالة إلى دال ة تجزئة مثل SHA-256 \n* الحصول على قيمة تجزئة قصيرة وثابتة الطول \n* التوقيع يتم على هذه القيمة فقط وليس على كامل الرسالة", | |
| "chunk_id": 72 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 3, | |
| "text": "## لماذا نستخدم التجزئة؟ * لأنها صغيرة الحجم \n* سريعة الحساب \n* أي تغيير بسيط في الرسالة يغي ر قيمة التجزئة كلي ا", | |
| "chunk_id": 73 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 4, | |
| "text": "* شرح بسيط للتعليمات: * openssl sha256 -binary msg. txt يحسب هاش SHA-256 للملف. * > msg. sha256 يحفظ الهاش في ملف جديد. * xxd msg. sha256 يعرض الهاش الثنائي بصيغة هيكس + ASCII ليصبح مقروءا. ## إنشاء التوقيع والتحقق منه ( Generate and verify the signature ) \n* أولا: إنشاء التوقيع \n* توليد قيمة تجز ئة للرسالة \n* تطبيق المفتاح الخاص على التجزئة للحصول على التوقيع \n* ثانيا: التحقق من التوقيع \n* توليد قيمة تجزئة جديدة من الرسالة المستلمة \n* فك التوقيع باستخدام المفتاح العام للحصول على التجزئة الأصلية \n* مقارنة القيمتين: * إذا كانتا متطابقتين: التوقيع صحيح \n* إذا اختلفتا: الرسالة أو التوقيع قد تم تعديلهم ا", | |
| "chunk_id": 74 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 4, | |
| "text": "## السيناريو الكامل لعملية إرسال رسالة آمنة وتوقيعها بين أليس وبوب \nلضمان سر ية الرسالة وأصالتها وسلامتها، تتم العملية بين أليس (المرس لة) وبوب (المستقب ل) كما يلي: * 1. تول د أليس مفتاح ا متناظر ا (Secret Key) مثل مفتاح AES، لأن التشفير المتناظر سريع جد ا ويصلح للملفات الكبيرة.", | |
| "chunk_id": 75 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 5, | |
| "text": "* 2. تشف ر أليس محتوى الرسالة باستخدام هذا المفتاح المتناظر. * 3. ولأن ال Secret Key يجب أن ي رسل إلى بوب بشكل آمن، تقوم أليس ب تشفير المفتاح المتناظر باستخدام المفتاح العام لبوب (تشفير غير متناظر) \n* 4. عند وصول الرسالة، يفك بوب تشفير المفتاح المتناظر باستخدام مفتاحه الخاص، ثم يستخدمه لفك تشفير الرسالة. * 5. بعد تحقيق سر ية البيانات، تنتقل أليس لضمان أصالة الرسالة وسلامتها عبر التوقيع الرقمي: * 6. تحو ل أليس الرسالة (قبل التشفير أو بعدها) إلى قيمة تجزئة (Hash). * 7. توق ع أليس قيمة التجزئة باستخدام مفتاحها الخاص للحصول على التوقيع الرقمي. * 8. ترسل أليس إلى بوب: * الرسالة المشف رة \n* المفتاح المتناظر المشف ر \n* التوقيع الرقمي", | |
| "chunk_id": 76 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 5, | |
| "text": "* المفتاح المتناظر المشف ر \n* التوقيع الرقمي \n* 9. وعند الاستقبال يتحقق بوب من صحة التوقيع: * 10. يفك بوب التوقيع الرقمي باستخدام المفتاح العام لأليس لاستعادة الهاش الأصلي الذي وق عته. * 11. يول د بوب قيمة تجزئة جديدة من الرسالة بعد فك تشفيرها. * 12. يقارن بوب بين الهاشين: * إذا كانا متطابقين: التوقيع صحيح، والرسالة أصلية وغير معد لة. * إذا: اختلفا فهذا يعني أن الرسالة تم التلاعب بها أو أن التوقيع غير صحيح. ## تجربة هجوم على التوقيع الرقمي: لماذا لا ينجح المهاجم؟ ## لأن: * المهاجم لا يمتلك المفتاح الخاص، وبالتالي لا يستطيع توليد توقيع صحيح. * إذا قام بتعديل الرسالة، حتى لو عد ل بت واحد فقط، فإن قيمة التجز ئة الجديدة ستختلف كليا. * لذلك لن تتطابق مع القيمة المستخرجة من التوقيع. ## التجربة المقترحة", | |
| "chunk_id": 77 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 5, | |
| "text": "تعديل جزء صغير من ملف التوقيع (msg. sig) ثم محاولة التحقق: النتيجة ستكون \"توقيع غير صالح \". عند تطبيق المفتاح العام RSA على التوقيع: * نحصل على كتلة بيانات تمث ل قيمة التجزئة الأصلية. * في حال كان التوقيع م عد لا، فإن البيانات الناتجة تكون مختلفة بالكامل، ولا تتطابق مع تجزئة الرسالة الحقيقية.", | |
| "chunk_id": 78 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 6, | |
| "text": "## التوقيع الرقمي: * يضمن أصالة الم رسل \n* يكشف أي تعديل على الرسالة \n* يمنع المهاجم من إنشاء توقيع مزيف دون معرفة المفتاح الخاص", | |
| "chunk_id": 79 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 6, | |
| "text": "## ما هي البنية التحتية للمفاتيح العامة؟ (Public Key Infrastructure -PKI) \nهي منظومة متكاملة لإدارة مفاتيح التشفير العام، والتحقق من الهويات الرقمية. وهدفها الأساسي: ربط هوية محددة بمفتاح عام، بطريقة يمكن الوثوق بها. التشفير بالمفتاح العام قد م لنا حل ا مهم ا: إمكانية إرسال رسالة مشف رة لشخص ما باستخدام مفتاحه العام، بحيث لا يستطيع فك ها إلا هو وحده لأن ه يملك المفتاح الخاص. لكن … ظهرت مشكلة خطيرة: عندما يريد بوب أن يحصل على المفتاح العام لأليس، كيف يتأكد أن المفتاح الذي استلمه هو بالفعل مفتاح أليس وليس مفتاح مهاجم ينتحل شخصيتها؟ هنا يبدأ موضوع المحاضرة. كل ما سيأتي لاحقا في PKI يهدف لحل هذه المشكلة تحديد ا.", | |
| "chunk_id": 80 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 7, | |
| "text": "## Man-in-the-Middle Attack \nإذا نجح المهاجم في الوقوف بين أليس وبوب، يمكنه أن: * يعترض الرسائل \n* يستبدل المفتاح العام الحقيقي بمفتاحه \n* يخدع الطرفين بأن الاتصال بينهما آمن \nلكن بالحقيقة … المهاجم يرى كل شيء. هذا الهجوم ي سم ى الرجل في المنتصف (MITM)، وهو السبب الرئيسي لظهور PKI. ## ▪ ما هي المشكلة الأساسية؟ الجوهر كله في جملة واحدة: \" بوب لا يملك أي وسيلة ليتأكد أن المفتاح العام الذي بين يديه يخص أليس فعل ا. \" \nتمام ا كما لو استلمت رسالة من رقم غريب يد عي أنه صديقتك … \nكيف تعرفين أنها هي وليس أحد ا آخر؟ نحن بحاجة إلى مصدر وثوق أعلى من الطرفين. ## : الحل \nوجود طرف ثالث موثوق \nهذا الطرف مسؤول عن \nTrusted Third Party: * التأكد من هوية أليس \n* التأكد من امتلاكها للمفتاح العام \n* ثم ربط هويتها بمفتاحها داخل شهادة رقمية \n* وأخير ا: توقيع هذه الشهادة لتصبح غير قابلة للتزوير", | |
| "chunk_id": 81 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 7, | |
| "text": "* ثم ربط هويتها بمفتاحها داخل شهادة رقمية \n* وأخير ا: توقيع هذه الشهادة لتصبح غير قابلة للتزوير \nوهكذا، عندما يستلم بوب الشهادة، يستطيع التحقق منها دون الرجوع لأليس مباشرة. هذا الطرف يسمى: Certificate Authority (CA) \nتمنح شهادات رقمية", | |
| "chunk_id": 82 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 8, | |
| "text": "## مراجعة ل خصائصه الأساسية: * لا يستطيع إنشاء التوقيع إلا صاحب المفتاح الخاص \n* يستطيع الجميع التحقق من التوقيع باستخدام المفتاح العام \n* إذا لم يجر التلاعب بالرسالة، فإن النص المفكوك (M') يطابق النص الأصلي (M)", | |
| "chunk_id": 83 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 8, | |
| "text": "## التوقيع الرقمي يضمن: * صحة الرسالة \n* عدم تعديلها \n* أن مصدرها حقيقي", | |
| "chunk_id": 84 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 8, | |
| "text": "## تعريف: ## هي جهة موثوقة مسؤولة عن: * التحقق من هوية المستخدمين \n* إصدار شهادات رقمية تثبت ملكيتهم للمفاتيح العامة \n* توقيع هذه الشهادات رقميا لمنع التلاعب بها", | |
| "chunk_id": 85 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 9, | |
| "text": "## الشهادة الرقمية (Digital Certificate): ## تتضمن عادة: * هوية مالك الشهادة مثلا: (PayPal) \n* المفتاح العام الخاص به \n* هوية الجهة التي أصدرت الشهادة مثل: (Symantec) \n* التوقيع الرقمي الخاص بال CA \nالتعليمة التي يجب التركيز عليها هي: وهذه التعليمة هي الوسيلة العملية التي ت مك نك من: * الاتصال بخادم PayPal عبر بروتوكول TLS \n* استخراج سلسلة الشهادات التي يرسلها الخادم \n* عرضها في (Terminal) \n* نسخها وحفظها في ملف للاستخدام اللاحق", | |
| "chunk_id": 86 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 9, | |
| "text": "## شرح التعليمة خطوة: بخطوة \n* openssl \nبرنامج يستخدم لإدارة التشفير والشهادات. * s_client \nأداة داخل OpenSSL تمك نك من الاتصال بأي خادم يستخدم SSL/TLS. * -showcerts \nيطلب من الخادم أن يرسل جميع الشهادات ضمن سلسلة الثقة، وليس الشهادة الأساسية فقط. * -connect www. paypal. com: 443 \nالاتصال بخادم PayPal على المنفذ 443 المنفذ القياسي ل HTTPS. * </dev/null \nيسمح للأمر بأن يعمل دون انتظار إدخال إضافي من المستخدم، وينهي الجلسة مباشرة بعد عرض الشهادات.", | |
| "chunk_id": 87 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 10, | |
| "text": "الصورة ت ظهر مثال ا للشهادة بعد تنفيذ الأمر، ويظهر فيها نص الشهادة بالتنسيق PEM، أي: * ترويسة BEGIN CERTIFICATE \n* بيانات Base64 \n* نهاية END CERTIFICATE \nالصورة المعروضة تظهر نتيجة تنفيذ الأمر السابق. ما تحتويه الصورة: * Issuer الجهة الم صد رة ): مثال (Symantec \n* Subject صاحب الشهادة ): مثال (PayPal \n* Validity: تاريخ البداية والنهاية \n* Serial Number \n* Signature Algorithm \nهذه البيانات مأخوذة من قلب الشهادة بعد فك ترميزها. The CA's identity (Symantec) The owner of the certificate (paypal)", | |
| "chunk_id": 88 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 11, | |
| "text": "Public key CA's signature \nالصورة هنا ت ظهر الجزء الثاني من مخرجات الأمر. ماذا تعرض الصورة؟ * Public Key: المفتاح العام لمالك الشهادة \n* Key Length: طول المفتاح (مثل 2048 بت) \n* CA's Signature: توقيع سلطة الشهادة \n* Extensions مثل: * Key Usage \n* Extended Key Usage \n* Certificate Policies \nهذه البيانات مهمة لأنها تحدد الدور الأمني للشهادة. ## الوظائف الأساسية لسلطة الشهادات (CA) \n* . التحقق من الهوية (Verify the subject) التأكد من أن مقد م الطلب يملك فعلا الهوية المذكورة. * 1 \n* 2. توقيع الشهادات (Signing Certificates) توقيع الشهادة باستخدام المفتاح الخاص لل CA. * 3. بعد التوقيع لا يمكن تعديل الشهادة. * 4. يستطيع أي شخص التحقق من التوقيع باستخدام المفتاح العام لل CA.", | |
| "chunk_id": 89 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 12, | |
| "text": "## كيف تصبح جهة إصدار شهادات؟ (Being a Certificate Authority) \nلإنشاء سلطة شهادات باسم Model CA نحتاج إلى: * توليد زوج من المفاتيح (عام/خاص) \n* إنشاء شهادة X. 509 \n* كيف نتحقق من شهادة موق عة ذاتيا؟ * الإجابة: لا توجد طريقة للتحقق منها ر قميا \nوبما أن Model CA هي سلطة جذرية (Root CA) فهي توق ع شهادتها بنفسها: ▪ Self-signed Certificate: شهادة موق عة ذاتيا يقوم الأمر التالي بإنشاء شهادة X. 509 موقعا ذاتيا: . لذلك يعتمد الأمر على مصدر الحصول عليها: * إذا جاءت مع نظام التشغيل نثق بها \n* إذا جاءت مع المتصفح أو برنامج معروف نثق بها \n* إذا أضفناها يدويا نثق بقرارنا \n* إذا جاءت من جهة مجهولة لا نثق بها", | |
| "chunk_id": 90 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 12, | |
| "text": "## 1. توليد زوج مفتاح عام/خاص \nويتم تشفير المفتاح الخاص ب AES لحمايته. عادة يستخدم: * RSA Key حجم 2048 أو 4096 \n* تشفير الملف باستخدام AES-128", | |
| "chunk_id": 91 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 13, | |
| "text": "2. Step 2: Certificate Signing Request (CSR) مصطلح: CSR = طلب توقيع الشهادة الخطوة الثانية: توليد CSR وهو ملف يحتوي: ▪ ). . . معلومات الهوية (البلد، الشركة، عنوان الموقع ▪ المفتاح العام الخاص بك هذا الملف ي رسل لل CA. ال CA تتحقق من الهوية قبل التوقيع. CA will verify this subject information", | |
| "chunk_id": 92 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 13, | |
| "text": "## CA Issuing X. 509 Certificates \n* البنك عنده ملف CSR (Certificate Signing Request)، وهدفه إرسال هذا الملف إلى Model CA. * Model CA تعمل عملية تحقق للتأكد من أن البنك هو صاحب الهوية المذكورة في CSR أو لديه الحق في تمثيلها. * إذا نجحت عملية التحقق، تصدر Model CA شهادة رقمية (Digital Certificate) للبنك. ملاحظة: البنك يطلب شهادة رقمية CA، تتحقق من الهوية، تصدر الشهادة.", | |
| "chunk_id": 93 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 14, | |
| "text": "## الفكرة الأساسية \nال PKI في العالم الحقيقي ليس CA واحد فقط، بل شبكة كبيرة من جهات مصد قة منظ مة في هيكلية هرمية. ## مستويات ال CA", | |
| "chunk_id": 94 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 14, | |
| "text": "## Root CA. 1 الجذر \n* أعلى جهة موثوقة \n* ت وق ع نفسها بنفسها (Self-Signed) \n* مفتاحها العام م دمج مسبق ا داخل: * نظام التشغيل \n* المتصفح \n* البرامج الموثوقة \n* إذا وثقت بهذه الجهة: تلقائي ا تثق بكل الجهات تحتها. ## Intermediate CA. 2 وسيطة \n* ليست موق عة ذاتي ا \n* بل موق عة من Root CA \n* وظيفتها إصدار شهادات للمواقع أو لمستويات أخرى من CAs \n* وجودها يزيد الأمان: * لو تم اختراق Intermediate CA، يمكن إلغاؤها دون المساس بال Root CA. ## لماذا هذه الهيكلية مهمة؟ لأنها تسمح ببناء سلسلة ثقة متدرجة: User Certificate ← Intermediate CA ← Root CA إذا تم التحقق من الحلقات كلها هذا يعني الشهادة موثوقة.", | |
| "chunk_id": 95 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 15, | |
| "text": "## يشرح كيفية بناء سلسلة الثقة: ## آلية السلسلة \n* شهادة الموقع مثلا: (paypal. com) يتم توقيعها من Intermediate CA \n* ال Intermediate CA نفسها تكون موق عة من Root CA \n* تأتي مع نظام التشغيل \n* أو تأتي مع المتصفح \n* أو مع برامج موثوقة جد ا \n* أو نضيفها يدوي ا إذا كنا نثق بالمصدر \nRoot CA لماذا توق ع نفسها؟ لأنه ببساطة … لا يوجد جهة أعلى منها لتوق عها. كيف نثق بها إذا كانت موق عة بنفسها؟ الثقة لا تأتي من التوقيع، بل من مصدر الحصول على الشهادة \nإذا وصلتك شهادة Root CA من جهة مجهولة لا تثق بها. :", | |
| "chunk_id": 96 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 16, | |
| "text": "* وبالتالي: * Root CA → Intermediate CA → User Certificate", | |
| "chunk_id": 97 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 16, | |
| "text": "## كيف يتم التحقق؟ * 1. المتصفح يحصل على شهادة الموقع \n* 2. يبحث عن الشهادة الموق عة التي فوقها (Intermediate) \n* 3. ثم يتحقق من توقيع Intermediate باستخدام Root \n* 4. بما أن Root CA موثوقة تصبح السلسلة كاملة موثوقة", | |
| "chunk_id": 98 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 16, | |
| "text": "## في الفقرات السابقة تعر فنا على: * مفهوم سلسلة الثقة (Chain of Trust) \n* وجود Root CA ثم Intermediate CAs ثم الخادم نفسه \n* وكيف أن كل شهادة موق عة من التي فوقها. ## هذه الفقرة تظهر خطوة مهم ة جدا: 🔍 كيف نتحق ق يدوي ا من هذه السلسلة؟ أي: كيف نثبت أن شهادة موقع معي ن صحيحة، وأنها مربوطة فعلا بجذر موثوق؟ ## : لدينا ثلاث ملفات شهادات يجب حفظها \n* Paypal. pem وهو ملف يحتوي شهادة PayPal نفسها هذه شهادة \"الخادم \" (Server Certificate) \n* Symantec-g3. pem وهي شهادة من نوع Intermediate CA اسمها: 'Symantec Class 3 EV SSL CA G3' \n* VeriSign-G5. pem وهي شهادة Root CA اسمها: VeriSign Class 3 Public Primary CA -G5", | |
| "chunk_id": 99 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 17, | |
| "text": "هذا الأمر يبني سلسلة الثقة الكاملة: PayPal → Symantec G3 → VeriSign G5 ويتحقق من صحة الشهادة. هذا هو الأمر الأساسي الذي ينجح عادة. ## الهدف من هذه العملية: ## بناء سلسلة شهادات كاملة (Certificate Chain) وتتألف من: * شهادة الخادم (PayPal) \n* Intermediate CA \n* Root CA", | |
| "chunk_id": 100 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 17, | |
| "text": "## ثم التحقق من صحتها. * لماذا نحتاج للتحق ق اليدوي؟ عادة: * المتصفح (Chrome, Firefox…) \n* نظام التشغيل (Windows, macOS…) \n* يقومون بالتحقق تلقائي ا. * لكن التحقق اليدوي مهم جدا في: * الاختبارات الأمنية \n* دروس PKI \n* تحليل شهادات م عد لة \n* فحص شهادات المواقع في حالات الشك", | |
| "chunk_id": 101 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 18, | |
| "text": "## كيف ت حبط بنية PKI هجمات MITM؟ بعد أن فهمنا كيف ت بنى سلسلة الشهادات من الجذر Root CA وصول ا إلى شهادة الموقع، ننتقل إلى توضيح كيف ت فشل هذه البنية محاولات هجوم \"الرجل في الوسط \" (MITM). : الآن سنناقش سيناريو زيارة أليس إلى موقع مثل \nhttps: //example. com / \nثم يتدخل المهاجم لاعتراض الاتصال. الهجوم لديه 3 محاولات: ## 1. المهاجم يعترض الشهادة الأصلية ويعيد تمريرها \nيقوم المهاجم Mike باعتراض اتصال Alice بالموقع example. com، ولا يزو ر شيئ ا، بل يمر ر الشهادة الأصلية الحقيقية للموقع. لكن … \nرغم أن الشهادة صحيحة، إلا أن Mike: * ❌ لا يمتلك المفتاح الخاص للخادم \n* ❌ لا يستطيع فك السر الذي ترسله Alice أثناء ال TLS Handshake \n* ❌ وبالتالي لا يستطيع فتح قناة مشف رة \n* ❌ ولا قراءة أي بيانات أو تعديلها", | |
| "chunk_id": 102 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 18, | |
| "text": "* ❌ وبالتالي لا يستطيع فتح قناة مشف رة \n* ❌ ولا قراءة أي بيانات أو تعديلها \nأقصى ما يمكن أن يفعله هو تعطيل الاتصال (DoS)، أما هجوم MITM الحقيقي فيفشل تمام ا. ## 2. المهاجم يصنع شهادة مز و رة \nيدرك Mike أن تمرير الشهادة الأصلية لا يفيده، فيحاول الآن تزوير شهادة لاسم example. com: * ينشئ شهادة جديدة ويكتب فيها أن ها تخص example. com \n* ويستبدل المفتاح العام الحقيقي بمفتاحه هو \n* ويحاول أن يجعل CA موثوقة توق ع الشهادة \nلكن هنا تحدث المشكلة: ## ال CA لن توق ع الشهادة \nلأن Mike لا يملك السيطرة على النطاق example. com. وعندما يعجز عن الحصول على توقيع جهة موثوقة، يضطر لأن يوق ع الشهادة بنفسه تصبح Self-Signed.", | |
| "chunk_id": 103 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 19, | |
| "text": "## وهنا دور المتصفح: * يبحث المتصفح عن سلسلة ثقة تؤدي إلى Root CA \n* لن يجد أي سلسلة موثوقة \n* فيعرض تحذير ا قوي ا بأن الشهادة غير موثوقة \nالهجوم يفشل ما دام المستخدم لا يتجاهل التحذير. ## 3. المهاجم يرسل شهادته الخاصة \nفي هذه المحاولة Mike لا يزو ر شهادة example. com، بل يرسل شهادته الخاصة التي يملكها أصل ا: * شهادته صحيحة ✔ \n* موق عة من CA حقيقية ✔ \n* لكنها تخص attacker. com وليس ✖ example. com \nهنا المتصفح يتحقق من: * اسم النطاق الموجود في الشهادة \n* مقابل اسم الموقع الذي تزوره Alice \nعندما يحدث عدم تطابق (Hostname Mismatch): فهنا", | |
| "chunk_id": 104 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-3.pdf", | |
| "page": 19, | |
| "text": "* مقابل اسم الموقع الذي تزوره Alice \nعندما يحدث عدم تطابق (Hostname Mismatch): فهنا \n* المتصفح ي نهي بروتوكول TLS قبل أن يبدأ الاتصال ولا يسمح بمتابعة العملية وبالتالي يفشل الهجوم بالكامل PKI تمنع المهاجم من استخدام شهادة صحيحة لكن لهوية مختلفة. * النتيجة النهائية: * PKI تمنع انتحال الهوية بشكل كامل، وت سقط كل محاولات MITM المعتمدة على تبديل المفتاح العام. * فالمفتاح الخاص غير قابل للوصول، وسلسلة الثقة تضمن أن كل شهادة مصدرها جهة موثوقة، وملكية النطاق تمنع أي شخص من الحصول على شهادة باسمك. < The End >", | |
| "chunk_id": 105 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 1, | |
| "text": "## : مقدمة \nفي هذه المحاضرة سن كث ف فهمنا لأساسيات عمل الويب من منظور أمني ثم ننتقل إلى هجوم Cross-Site Request Forgery (CSRF) وطرق الوقاية منه. الهدف أن نخرج بفهم واضح لكيفية تدف ق الطلبات بين المتصف ح والخادم، كيف تدار الجلسات (sessions) والكوكيز، لماذا قد ت ستغل هذه الآليات في ال هجمات، وكيفية تصميم تدابير دفاعية فع الة. ## فلنبدأ …", | |
| "chunk_id": 106 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 1, | |
| "text": "## : محاور المحاضرة الأساسية \n* The web architecture \n* Web server \n* HTTP protocol, cookies \n* JavaScript and sandboxing", | |
| "chunk_id": 107 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 1, | |
| "text": "## ▪ ما هي 'Web Application Architecture': بنية الويب هي الهيكل العام أو 'الخريطة' التي تحدد كيف موقع/تطبيق ال ويب ي بنى، وكيف مكوناته تتكامل، وكيف ينتقل الطلب من المستخدم إلى السيرفر ويرجع الرد \nيعني ببساطة، هي 'المخطط المعماري' الذي يوضح: الجزء الذي يتعامل معه المستخدم (Front-end)، الجزء اللي ي عمل بالسيرفر (Back-end)، قاعدة البيانات، ووسائل الاتصال بينهم \n* هدفها: تنظيم العمل بحيث الموقع/التطبيق يكون مستقر، سهل الصيانة، آمن، وقابل للتطوير (scalable). * العناصر الأساسية المكو نة لأي موقع: لغة HTML التي ت نشئ المحتوى، و CSS التي تضبط الشكل والتنسيق، واللغات الديناميكية مثل JavaScript التي تمنح الصفحة الحركة والتفاعل. يلي ذلك شرح دور خادم الويب", | |
| "chunk_id": 108 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 2, | |
| "text": "web server وخادم التطبيق (Application Server)، وكيف تتكامل هذه المكو نات لتوليد صفحات ثابتة أو محتوى ديناميكي. ## المكو نات الأساسية لصفحات الويب", | |
| "chunk_id": 109 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 3, | |
| "text": "* 💡 في الآونة الأخيرة تطور الويب من محتوى ثابت إلى محتوى ديناميكي يعتمد على المستخدم وحالته. قديما كانت ت ستخدم تقنيات مثل Flash، Silverlight، ActiveX، و Java Applets لإنشاء صفحات تفاعلية، لكن هذه التقنيات لم تعد آمنة أو مدعومة. المحتوى الديناميكي اليوم يعتمد على JavaScript بالدرجة الأساسية، وهو ما جعل الويب أكثر قوة… وأكثر عرضة للهجمات أيضا. ## 3. ثالثا JavaScript -العمود الفقري للمحتوى الديناميكي: مع تطور الويب أصبح المحتوى ديناميكيا لا ثابتا، وظهرت تقنيات قديمة مثل Flash و Silverlight و ActiveX التي أصبحت غير آمنة. اليوم ي عد JavaScript الأساس للتفاعل في صفحات الويب، إذ يمنح الصفحات القدرة على الاستجابة والتعديل أثناء العمل. ومع استخدام JavaScript تظهر مخاطر مهمة مثل هجمات XSS، لذلك تصبح إدارة مصادر الشيفرات والتحقق من المدخلات جزءا مهما من أمن الويب. : مثال", | |
| "chunk_id": 110 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 3, | |
| "text": "## 💡 لمحة عن هجمة: XSS \nهجوم XSS -Cross-Site Scripting هو أحد أشهر هجمات الويب وأكثرها خطورة، ويحدث عندما يتمك ن المهاجم من إدخال شيفرة JavaScript خبيثة داخل صفحة ويب ير اها المستخدمون. المشكلة الأساسية أن المتصفح يثق بالموقع الذي يعرض الصفحة، فإذا ظهرت الشيفرة الخبيثة داخل الصفحة، فإن المتصفح ي شغ لها كما لو أن ها جزء شرعي من الموقع. يمكن لهذه الشيفرة أن تسرق الكوكيز، أو تغي ر محتوى الصفحة، أو ترسل طلبات باسم المستخدم، أو ت عيد توجيهه لمواقع ضار ة. غالب ا تنتج هجمات XSS بسبب عدم فلترة أو تعقيم البيانات المدخلة من المستخدم قبل عرضها داخل الصفحة.", | |
| "chunk_id": 111 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 4, | |
| "text": "إذا اردت يمكنك ان تمسح ال QR جانبا للحصول على معلومات أكثر حول هذه الهجمة. ## Web Server", | |
| "chunk_id": 112 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 5, | |
| "text": "## بروتوكول HTTP -الطلب والاستجابة \nفي هذا الجزء سن شرح كيف المتصفح يرسل طلب (Request) إلى خادم الويب، وما هي البنية الأساسية للطلب. مكو نات طلب HTTP: عندما يزور المستخدم أي موقع، المتصفح يرسل للخادم طلب يشبه التالي: * 1. سطر الطلب Request Line يحدد: * نوع الطلب (GET -POST -…) \n* الملف أو المسار المطلوب \n* نسخة بروتوكول HTTP \n* 2. الرؤوس (Headers) معلومات إضافية يقول فيها المتصفح \"هي التفاصيل اللي تحتاج أن تعلمها لترد \". * 3. لا يوجد جسم (Body) في GET. أما عن الاستجابة (Response) التي يعيدها الخادم للمتصفح: تكون كالتالي", | |
| "chunk_id": 113 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 6, | |
| "text": "* 1. سطر الحالة Status Line يحتوي: * نسخة HTTP \n* رمز الحالة (200 -404 -500…) \n* الرسالة (OK -Not Found -Internal Server Error) \n* 2. Headers يحدد: * نوع المحتوى \n* طوله \n* الكوكيز (إن كان يريد ضبطها) \n* معلومات التخزين المؤقت (Cache-Control) \n* 3. Body وهو محتوى الصفحة نفسها (صورة Json- html-)", | |
| "chunk_id": 114 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 6, | |
| "text": "## GET vs POST الفرق بينهما: * : GET \n* يرسل البيانات داخل URL \n* مناسب للعمليات غير الحس اسة \n* سهل التخزين والنسخ \n* المتصف ح والمخد مات الوسيطة يمكن أن تحفظه (Cache) \n* آمن أكثر من ناحية الخصوصية (ولكن ليس تشفير ا ) \n▪: POST ▪ يرسل البيانات داخل Body ▪ مناسب لإرسال كلمات مرور، نماذج تسجيل، بيانات طويلة ▪ لا يظهر في URL ▪", | |
| "chunk_id": 115 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 7, | |
| "text": "Cookies تعريفها ودورها: * لماذا نحتاج الكوكيز؟ * بروتوكول HTTP هو بروتوكول بلا ذاكرة (stateless)، يعني: كل طلب نرسله للسيرفر ي عتبر مستقل تمام ا عن أي طلب سابق. مثال بسيط: نفتح صفحة home بعدها نضغط على profile \" السيرفر لا يعرف\" إنك نفس الشخص إلا إذا وجد شيء يربط الطلبي ن ببعضهما. هنا تأتي فكرة الكوكيز: نستخدم الكوكيز كطريقة لتخزين معلومات صغيرة عند المستخدم، حتى يرسلها المتصفح تلقائي ا مع كل طلب جديد للموقع. حيث يرسل المتصفح تلقائيا أي كوكي تخص الموقع الهدف، وهذه طريقة عمل الجلسات. لكن الكوكيز قد تشكل خطرا إذا لم ت حمى جيدا. أهم السمات الأمنية للكوكيز: HttpOnly: تمنع JavaScript من قراءتها Secure: ت رسل فقط عبر HTTPS SameSite: تمنع إرسالها مع الطلبات الخارجية الكوكي = \"بطاقة تعريف صغيرة\" يخز نها المتصفح ويرسلها لكل طلب لنفس الموقع. ## كيف ت نشأ الكوكيز؟ (Set-Cookie Header) \nSet-Cookie", | |
| "chunk_id": 116 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 7, | |
| "text": "Set-Cookie \nالسيرفر يضيف في ال HTTP response رأس خاص اسمه المتصفح يستقبل هذا الرأس ويخزن الكوكي. يكون ال HTTP Response: كالتالي", | |
| "chunk_id": 117 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 8, | |
| "text": "## كيف المتصفح يرفق الكوكيز: في كل مرة يرسل المتصفح طلب ا لنفس الموقع الذي أنشأ الكوكي، يقوم تلقائي ا بإرسال الكوكي ضمن رأس ولكن هذا السلوك يمكن استغلاله في هجمات مثل CSRF إذا لم ت ضبط السياسات جيدا. المستخدم لا يفعل أي شيء، المتصفح يعمل هذا بشكل تلقائي. ## النقطة الأمنية: هذا السلوك هو السبب الرئيسي لهجوم CSRF لاحق ا، لأن المتصفح ير سل الكوكي دائم ا طالما الطلب ذاهب لنفس الموقع. ## كيف يمكن استخدام الكوكيز لتتب ع المستخدمين: بعض المواقع أو شبكات الإعلانات تستخدم الكوكيز كطريقة لمعرفة: * الصفحات التي تزورها \n* اهتماماتك \n* وقت نشاطك \n* المواقع التي تنتقل لها \n* هذه ت سم ى Third-party cookies لأن ها ت نشأ من طرف خارجي غير الموقع الأساسي. * استخدامها غالب ا للإعلانات والتحليل الإحصائي وليس لتسهيل الاستخدام مثل كوكي الجلسة.", | |
| "chunk_id": 118 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 9, | |
| "text": ". ## طرق بسيطة لتقليل التتبع: * استخدام وضع التصفح الخفي (Private / Incognito) \n* حظر الكوكيز من الطرف الثالث (Third-party cookies)", | |
| "chunk_id": 119 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 9, | |
| "text": "## ملاحظة: First-party cookies أساسية لعمل الموقع (مثل تسجيل الدخول) \nThird-party cookies هي للمتابعة والإعلانات", | |
| "chunk_id": 120 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 9, | |
| "text": "## النقطة الأساسية: تقليل التتبع لا يعني إيقاف كوكيز الجلسة الضرورية للموقع، بل إيقاف الكوكيز التي تأتي من أطراف أخرى. ## Session Cookies \nي عد Session ID أهم أنواع الكوكيز، فهو المعرف الذي يحدد هوية المستخدم عند الخادم وفي حال حصول المهاجم عليه يمكنه انتحال شخصية المستخدم. لذلك يجب أن يكون هذا النوع من الكوكيز: * محمي بالسمات الأمنية \n* قصير العمر \n* ي عاد توليده بعد العمليات الحساسة كالتسجيل وتغيير البيانات \n* بعد تسجيل دخول المستخدم. ## : ملخص لما تحدثنا به سابقا \nأساسيات الويب -من HTML و CSS و JavaScript إلى HTTP والكوكيز -ليست مجرد أدوات لإنشاء المواقع، بل مكونات أمنية حساسة. وأي خلل في إدارة هذه الجوانب يمكن أن يتحول إلى ثغرة خطيرة تمه د لهجمات مثل CSRF وغير ها التي ست شرح لاحقا. ## الطلبات عبر المواقع ومشكلاتها", | |
| "chunk_id": 121 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 9, | |
| "text": "* 1. عندما ترسل صفحة من موقع إلكتروني طلب HTTP عائد ا إلى نفس الموقع، ي سم ى ذلك طلب ا من نفس الموقع (same-site request). وإذا أ رسل الطلب إلى موقع مختلف، ي سم ى طلب ا عبر المواقع (cross-site request) لأن مصدر الصفحة \nوالوجهة مختلفان. مثال: صفحة ويب (ليست فيسبوك) يمكنها تضمين رابط لفيسبوك، ولذلك عند نقر المستخدم على الرابط، ي رسل المتصفح طلب HTTP إلى فيسبوك.", | |
| "chunk_id": 122 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 10, | |
| "text": "* 2. عندما ي رسل طلب إلى example. com من صفحة قادمة من example. com، يقوم المتصفح بإرفاق كل ملفات تعريف الارتباط (cookies) الخاصة ب example. com. وعندما ي رسل طلب إلى example. com من موقع آخر ( مختلف عن example. com)، سي رفق المتصفح الكوكيز نفسها أيض ا. وبسبب هذا السلوك، لا يستطيع الخادم التمييز بين الطلبات القادمة من نفس الموقع وتلك القادمة من موقع آخر. * يمكن لمواقع الطرف الثالث تزوير طلبات تبدو مطابقة للطلبات الطبيعية. وي سم ى هذا تزوير طلبات المواقع المتقاطعة (CSRF). ## Cross Site Request Forgery (CSRF) \n* CSRF هو نوع من الهجمات على تطبيقات الويب: المتصفح بدل ان يكون مجرد وسيط، ي ستغل ليرسل طلبات غير مرغوب فيها على أن ها طلبات صحيحة إلى الموقع الذي المستخدم مسج ل دخول فيه", | |
| "chunk_id": 123 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 10, | |
| "text": "* السبب أن المتصفح يبعث الكوكيز مثل session cookie تلقائي ا مع الطلبات → الموقع يظن إن الطلب من المستخدم الحقيقي \n* \" يعني حتى إذا الضحية ما ضغطت على أي زر \"تأكيد يكفي إنها تفتح صفحة خبيثة بينما هي مسج لة دخول على الموقع الشرعي", | |
| "chunk_id": 124 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 10, | |
| "text": "* بمعنى أبسط: CSRF هجوم ي جبر متصف ع الضحية على إرسال طلبات م صادقة إلى موقع موثوق أثناء تواجده على صفحة خبيثة. * 💡 فيديو ممتاز وواقعي يشرح كيف يعمل CSRF، أمثلة عملية، وكيف ت منع هجوم CSRF. ## كيف يعمل هجوم CSRF: * المستخدم (أنت مثلا ) يكون مسج ل دخول في موقع (بنك، حساب شخصي، … ) و المتصفح ي خز ن session cookie. * المهاجم ي نشئ صفحة أو رابط خبيث يحوي طلب GET أو POST يستهدف الموقع (مثلا 'نقل مبلغ' أو 'تغيير )' إعدادات. * المستخدم يزور الصفحة الخبيثة. * المتصفح يرسل الطلب إلى الموقع الشرعي + الكوكيز تلقائي ا. * الموقع يظن الطلب حقيقي لأن الكوكيز صحيحة فينف ذ العملية كأن المستخدم نف ذها.", | |
| "chunk_id": 125 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 11, | |
| "text": "النتيجة: إجراء مهم (تحويل مال، تعديل كلمات مرور، حذف بيانات، …) يتم باسم الضحية وبدون موافقتها", | |
| "chunk_id": 126 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 11, | |
| "text": "## لكي ينجح الهجوم يحتاج المهاجم إلى: * موقع الهدف \n* مستخدم ضحية لديه جلسة فع الة على موقع الهدف \n* موقع خبيث يتحكم به المهاجم", | |
| "chunk_id": 127 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 12, | |
| "text": "طلبات HTTP POST: توضع البيانات foo و bar في جسم الطلب. والهجمة ت نف ذ بطريقة مختلفة حسب نوع الطلب، لذلك سنبدأ الشرح أول ا بآلية تنفيذ الهجمات على GET ثم ينتقل لاحق ا إلى POST. : مثال تطبيق مصرفي على الإنترنت www. bank32. com يسمح للمستخدمين بتحويل المال. مستخدم مسج ل الدخول ويملك cookie لجلسة تحدده بشكل فريد. طلب تحويل 500 دولار: http: //www. bank32. com/transfer. php?to=3220&amount=500 لشن الهجوم، يجب على المهاجم إرسال طلب مزيف من جهاز الضحية بحيث يرفق المتصفح كوكيز جلسة الضحية. يمكن للمهاجم تضمين كود JavaScript في الصفحة الخبيثة لإطلاق الطلب. كما يمكن لعلامات HTML مثل img و iframe إطلاق طلبات GET باستخدام السمة src. ## Attack on Elgg's Add -Friend Service", | |
| "chunk_id": 128 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 12, | |
| "text": "## في هذا المثال يتم تطبيق الهجوم على منصة Elgg: * الهدف: Samy (المهاجم) يريد إضافة نفسه صديق ا ل Alice (الضحية) دون موافقتها. * خطوات المهاجم: سامي \n* ينشئ حساب ا باسم Charlie. * من حساب Charlie، يقوم Samy بالضغط على زر \"Add Friend\" لإضافة نفسه. * يستخدم أداة مثل LiveHTTPHeaders لمراقبة طلب إضافة صديق ومعرفة شكله. * يلاحظ أن الطلب يحتوي على:", | |
| "chunk_id": 129 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 13, | |
| "text": "* ① عنوان URL لطلب إضافة صديق. م عر ف المستخدم المراد إضافته (GUID). هنا رقم سامي هو 42. * ② عدم وجود حماية CSRF ( أدوات Elgg المضادة ل CSRF معط لة. ) \n* ③ Cookie الجلسة، يرسله المتصفح تلقائي ا. * كل هذا يعط ي المهاجم فكرة عن شكل الطلب المطلوب لتزويره. ## إنشاء الصفحة الخبيثة (Create the malicious web page) \nالفكرة الأساسية هي أن المهاجم يريد إجبار المتصفح على إرسال طلب إلى موقع الضحية من دون أن ينتبه المستخدم. ولتنفيذ هجوم CSRF في حالة 'إضافة صديق'، يقوم المهاجم بثلاث خطوات بسيطة: * استخدام رابط إضافة الصديق الحقيقي", | |
| "chunk_id": 130 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 13, | |
| "text": "المهاجم يلتقط من المتصفح عبر أدوات مثل LiveHTTPHeaders الرابط الذي يضيف شخص ا لقائمة الأصدقاء. هذا الرابط يكون مثل: http: //www. csrflabelgg. com/action/friends/add?friend=42 حيث الرقم 42 هو رقم حساب المهاجم نفسه. عندما يتم فتح هذا الرابط، الموقع سيضيف المهاجم للقائمة فور ا -طالما أن الضحية مسج ل الدخول. ▪ وضع الرابط داخل صورة صغيرة جد ا المهاجم ينشئ وسم <img> ويضع داخل ال src رابط إضافة الصديق، مثل: < img src=\"http: //www. csrflabelgg. com/action/friends/add?friend=42\" width=\"1\" height=\"1 >\" لماذا صورة؟ * الصورة تجعل المتصفح يرسل طلب GET تلقائي ا. * حجمها صغير جد ا، 1×1 بكسل، فلا يلاحظها الضحية. * لا يحتاج المستخدم لنقر أي شيء مجرد فتح الصفحة كاف. * ▪ \nالمستخدم (Alice) لا ترى شيئ ا، ولكن المتصفح يرسل الطلب نيابة عنها، ومعه كوكي الجلسة التي تثبت هويتها.", | |
| "chunk_id": 131 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 14, | |
| "text": "* وضع الصفحة الخبيثة في موقع المهاجم \nالمهاجم يرفع الصفحة إلى موقعه الخبيث حتى ينجح الهجوم، يجب أن تزور الضحية الصفحة الخبيثة. * مثل ا: Samy يرسل رسالة خاصة إلى Alice تحتوي رابط ا بسيط ا. ## http: //www. csrflabattacker. com/ \nوفور دخول الضحية إلى هذه الصفحة: * المتصفح يقرأ ال <img> \n* فيرسل تلقائي ا طلب GET \n* ومعه كوكيز الضحية الأصلية \n* فيتم تنفيذ الأمر وكأن الضحية نفسه قام به", | |
| "chunk_id": 132 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 14, | |
| "text": "* ومعه كوكيز الضحية الأصلية \n* فيتم تنفيذ الأمر وكأن الضحية نفسه قام به \n* وهكذا تم ت عملية CSRF بنجاح دون علم الضحية. ## النتيجة: المهاجم ي ضاف إلى قائمة أصدقاء الضحية دون أي موافقة. ## لماذا يحدث هذا؟ لأن المتصفح يرسل الكوكيز دائم ا لموقعها الأصلي، سواء جاء الطلب من صفحة موقع آخر أو من صفحة الضحية. بالتالي: الطلب يبدو 'شرعي ا' بالنسبة للخادم. الخادم لا يستطيع التمييز بين طلب حقيقي من الضحية وطلب مزور صادر من صفحة المهاجم. الخلاصة المبسطة: المهاجم: يحصل على رابط العملية الحقيقية (إضافة صديق). يخفيه داخل صور ة صغير ة تر سل الطلب تلقائي ا. يجذب الضحية لزيارة الصفحة الخبيثة. المتصفح يقوم بالباقي تلقائي ا، وبذلك يحدث هجوم \nCSRF.", | |
| "chunk_id": 133 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 15, | |
| "text": "* الآن ننتقل لقسم هجمات POST. . . ## CSRF Attacks on HTTP POST Services \nPOST لا يتم تشغيله تلقائي ا بعناصر مثل الصور \nلذلك يلجأ المهاجم إلى إنشاء form مخفي في الصفحة، ويستخدم JavaScript لإرسال النموذج تلقائي ا. . * يمكن إنشاء طلبات POST باستخدام النماذج في HTML. * عند نقر المستخدم زر \"Submit\"، ي رسل الطلب الى عنوان URL المحدد في حقل الاجراء مع تضمين حقلي \" to \" و المبلغ في النص \n* عمل المهاجم هو جعل الزر \"ي ضغط تلقائي ا\" دون المستخدم. * مثال على جافاسكريبت يقوم بإنشاء النموذج وإرساله مباشرة: ## : الخطوات \n* إنشاء form جديد وتحديد method = POST \n* إضافة حقول input من النوع hidden \n* إضافة النموذج لصفحة HTML \n* تنفيذ form. submit() تلقائي ا عند التحميل \nالمستخدم لا يرى شيئ ا، لكن المتصفح يرسل POST باسم الضحية. ## Attack on Elgg's Edit -Profile Service", | |
| "chunk_id": 134 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 16, | |
| "text": "* Session Cookie \n* الحقول الخاصة بالوصف \nهذا كل ما يحتاجه المهاجم لمعرفة شكل الطلب المطلوب تزويره. : يكون الطلب كالتالي", | |
| "chunk_id": 135 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 16, | |
| "text": "## : شرح عناصر الطلب \n* السطر (1): URL خدمة تعديل الملف \n* السطر (2): Cookie Session الخاصة بالضحية \n* ( السطر 3 ): حقل CSRF Token ( م عط ل في بيئة التدريب ) \n* ( السطر 4 ): حقل الوصف، وفيه القيمة التي يريد Samy إضافتها \"SAMY is MY HERO\" \n* ( السطر 5 ): مستوى الصلاحية Access level \n* ( السطر 6 ): معرف الضحية GUID=39 \n* توضيح إضافي لآلية تعديل بيانات مستخدم عبر طلب م ز و ر:", | |
| "chunk_id": 136 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 17, | |
| "text": "يقوم Samy بكتابة صفحة HTML تحتوي: * form مخفي \n* حقول مخفية فيها البيانات المطلوبة ( الوصف - ال GUID -مستوى الصلاحية … ) \n* JavaScript يقوم بإرسال form تلقائي ا \nعندما تزور Alice الصفحة يتم إرسال POST إلى: http: //www. csrflabelgg. com/action/profile/edit ويتم تعديل ملفها دون علمها. ## الأسباب الأساسية ل CSRF \n* لا يستطيع الخادم التمييز ما إذا كان الطلب عبر موقع آخر أو من نفس الموقع. * . طلب من نفس الموقع: قادم من صفحة الخادم نفسه موثوق. * . طلب عبر موقع آخر: قادم من صفحات موقع مختلف غير موثوق. * لا يمكننا التعامل مع هذين النوعين من الطلبات بالطريقة نفسها. * هل يعرف المتصفح الفرق؟ بالتأكيد. المتصفح يعرف من أي صفحة تم إنشاء الطلب. * هل يمكن للمتصفح المساعدة؟ كيف يساعد الخادم؟ * ترويسة Referrer ( مساعدة من المتصفح) \n* كوكيز Same Site ( مساعدة من المتصفح)", | |
| "chunk_id": 137 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 17, | |
| "text": "* كوكيز Same Site ( مساعدة من المتصفح) \n* الرمز السري Secret token (الخادم يساعد نفسه للدفاع ضد CSRF )", | |
| "chunk_id": 138 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 17, | |
| "text": "## كيف نوقف CSRF؟ (وسائل الحماية) \n* التحقق من (Referer Header) \n* المتصفح قد يرسل Header يسمى Referer يدل على الصفحة التي جاء منها الطلب. يمكن للخادم فحصه لتمييز الطلبات المشروعة من المزيفة. * لكن المشكلة: * بعض المتصفحات تخفي ال Referrer \n* بعض الشبكات أو الإضافات تحذفه \n* فيه مخاوف خصوصية", | |
| "chunk_id": 139 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 17, | |
| "text": "## لذلك الاعتماد عليه وحده غير موثوق. * خاصية SameSite Cookie \n* Cookies خاص في المتصفحات مثل Chrome و Opera، وهو يوف ر خاصية خاصة لملفات الارتباط ت سم ى SameSite. يتم تعيين هذه الخاصية من ق بل الخوادم، وهي تخبر المتصفح ما إذا كان يجب إرفاق Cookie مع طلب عبر موقع آخر أم لا.", | |
| "chunk_id": 140 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 18, | |
| "text": "Cookies التي تحتوي على هذه الخاصية ت رسل دائم ا مع الطلبات من نفس الموقع، أم ا إر سالها مع الطلبات عبر المواقع فيعتمد على قيمة هذه الخاصية. ## القيم: * Strict: لا ت رسل مع الطلبات عبر المواقع. * Lax: ت رسل مع الطلبات عبر المواقع. * Secret Token ▪ يقوم الخادم بتضمين قيمة سرية عشوائية داخل كل صفحة من صفحات الويب. عندما يتم إنشاء طلب من هذه الصفحة، ت رفق القيمة السرية مع الطلب. يتحقق الخادم من هذه القيمة لمعرفة ما إذا كان الطلب عبر موقع آخر أم لا. الصفحات من أصل مختلف لن تستطيع الوصول إلى القيمة السرية، وهذا مضمون من المتصفحات (سياسة نفس الأصل). ي ول د السر بشكل عشوائي ويختلف من مستخدم لآخر، ولذلك لا توجد طريقة للمهاجم لمعرفة هذا السر أو تخمينه. ▪ إجر اء Elgg الوقائي ▪ يستخدم Elgg أسلوب الرمز السري: _elgg_tc و _elgg_token ▪ ت خز ن هذه القيم داخل متغيرين في JavaScript، وكذلك في جميع النماذج", | |
| "chunk_id": 141 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 18, | |
| "text": "السري: _elgg_tc و _elgg_token ▪ ت خز ن هذه القيم داخل متغيرين في JavaScript، وكذلك في جميع النماذج التي تتطلب إجر اء من المستخدم. ت ضاف المعلمان المخفيان إلى النموذج بحيث عند إرسال النموذج عبر طلب HTTP، ت رسل هاتان القيمتان مع الطلب. هذه القيمتان المخفيتان يتم توليدهما من ق بل الخادم وإضافتهما كحقول مخفية داخل كل صفحة. * ت خز ن القيم في متغيرات JavaScript وفي الحقول المخفية للنماذج. ▪ رمز الأمان في Elgg هو ناتج تجزئة MD5 لأربعة عناصر: ▪ السر الخاص بالموقع ▪ الطابع الزمني ▪ معر ف جلسة المستخدم ▪", | |
| "chunk_id": 142 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 19, | |
| "text": "هجمات CSRF تمثل خطر حقيقي لأن الموقع يثق بالكوكيز التي ي ر فقها المتصفح، وإذا لم ت نف ذ تدابير حماية (Tokens, SameSite, التحقق من المصدر …) يمكن للمهاجم تنفيذ أفعال نيابة عن المستخدم دون إذن. في نهاية المحاضرة أصدقائي وجدنا أن فهم أساسيات عمل الويب هو الخطوة الأولى لحماية أي تطبيق، فطريقة بناء الصفحات، وكيفية إرسال الطلبات، وآلية عمل الكوكيز كلها عناصر تؤثر مباشرة في مستوى الأمان. ومن خلال ذلك أصبح من السهل إدراك خطورة هجوم CSRF، الذي يستغل ثقة الخادم في المتصفح لإجبار المستخدم على تنفيذ عمليات لم يقم بها فعلي ا. ورأينا كيف يمكن أن يظهر الهجوم ببساطة عبر طلب GET أو من خلال نموذج POST م ر س ل تلقائي ا، مما يجعل وجود آليات حماية مثل الرموز السرية وخصائص SameSite أمر ا ضر ور ي ا. وبذلك تؤكد المحاضرة أن الأمان في الويب ليس ميزة إضافية، بل جزء أساسي من تصميم أي نظام يعتمد على تفاعل المستخدمين.", | |
| "chunk_id": 143 | |
| }, | |
| { | |
| "source": "parctical-data-security-lec-4.pdf", | |
| "page": 19, | |
| "text": "أن الأمان في الويب ليس ميزة إضافية، بل جزء أساسي من تصميم أي نظام يعتمد على تفاعل المستخدمين. See you soon", | |
| "chunk_id": 144 | |
| } | |
| ] |