important links | روابط مُهمة

link 1: OPSEC Digital Shadow
link 2: How to Improve OPSEC
link 3: The Ultimate OPSEC Guide To Stay Secure Online beginner
link 4: OPSEC Guide
link 5: Most comprehensive free OPSEC guide

CH : @SparkSecurity

📢 فقرة اخبار سيبرانية

عملية بقيادة الإنتربول أسفرت عن القبض على 1,006 شخص عبر 19 دولة إفريقية وتفكيك 134,089 بنية تحتية وشبكة خبيثة كجزء من جهود منسقة لمكافحة الجرائم الإلكترونية في القارة.

العملية اللي أطلق عليها اسم "سيرينغيتي" استمرت من 2 سبتمبر لغاية 31 أكتوبر 2024، واستهدفت المجرمين المتورطين في هجمات الفدية، واختراق البريد الإلكتروني التجاري (BEC)، والابتزاز الرقمي، والاحتيالات الإلكترونية.

الدول المشاركة في العملية هي: الجزائر، أنغولا، بنين، الكاميرون، ساحل العاج، جمهورية الكونغو الديمقراطية، الغابون، غانا، كينيا، موريشيوس، موزمبيق، نيجيريا، رواندا، السنغال، جنوب أفريقيا، تنزانيا، تونس، زامبيا، وزيمبابوي.

النشاطات الإجرامية اللي تم استهدافها شملت احتيالات بطاقات الائتمان عبر الإنترنت، وعمليات بونزي، ونظم الاستثمار والاحتيال متعدد المستويات، اللي أضرت بأكثر من 35,000 شخص وسببت خسائر مالية تقدر بـ 193 مليون دولار حول العالم.


#الامن_السيبراني #هجوم_سيبراني #news
CH : @SparkSecurity

🛡 تحليل شامل للدفاعات الإلكترونية ضد الهجمات الحديثة (One-Day Exploits)

من أكثر التحديات الي تواجه المؤسسات والشركات اليوم هي الهجمات السيبرانية الحديثة، خاصة الهجمات الي تستهدف الثغرات المكتشفة حديثًا قبل إصدار التحديثات الأمنية، والي تعرف بـ One-Day Attacks. هاي الهجمات تعتمد على سرعة تنفيذها قبل ما تكون الأنظمة مستعدة بشكل كامل.

🔍 دراسة جديدة بعنوان "Defects-in-Depth" تكشف أهم التحديات والنواقص في الدفاعات الإلكترونية الحالية، مع تقديم حلول عملية لتحسين الحماية وتعزيز الأمان.

🎯 النقاط الأساسية الي تطرقت الها الدراسة

1️⃣ شنو هاي الهجمات؟

الهجمات تستغل نقاط الضعف المكتشفة حديثًا بشكل سريع قبل إصدار التحديثات.
تعتمد على سرعة التنفيذ وصعوبة كشفها بالأدوات التقليدية

2️⃣ أبرز المشاكل الدفاعية الي نعاني منها

تأخير بتطبيق التحديثات الأمنية.
نقص التعاون بين فرق الـ IT وفريق الأمن السيبراني.
الأدوات التقليدية مو كافية لمواكبة سرعة تطور هجمات الـ One-Day.

3️⃣ شنو الحلول المقترحة؟

تحليل ديناميكي: بدل ما نعتمد على توقيع الهجمات فقط، نحتاج نحلل سلوك التهديدات.
التعاون والمشاركة: مشاركة المعلومات الأمنية بين الشركات يقلل الوقت اللازم للكشف عن الهجمات.
تحديث السياسات الأمنية: التركيز على الوقاية وإدارة المخاطر بدل انتظار وقوع المشكلة.

4️⃣ أهمية الذكاء الاصطناعي

الذكاء الاصطناعي صار جزء أساسي بالكشف المبكر عن الهجمات وتحليل البيانات بشكل أسرع.
التعلّم الآلي (Machine Learning) يساعدنا بتوقع الهجمات المستقبلية بناءً على الأنماط السابقة.

📊 إحصائيات مهمة

أكثر من 50% من الهجمات تصير خلال الساعات الأولى من اكتشاف الثغرة.
الزمن اللازم لتطبيق التحديثات الأمنية يحتاج ينخفض إلى أقل من 24 ساعة.
تدريب الكوادر الأمنية صار ضرورة حتمية حتى نكون مستعدين لأي تهديد.


حتى تحمي بياناتك وأنظمتك، لازم تخلّي الأمن السيبراني من أولوياتك. استثمر بالأدوات الحديثة، ركّز على تدريب فريقك، وكن مستعد دائمًا للأسوأ.

CH : @SparkSecurity

Defects-in-Depth: Analyzing the Integrationof Effective Defenses against One-Day Exploits in Android Kernels

https://github.com/IAIK/DefectsInDepth

CH : @SparkSecurity

🚨 ثغرات خطيرة تهدد نظام Jenkins وأمانه

تم الكشف عن مجموعة من الثغرات الأمنية التي قد تعرّض نظام Jenkins للخطر، مما يتيح للمهاجمين تنفيذ هجمات حجب الخدمة (DoS) وحقن الأكواد (XSS) واستغلال النظام بطرق متعددة
🛡 الثغرات المكتشفة بالتفصيل:

1️⃣ ثغرة حجب الخدمة (DoS) في مكتبة JSON
CVE-2024-47855


تؤثر هاي الثغرة على مكتبة org.kohsuke.stapler:json-lib
المستخدمة في معالجة JSON في نظام Jenkins هاي المشكلة موجودة ب إصدارات Jenkins LTS 2.479.1 وما قبلها، وأيضًا في الإصدارات الأسبوعية حتى 2.486 وما قبلها
يمكن للمهاجمين استغلال هذه الثغرة لاحتكار موارد النظام، مما يؤدي إلى تعطل الخدمة وإيقاف العمليات الشرعية الخطورة تزداد لأن بعض الإضافات مثل SonarQube Scanner وBitbucket
تسمح باستغلال هاي الثغرة حتى بدون صلاحيات كبيرة

تم تصحيح المشكلة في مكتبة JSON بالإصدار 2.4-jenkins-8، وتم تضمين الإصلاح في Jenkins LTS 2.479.2 والإصدار الأسبوعي 2.487.

2️⃣ ثغرة حقن الأكواد (XSS) في إضافة Simple Queue
CVE-2024-54003

الإصدارات 1.4.4 وما قبلها من إضافة Simple Queue Plugin تعاني من مشكلة عدم معالجة أسماء العرض بشكل آمن، مما يسمح للمهاجمين بتنفيذ أكواد ضارة إذا كانت لديهم صلاحية View/Create
تم حل المشكلة في الإصدار 1.4.5 من الإضافة من خلال تأمين أسماء العرض ومنع استغلال هذه الثغرة.


3️⃣ ثغرة Path Traversal في إضافة Filesystem List Parameter
CVE-2024-54004

تسمح هذه الثغرة في الإصدارات 0.0.14 وما قبلها للمهاجمين الذين لديهم صلاحية Item/Configure بتصفح الملفات على نظام Jenkins والوصول إلى بيانات غير مصرّح بها تم تصحيح المشكلة في الإصدار 0.0.15 من الإضافة، حيث أصبحت المسارات المسموح بها محصورة فقط ضمن $JENKINS_HOME/userContent/.


📌 الإصدارات المتأثرة والإصلاحات المتوفرة
Jenkins الأسبوعي حتى الإصدار 2.486.
Jenkins LTS حتى الإصدار 2.479.1.
Filesystem List Parameter Plugin حتى الإصدار 0.0.14.
Simple Queue Plugin حتى الإصدار 1.4.4.


شنو اللي تسوي حالياً ؟


تحديث نظام Jenkins إلى الإصدار الأسبوعي 2.487 أو إصدار LTS 2.479.2 ، تحديث الإضافات المتأثرة إلى أحدث الإصدارات المتاحة.

⚠️ ليش لازم تحدث ؟

عدم التحديث يعرض نظامك لخطر كبير، مما قد يؤدي إلى تعطيل العمليات أو استغلال النظام لسرقة البيانات.

📢 رسالة مهمة

تحديث الأنظمة بشكل دوري هو أفضل وسيلة للحفاظ على الأمان والاستقرار تأكد من مراقبة التحديثات الأمنية بشكل دائم لحماية نظامك من أي تهديد محتمل حتى تحمي بياناتك وأنظمتك، لازم تخلّي الأمن السيبراني من أولوياتك. استثمر بالأدوات الحديثة، ركّز على تدريب فريقك، وكن مستعد دائمًا للأسوأ.


CH : @SparkSecurity

💡 تنويه للمشتركين

هذا المنشور مخصص للأشخاص اللي يشتغلون أو يتعاملون مع نظام Jenkins ضمن بيئات عملهم. إذا كنت من المهتمين أو تعمل بهذا النظام، فتأكد من قراءة المنشور بعناية وتطبيق التحديثات المذكورة للحفاظ على أمان نظامك. 🛡

وإذا كنت مبتدئ أو ما عندك فكرة عن Jenkins، فهذا النظام يُستخدم لإدارة عمليات التطوير البرمجي (CI/CD)، والموضوع هنا يتعلق بتأمينه ضد الثغرات. 🚀

CH : @SparkSecurity

شنو هو Jenkins؟ 🤔

إذا انت مبرمج أو مختبر ثغرات وتحب تسوي شغلك بأسرع طريقة وأكثر ترتيب، اسم Jenkins لازم يكون ببالك! Jenkins هو أداة مفتوحة المصدر تركز على الـ CI/CD
يعني التكامل المستمر (Continuous Integration) والتوصيل المستمر (Continuous Delivery)
ببساطة، إذا عندك مشروع برمجي كبير أو حتى صغير، Jenkins يساعدك تسوي كل شي أوتوماتيكي، من بناء الكود (Build)، إلى اختباره، إلى نشره (Deploy).

---

ليش يفيد المبرمجين؟ 👨‍💻

1. سهولة الأتمتة (Automation)
كل الخطوات اللي تعيدها كل مرة؟ Jenkins يشتغلها بدالك! مجرد تكتب سكربت بسيط أو تستخدم واجهته، وهو راح يشتغل.

2. دعم أغلب لغات البرمجة
سواء تشتغل على Python، Java، C# أو حتى Go، Jenkins يدعمها كلها! 🛠

3. تقليل الأخطاء البشرية
ماكو مجال للغلط أو النسيان، لأن Jenkins يتابع كل خطوة ويسجل كل شي.

4. بيئة متكاملة للاختبار
تكدر تسوي بيئة كاملة لتجربة الكود الخاص بك، حتى إذا كانت تحتاج عدة سيرفرات أو قواعد بيانات، ويضمنلك استقرار العمل.

---

شنو يفيد مختبري الثغرات؟ 🕵️‍♂️

1. تحليل الأمان
إذا تريد تختبر ثغرات ببيئة مشابهة للإنتاج (Production)، تكدر تسوي بيئة محاكية وتبدأ تبحث عن نقاط الضعف بالـ Pipeline.

2. فحص مستمر (Automated Security Testing)
جرب إضافة أدوات الفحص التلقائي مثل OWASP ZAP أو SonarQube ضمن Jenkins. بمجرد تحديث الكود، راح يبدأ الفحص بشكل مباشر.

3. تعقب التغييرات (Change Tracking)
تكدر تراقب أي تغييرات بالكود أو النظام مباشرة، وإذا صارت مشكلة، تكدر تعرف شنو اللي تغيّر بدقة.

- إذا جديد على Jenkins، جرّب تشوف الواجهة البسيطة مالتها وتبدأ تضيف Jobs خطوة بخطوة.
- خلي الـ Backup دائماً شغال، لأن الإعدادات مالتك مهمة وما تريد تخسرها.
- استخدم Plugins تضيف ميزات أكثر حسب احتياجك (أكو آلاف!).


CH : @SparkSecurity

CPDR .. راح نحجي عنه قريباً

شنو يعني CPDR؟

📌 CPDR اختصار لـ Cross-Party Delegated Resources
يعني موارد يتم مشاركتها بين أطراف مختلفة داخل التطبيقات أو بين التطبيقات
فكرة هذا المصطلح ترتبط بالتطبيقات اللي تستخدم موارد مشتركة بين أطراف متعاونة
مثل التطبيقات الفرعية أو الأنظمة اللي تعتمد على بعضها البعض لتقديم خدماتها

وين ممكن يكون موجود CPDR؟

مثال واضح على الـ CPDR هو التطبيقات اللي تسمح بوجود Mini-Apps داخلها، مثل


TikTok , Facebook وغيرها هواي منصات عديدة حتى التيليكرام بس هذا فقط مثال ، يربط المستخدمين بخدمات تجارية أو إعلانية

هاي التطبيقات تستغل موارد متشاركة مثل قنوات الاتصال بين التطبيق الأساسي والتطبيق الفرعي
البيانات اللي يتم تبادلها مثل تسجيل الدخول أو بيانات المستخدم
الصلاحيات الممنوحة لكل طرف، مثل الوصول للكاميرا أو الموقع

ليش الـ CPDR خطير؟ ⚠️

لأن هالأنظمة إذا ما كان بيها سيطرة صارمة، تصير أهداف سهلة للهجمات الإلكترونية مثل Data Exploitation ، Hijacking Channels ، Masquerade Attacks


CH : @SparkSecurity

راح نشرح الموضوع بشكل مفصل اكثر من ناحية الـ BlueTeam و RedTeam وانت اخذ المعلومة بالطريقة اللي تعجبك وسوي محاكاة لهيج موضوع حتى توضح عندك 100% شلون تسوي محاكاة " CTF "

كلنا احد انواع الهجوم هو الـ Masquerade Attacks ب هذا النوع من الهجمات المهاجم يحاول يتنكر كانهُ هو جزء موثوق من النظام بس شلون !

اكيد ب استخدام تقنيات مُختلفة اللي هي

مثلاً ، الـ Credential Spoofing هاي عن طريق هذا التكنيك المهاجم يكدر يستغل ثغرات المصادقة للحصول على صلاحيات غير مخصصة إله او عن طريق الـ Privilege Escalation بعد التنكر وومحاولة دخول النظام يحاول يسوي رفع صلاحياتة داخل النظام للوصول الى بيانات حساسة وحسب اليوزر اللي يوصلة بالنظام حتى يوصل مرحلة التحكم بالنظام ب شكل كامل اذا يكدر

النتيجة .. اللي راح تؤديها هاي التقنيتين واكيد هالشي مو شرعي بس انت كـ Bug Hunter لما تكتب التقرير عن الـ Bug مثلاً اللي تصادفك ممكن تكول انو ممكن عن طريق الثغرتين اللي توصلهن يخليك تكدر تسرق بيانات المستخدمين او تنفذ عمليات ضارة ب استخدام التطبيق الفرعي الي بي Vulnerability او رسائل Phishing لمحاولة توسيع الهجمة

CH : @SparkSecurity

عدنا الـ Data-Driven Attacks الهجمات هاي تعتمد على البيانات نفسها بحيث المهاجم يكدر يستغل الثغرات الموجودة بالـ Data Handling او Api's للتلاعب بالبيانات المشتركة بين التطبيقات ، عن تجربتي اكثر شي شايفة هو ضعف النظام الامني من خلال الـ API مثل ماتعرفون الـ API هو وسيلة ربط بين مثلاً البرنامج الاساسي والبرنامج الفرعي المربوط ب التطبيق او الموقع او البرنامج من خلال هاي الثغرة .. راح تكدر تنفذ 3 هجمات واكو غيرها بعد بس حنشرح 3 بس

اللي هم اولاً عندك الـ SQL Injection هاي شارحين عنها وتعرفوها واللي هي ادخال اوامر خبيثة ب الحقول المدخلة من قبل المستخدمين مثل تسجيل الدخول او البحث

او عن طريق الـ Data Exfiltration هو سرقة البيانات اثناء معالجتها او نقلها بين الانظمة مثلاً بالمواقع ـ عمليات الـ GET , POST هو نقل البيانات بين الكلاينت والسيرفر وهسه نرجع لهاي النقطة بشكل مفصل اكثر ..

عدنا الـ Channel Hijacking هذا النوع من الهجمات يركز على قنوات الاتصال بين التطبيق الاساسي والتطبيق الفرعي ب استخدام تقنيات هواي ومنها

MITM المهاجم هنا يكدر يعترض الاتصالات ويعدل على البيانات المرسلة او المستلمة وحاجين عن الـ MiTM سابقاً

https://t.me/SparkSecurity/3282

او عن طريق الـSession hijacking من خلالها تتم سرقة الـ token او الـ Session token للمستخدم للوصول الى داتا المستخدم او عن طريق الـ Replay attacks هو اعادة ارسال بيانات قديمة مثل الرموز الامنية او API Request's

زين شنو نتيجة الـتقنيات هاي هو الـ Data Tempering التلاعب بالمعلومات الحساسة مثل تفاصيل المدفوعات او بيانات المستخدم ، وبنفس الوكت تسبب
Credential Harvesting اللي هي سرقة بيانات تسجيل ادلخول او السشنات النشطة

CH : @SparkSecurity

شنو أرائكم حول الموضوع شنو عدكم استفسارات ؟ تكدرون ترسلون النا عن طريق البوت

@Nationofdev_bot

راح نكمل شرحهم غير وكت ان شاء الله ، بالتوفيق ..

CH : @SparkSecurity

بوست جديد على الانستكرام !

اضغط هنا لمشاهدة المنشور

CH : @SparkSecurity

بالمنشور السابق حجينا عن الـ Data Exfiltration واليوم راح نشرح بشكل مفصل اكثر .. خليكم متابعين

الـ Data Exfiltration بالنسبة للمواقع ، تستغل العمليات مثل GET , POST لنقل العمليات بين الكلاينت والسيرفر

شلون تتم العملية بالضبط ؟

ببساطة تتم اذا جان الموقع يعرض بيانات حساسة ضمن الرابط URL
مثل
(:?id=12345&name=JohnDoe)
المهاجم يكدر يسوي اعتراضات عن هذا الرابط عبر تقنيات مثل

MITM - هنا يعترض اثناء نقل الطلب
Referrer Logs

مثل اداة الـ intruder بالـ Burp Suite يمكن استخدامها لتعديل واستغلال طلبات الـ GET اللي تحتوي على بيانات حساسة ب الرابط

اولاً تم الطريقة عن طريق جمع البيانات المهاجم يعترض طلب الـ GET ب استخدام Burp Suite ليحصل على الرابط اللي يحتوي على معلومات حساسة

GET /profile?id=12345&name=JohnDoe HTTP/1.1
Host: example.com

الرابط يحتوي على معلومات مثل ID و Name للاستغلال الي قد تكون اهدافا سهلة للاستغلال بعدها راح يتم ارسال طلب من خلال البربسيوت يتم ارسال طلب الى الانترودر ونحدد المعلومات للتلاعب ف راح تكون هيج

GET /profile?id=§12345§&name=§JohnDoe§ HTTP/1.1
Host: example.com

علامة الـ § تشير الى الاجزاء اللي يتم استهدافها وتعديلها اثناء الهجوم بعدها يتم اعداد البايلود حسب نوع الهجوم مثلا

راح يستغل ID's و users

الايدي تكون مثلاً ارقام ثانية 1001,1002,2604 والـ IDS ممكن تكون admin root وغيرها

لما يشتغل الانترودر راح يرسل البربسيوت الطلبات المعدلة للسيرفر ويحدد المهاجم اذا جان يكدر؟

هل من الممكن يوصل لبيانات مستخدمين اخرين عن طريق هاي الثغرة؟
او استغلال النظام للحصول على معلومات حساسة

العملية الاولى اللي صارت هي Information gathering بعدها payloads


مثال عن وصول الى بيانات مستخدم اخر

الـRequest الاصلي

GET /profile?id=12345&name=JohnDoe HTTP/1.1

الـ Request المُعدل

GET /profile?id=67890&name=JaneDoe HTTP/1.1

النتيجة اذا جان السيرفر معلومات مستخدم بناء على id دون تحقق اضافي ف المهاجم راح يكدر رؤية ب يانات الشخص JaneDoe

CH : @SparkSecurity

شلون نمنع هذا الهجوم من نضرة مُبرمجين لهاي المواقع !

دائماً نحاول نسوي استخدام التحقق من الهوية لكل طلب اللي هو الـ Authentication عن طريق ربط الريكوست ب جلسة المستخدم ب الـ Session الحالي عبر Token

او عن طريق تطبيق التحقق من المدخلات مالتنا عن طريق انو دائما نتحقق من ان الـ ID يخص المستخدم اللي قام بالطلب ، دائما لازم نستخدم ارقام معرفات غير متوقعة او بمعني تقني ( Non-Sequential IDs ) عن طريق استبدال ارقام الـ IDs بأرقام عشوائية او عن طريق تقنية الـ Tokenization واكيد وليس اخراً هو التشفير عبر الـ HTTPS لضمان ان البيانات ب مرحلة الطلب لا يتم اعتراضها ب الطريق!

CH : @SparkSecurity

شارك القناة في كروباتكم الدراسية للاستفادة

الي يداوم قسم امن سيبراني او اي تخصص تقني اخر

علوم حاسبات
هندسة حاسبات
نظم معلومات وباقي التخصصات الاخرى لان الكل ممكن يستفاد من المعلومات الموجودة بقناتنا

❤️.

CH : @SparkSecurity

اليوم نكمل شرح عن Data Exfiltration ، خليكم جاهزين!

مثل ما حجينا وكلنا أكو GET و POST Request


الـ GET Request ، يتم استخدامه لجلب البيانات من السيرفر والبيانات يتم ارسالها كجزء من الرابط ( URL )

GET /search?q=user123 HTTP/1.1

المشكلة هنا ان البيانات مكشوفة بالـ URL وممكن تتسجل بالـ Logs

حجينا ب شكل مُفصل عن الـ GET سابقاً اليوم ننتقل لعملية الـ POST

البوست ريكوست ، يتم استخدامه لارسال بيانات للموقع او السيرفر مثل الفورمات ( Forms ) وغيرها ، البيانات تكون مخفية بالـ Request body

مثال ..

POST /login HTTP/1.1
Content-Type: application/x-www-form-urlencoded

username=admin&password=supersecret

البيانات هنا مخفية لكنها ما زالت مُعرضة للاستغلال اذا ما صار تأمين قوي !

أكو هواي طرق للاستغلال اذا صار كلنا MITM أو Brute Force Attack h أو Request Analysis أو Input Validation أو Cross-Origin Resource Sharing

بالنسبة للـMITM
إذا جان الاتصال غير مشفر (بدون HTTPS)، المهاجمين يكدرون يعترضون البيانات أثناء نقلها بين الجهاز والسيرفر

مثال

المستخدم يرسل بيانات تسجيل الدخول، والمهاجم يستغل أدوات مثل Wireshark لالتقاط البيانات

اما بالنسبة لهجوم #Brute_Force_Attack اذا السيرفر ما يحتوي على اليات الحماية المضبوطة المهاجمين يكدرون يستخدمون محاولة ادخال البيانات بشكل اوتماتيكي مثل

عن طريق سكربت واحد ممكن ارسال هواي ريكوستات للسيرفر مثل تخمين كلمة سر مُعينة ب استخدام سكربت واحد

بالنسبة للريكوست انلايسز او تحليل البيانات المهاجم هنا يكدر يستخدم ادوات مثل الـ Brup Suite أو OWASP ZAP لفحص الطلبات وتعديلها قبل إرسالها للسيرفر يعني شلون

مثال

تغيير  البيانات الحقول بالـ Request body لارسال قيم مامتوقعة 

username=admin'--&password=123

لمحاولة استغلال ثغرات SQL Injection

بالنسبة للتحقيق من الانبت او المدخلات Input vaildation حجينا عنه بالنسبة للـ GET ، بس هنا اذا السيرفر ما يتحقق من المدخلات بشكل كافي المهاجم ايضاً ممكن يرسل سكربتات مثلاً جافا سكربت عبر الـ بوست ريكوست لاستهداف ثغرات الـ XSS او بِما تُسمى Cross-Site-Scripting مثال

username=<script>alert('Hacked!')</script>&password=123

الثغرة الشائعة هي استغلال ضعف
الـ CORS ( Cross-Origin Resource Sharing )

اذا اعدادات الـCORS مو صحيحة المهاجم ايضاً ممكن يرسل بوست ريكوست من مواقع غير موثوقة للتلاعب بالبيانات او حتى سرقتهاً

طرق التامين كُلش سهل تطبيقها بس اهم شي المتابعة دائماً .. عن طريق استخدام HTTPS اول شغلة! ، واكيد التشفير يمنع المهاجمين من اعتراض البيانات واكيد الاهم الحماية من البروت فورس ب استخدام معدل الريكوستات ب شكل محدود عن طريق وضع Rate Limting وقفل الحساب بعد عدد معين من المحاولات ..
واكيد لازم الـ API نأمنه بشكل قوي ونستخدم طريقة الـ Access Tokens بالنسبة للكود نستخدم الادوات التحليلية الامنية مثل

- SYNK
- Checkmarx

https://snyk.io/
https://checkmarx.com/

بالنسبة لمراقبة الريكوستات دائمااااا واريدك تركز عليها انو تراقب الـ Logs بشكل دائمي ، واعتماد ادوات التحليل مثل Splunk و ELK واكيد استخدام الـ WAF راح يمنع الطلبات Non trusted وكشف الانشطة

بما انو وصلنا لنهاية الموضوع وموضوع الـ Data Exfiltration على ما اعتقد اكتشفتوا بالنهاية انو الحل يبدي من تطبيق افضل الممارسات وهذا الشي صح! عن طريق التولز اللي وفرتهن الكم حسيت انت ماكو داعي تتعلم بس هذا الشي غلط تبقى هاي مجرد ادوات تساعدك بحماية موقعك الالكتروني او تحمي المواقع اللي تشتغل الهم 😉 ف نعتبر هذا شنو ؟ 🔑 اوكي؟

اوكي .. نصيحة اخيرة دائماً فكر مثل المهاجم

CH : @SparkSecurity

معلومة اليوم

أول لغة برمجية تتعلمها هي دائمًا الأصعب، بغض النظر عن مدى سهولة أو صعوبة اللغات الأخرى.

CH : @SparkSecurity