نقاط الضعف في الكود. كيف يمكنك تمييز عيب خطير من خطأ بسيط؟

كيف يبدو عادةً مثل التحقق من رمز التطبيق بحثًا عن نقاط الضعف؟ يبدأ أخصائي الأمان الإجراء ، ويتم فحص الرمز ، واكتشاف الآلاف من الثغرات الأمنية في التطبيق. الجميع - كل من رجل الأمن والمطورين - مصدومون. رد الفعل الطبيعي للمطور: "نعم ، نصفها بالتأكيد إيجابيات كاذبة والآخر نقاط ضعف غير حرجة!"



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



لكن حول ما هو حاسم وما هو غير ذلك ، أود أن أتحدث بشكل أكثر موضوعية. إذا فهمت سبب عدم إمكانية استخدام SHA-1 ولماذا الهروب "؛" ، فربما لن تفتح لك هذه المقالة شيئًا جديدًا. ولكن إذا كان الفحص ناتجًا عن نقاط الضعف المكتشفة ، فمرحبا بكم في ظل القطع - سنخبرك ما هي "الثغرات" التي توجد غالبًا في تطبيقات الجوال والويب ، وكيفية عملها ، وكيفية إصلاحها ، والأهم من ذلك - كيفية فهم ما هو أمامك - عيب خطير أو خطأ بسيط في الكود.

التنفيذ

حسنًا ، نوع شائع جدًا من نقاط الضعف. يتم تضمينها في كل مكان: في استعلامات SQL و LDAP و XML و XPath و XSLT و Xquery ... تتميز كل هذه الحقن باستخدام بيانات غير موثوق بها ، بفضل وصول المهاجم إلى المعلومات أو تغيير سلوك التطبيق. على سبيل المثال ، مع إدخال المستخدم الذي لم يتم التحقق من صحته بشكل كافٍ.



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



حقن SQL . تدخل البيانات غير الموثوق بها في استعلام SQL إلى قاعدة البيانات.







إذا كان استعلام قاعدة البيانات لا ينفذ المصادقة الصحيحة لبيانات الإدخال ، يمكن للمهاجم إتلاف استعلام SQL:

• إرسال تعليمات برمجية ضارة إليها ؛
• أضف الرمز "-" أو "؛" وإجهاض أمر SQL الصحيح: يتم تفسير كل شيء بعد "-" على أنه تعليق ، و "؛" يمثل نهاية الأمر ؛
• تخمين كلمة المرور من خلال تنفيذ سلسلة من استعلامات SQL بالتتابع.

كيف تدافع عن نفسك؟ فيما يلي بعض التوصيات من OWASP :

• استخدم واجهة برمجة تطبيقات توفر واجهة ذات معلمات أو أدوات تعيين ارتباط الكائنات (ORM).
• تنفيذ آلية التحقق من صحة البيانات التي أدخلها المستخدم. استخدم قائمة بيضاء للتحقق من جانب الخادم.
• تخلص من الأحرف الخاصة ("؛" ، "-" ، "/ *" ، "* /" ، "" ، القائمة الدقيقة تعتمد على قاعدة البيانات).
• استخدم الإجراءات المخزنة جنبًا إلى جنب مع آلية التصفية لمعلماتها للتحقق من صحة إدخال المستخدم.

حقن XML . تستخدم التطبيقات XML لتخزين البيانات أو تبادلها ، بحيث يمكن أن تحتوي على معلومات قيمة.







إذا تمكن المهاجم من كتابة البيانات إلى مستند XML ، فيمكنه تغيير دلالاتها. في هذه الحالة ، سيسمح لك السيناريو الأكثر ضررًا بإدخال علامات إضافية في المستند ، ونتيجة لذلك سينتهي محلل XML مع وجود خطأ. ولكن قد تواجه حادثة أكثر خطورة: على سبيل المثال ، مع استبدال بيانات المصادقة في قاعدة بيانات العملاء أو السعر في قاعدة بيانات المنتج بالمتجر. يمكن أن يؤدي إدخال XML أيضًا إلى البرمجة النصية عبر المواقع (XSS) - إدخال التعليمات البرمجية الضارة التي يتم تنفيذها في متصفح المستخدم عند فتح الصفحة.



ماذا ننصح؟

• لا تقم بإنشاء علامات وسمات يتم اشتقاق أسمائها من بيانات من مصدر غير موثوق به (على سبيل المثال ، أدخلها مستخدم).
• تشفير (ترميز كيان XML) البيانات التي أدخلها المستخدم قبل كتابتها في مستند XML.

يعد حقن XQuery أحد أشكال حقن SQL الكلاسيكي ، ولكن في هذه الحالة ، سيستهدف الهجوم قاعدة بيانات XML ، وستنتهي البيانات غير الموثوق بها في تعبير XQuery.



في المثال أدناه ، يقوم التطبيق بإنشاء وتنفيذ تعبير XQuery بناءً على المعلمات usernameومن passwordطلب HTTP (مصدر غير موثوق به):

XQDataSource xqs = new XQDataSource();
XQConnection conn = xqs.getConnection();
String query = "for \$user in doc(users.xml)//user[username='" + request.getParameter("username") + "'and pass='" + request.getParameter("password") + "'] return \$user";
XQPreparedExpression xqpe = conn.prepareExpression(query);
XQResultSequence rs = xqpe.executeQuery();

إذا كانت البيانات صحيحة ، فسيعيد الطلب معلومات حول المستخدم بالاسم وكلمة المرور المناسبين:

for \$user in doc(users.xml)//user[username='test_user' and pass='pass123'] return \$user

إذا حدد المهاجم سلسلة تحتوي على أحرف خاصة (على سبيل المثال ، admin' or 1=1 or ''=') كمعامل ، فستتغير دلالات الطلب:

//user[username='admin']

سيعيد الطلب المستلم بيانات حول جميع المستخدمين.



الخيار الآمن (الاستخدامات prepared statements):

XQDataSource xqs = new XQDataSource();
XQConnection conn = xqs.getConnection();
String query = "declare variable $username as xs:string external; declare variable $password as xs:string external; for \$user in doc(users.xml)//user[username='$username' and pass='$password'] return \$user";
XQPreparedExpression xqpe = conn.prepareExpression(query);
xqpe.bindString(new QName("username"), request.getParameter("username"), null);
xqpe.bindString(new QName("password"), request.getParameter("password"), null);
XQResultSequence rs = xqpe.executeQuery();

يمكن التضمين في XSLT (لغة ​​تحويل مستند XML) إذا كان التطبيق يستخدم بيانات من مصدر غير موثوق به عند العمل مع XSL.



تستخدم التطبيقات XSL لتحويل مستندات XML. تحتوي ملفات نمط XSL على وظائف تصف التحول ، وإذا لم يتم تنفيذها بشكل صحيح ، فقد تتضمن ثغرات أمنية. يؤدي ذلك إلى زيادة مخاطر سيناريوهات الهجوم التي يقوم فيها المهاجم بتغيير بنية ومحتوى ملف نمط XSL ، وبالتالي ملف XML المقابل. ماذا يمكن أن نحصل عند المخرج؟



أولاً ، هجوم XSS: إدخال شفرة ضارة في صفحة صادرة عن نظام ويب والتفاعل مع خادم المهاجم. ثانيًا ، يتمكن المتسلل من الوصول إلى موارد النظام. ثالثًا ، تنفيذ قانون تعسفي. وللحلوى - هجوم XXE (XML eXternal Entity - إدخال كيان خارجي في XML). يمكن أن يؤدي



تضمين بروتوكول الوصول لتغيير بيانات الدليل ( LDAP) في الأوامر إلى فقد البيانات أو تعديلها. في هذه الحالة ، تدخل البيانات غير الموثوق بها في طلب LDAP.



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



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

String btype = request.getParameter("backuptype");
String cmd = new String("cmd.exe /K
\"c:\\util\\rmanDB.bat "+btype+"&&c:\\utl\\cleanup.bat\"")
System.Runtime.getRuntime().exec(cmd);

المشكلة هنا هي أن المعلمة backuptypeلم يتم التحقق من صحتها. عادةً Runtime.exec()لا يتم تنفيذ أوامر متعددة ، ولكن في هذه الحالة يتم تشغيل cmd.exe أولاً لتنفيذ أوامر متعددة عن طريق استدعاء Runtime.exec(). بمجرد بدء تشغيل سطر الأوامر ، يمكنه تنفيذ عدة أوامر ، مفصولة بأحرف &&"". إذا && del c:\\dbms\\*.*حدد المهاجم السلسلة " " كمعامل ، فسيقوم التطبيق بحذف الدليل المحدد.



نصائح المطور:

• لا تدع المستخدمين يتحكمون بشكل مباشر في الأوامر التي يشغلها التطبيق. إذا كان يجب أن يعتمد سلوك التطبيق على البيانات التي أدخلها المستخدم ، فقدم للمستخدم خيارًا من قائمة معينة من الأوامر المسموح بها.
• , . , . , .
• , , . . .

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



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



نوصي أن يقوم محترفو أمن معلومات الشركة بإنشاء "قائمة بيضاء" بمسارات اتصال الملفات الصالحة بحيث يمكن للموظفين إضافة ملفات فقط وفقًا للنصوص من هذه القائمة.

إشارات مرجعية

الإشارات المرجعية هي الأجزاء التي يتم إدخالها عن قصد في رمز التطبيق ، والتي من خلالها ، في ظل ظروف معينة ، يمكنك تنفيذ إجراءات غير مدرجة في التطبيق. لنفكر في أكثر أنواع الإشارات المرجعية شيوعًا.



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







يستخدم مطور التطبيق حسابًا خاصًا (ربما بامتيازات مرتفعة) عند تصحيح الأخطاء ويترك الأقسام المقابلة من الكود في الإصدار النهائي ، مع الاحتفاظ بحق الوصول إلى التطبيق. يمكن للمهاجم استعادة الكود الأصلي للتطبيق ، واستخراج القيم الثابتة للحساب الخاص ، والوصول إلى التطبيق.

من المستحيل بشكل قاطع تخزين معلومات تسجيل الدخول وكلمات المرور والمفاتيح في التعليمات البرمجية المصدر للتطبيق.

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



نشاط الشبكة غير الموثق. يتضمن هذا النوع من النشاط: الاتصال بموارد الطرف الثالث في الخلفية ، والاستماع إلى المنافذ غير الموثقة ، ونقل المعلومات باستخدام بروتوكولات SMTP و HTTP و UDP و ICMP.

إذا وجدت اتصالاً مشبوهًا في الرمز بعنوان غير موجود في قائمة العناوين الآمنة المعروفة ، نوصي بشدة بحذفه.

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

if (isAuthenticated = true)
{
    someDangerousAction();
}

مشغل الوقت (قنبلة زمنية). إشارة مرجعية تنشط في وقت محدد. يقارن التطبيق التاريخ الحالي بسنة وشهر ويوم معينين: في 1 يناير 2021 ، تنتظر مفاجأة الجميع:

Date now = java.util.Date();    // current time
if ((now.getYear() == 2021) && (now.getMonth() == 1) && (now.getDate() == 1))
{
    activateNewYearBackdoor();
}

أو ربما لا ... في الممارسة العملية ، عند البحث عن محفزات مؤقتة ، غالبًا ما تظهر إيجابيات خاطئة. على سبيل المثال ، إذا تم استخدام واجهة برمجة التطبيقات للوقت للغرض المقصود منها: التسجيل ، وحساب وقت التنفيذ ، والطوابع الزمنية لاستجابات الخادم لطلبات HTTP.



لكن! ما زلنا نوصي بعدم إغلاق عينيك عن كل هذه الإنذارات ، لأننا نعرف أمثلة حقيقية لمثل هذه الثغرات الأمنية



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

قلة التشفير واستخدام خوارزميات تشفير ضعيفة

تتمثل المشاكل الرئيسية في التشفير في عدم استخدامه على الإطلاق ، أو استخدام خوارزميات ضعيفة ، والمفاتيح والملح بسيطة للغاية أو مخزنة بشكل غير آمن. نتيجة كل هذه الثغرات هي نفسها - فمن الأسهل سرقة البيانات السرية.



يوضح المثال تهيئة التشفير باستخدام خوارزمية DES القديمة:

Cipher cipher = Cipher.getInstance("DES");

أمثلة على خوارزميات التشفير الضعيفة: RC2 ، RC4 ، DES. الخيار الآمن:

Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");

وفقًا لتصنيف OWASP الدولي ، تحتل نقاط الضعف مثل "تسرب البيانات السرية" المرتبة الثالثة من حيث شدة تهديدات أمان تطبيقات الويب.



توصيتنا للمطورين: تأكد من استخدام التشفير مع وضع الأمان في الاعتبار.



يعد استخدام بروتوكول HTTP غير الآمن بدلاً من HTTPS محفوفًا بهجوم رجل في المنتصف.



يعتمد بروتوكول HTTPS الآمن على HTTP ، ولكنه يدعم أيضًا التشفير عبر بروتوكولات التشفير SSL / TLS. يقوم HTTPS بتشفير جميع البيانات المنقولة عبره ، ولا سيما صفحات تسجيل الدخول وكلمة المرور أو بيانات البطاقة المصرفية للمستخدم ، مما يحميهم من الوصول والتغييرات غير المصرح بها. على عكس HTTP الذي لا يحمي البيانات المرسلة. نتيجة لذلك ، يمكن للمهاجم انتحال موقع إعلامي عبر HTTP وإجبار المستخدم على إدخال بيانات على صفحة مزيفة (هجوم تصيد).



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



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



نصيحتنا: قم بإنشاء مفاتيح باستخدام مولدات الأرقام العشوائية الزائفة (PRNGs) القوية المشفرة وتخزينها باستخدام وحدات خاصة.



خوارزمية حشو غير آمنة للتشفير . إذا تم استخدام خوارزمية تشفير RSA بدون حشوة OAEP ، تصبح البيانات المشفرة ضعيفة .



هناك حاجة إلى خوارزمية OAEP لمعالجة الرسائل قبل استخدام RSA. يتم أولاً تعبئة الرسالة بطول ثابت باستخدام OAEP ، ثم يتم تشفيرها باستخدام RSA. يُطلق على نظام التشفير هذا اسم RSA-OAEP وهو جزء من المعيار الحالي .



هذا مثال على تهيئة تشفير RSA بدون تعبئة:

rsa = javax.crypto.Cipher.getInstance("RSA/NONE/NoPadding");

الخيار الآمن:

rsa = javax.crypto.Cipher.getInstance("RSA/ECB/OAEPWithMD5AndMGF1Padding");

حجم مفتاح التشفير غير كافٍ . إذا كنت تستخدم مفتاحًا قصيرًا ، فإن هذا التشفير يكون عرضة لهجمات القوة الغاشمة.



تحليل الشفرات لا يقف ساكنا ، خوارزميات هجوم جديدة تظهر باستمرار ، أجهزة الكمبيوتر تكتسب قوة أكبر. تم إهمال إعدادات التشفير التي كانت تعتبر آمنة في السابق ولم تعد موصى بها للاستخدام. لذلك ، لم يعد RSA بطول مفتاح 1024 بت يعتبر آمنًا في 2010-2015.



خوارزمية تجزئة ضعيفة . للأسباب الموضحة في الفقرة السابقة ، فإن وظائف التجزئة MD2 و MD5 و SHA1 غير آمنة. لا يتطلب موارد كبيرة للعثور على تضاربات لوظائف MD2 و MD5.



بالنسبة إلى SHA1 ، هناك أمثلة على ملفين مختلفين لهما نفس التجزئة. اقترحت خوارزمية القرصنةموظفو Google ومركز الرياضيات وعلوم الكمبيوتر في أمستردام.







إذا تم تخزين كلمات مرور المستخدم على هيئة تجزئات ، ولكن باستخدام وظيفة تجزئة غير آمنة ، يمكن للمهاجم الوصول إليها بسهولة من خلال تنفيذ السيناريو التالي. من خلال معرفة تجزئة كلمة المرور واستغلال نقاط الضعف في خوارزمية التجزئة ، من الممكن حساب سلسلة يكون فيها التجزئة هو نفسه لكلمة المرور. يقوم المهاجم بالمصادقة باستخدام السلسلة المحسوبة.



يجب أن تكون وظيفة التجزئة لتخزين كلمات المرور مقاومة للتصادم وليست سريعة جدًا بحيث لا يمكن تنفيذ هجوم القوة الغاشمة. يجب استخدام الخوارزميات الآمنة PBKDF2 و bcrypt و scrypt.



بعض الأرقام المثيرة للاهتمام: باستخدام PBKDF2تم تقليل سرعة البحث إلى 70 قطعة في الثانية بالنسبة إلى Intel Core2 وحوالي ألف بالنسبة لـ FPGA Virtex-4 FX60. بالمقارنة ، فإن وظائف تجزئة كلمة مرور LANMAN الكلاسيكية لديها معدل قوة غاشمة يبلغ حوالي مئات الملايين من الخيارات في الثانية.



خوارزمية تشفير ضعيفة . كما هو الحال مع خوارزميات التجزئة ، يتم تحديد أمان خوارزمية التشفير من خلال الوقت والموارد التي يجب إنفاقها على فك تشفيرها. RC2 ، RC4 ، DES تعتبر خوارزميات ضعيفة. هذا الأخير ، بسبب طول مفتاحه الصغير (56 بت) ، يمكن تصدعها بالقوة الغاشمة.



مولد رقم عشوائي زائف ضعيف (PRNG) يولد تسلسلات يمكن التنبؤ بها. يمكن للمخترق تجاوز المصادقة واختطاف جلسة المستخدم.



دعنا نتعمق قليلاً في طبيعة PRNGs. يولدون سلاسل من الأرقام بناءً على القيمة الأولية للمعامل seed. هناك نوعان من PRNGs - الإحصائي والتشفير.



تولد PRNGs الإحصائية متواليات يمكن التنبؤ بها مشابهة إحصائيًا للتسلسلات العشوائية. لا يمكن استخدامها لأغراض أمنية.



على العكس من ذلك ، لا يمكن التنبؤ بنتيجة تشغيل PRNGs المشفرة إذا تم seedالحصول على قيمة المعلمة من مصدر ذي إنتروبيا عالية. القيمة الزمنية الحالية لها القليل من الانتروبيا وهي أيضًا غير آمنة من حيث الجودة seed. في جاوة، PRNGs من الطبقات java.util.Randomو java.lang.Mathتوليد تسلسل يمكن التنبؤ بها، وينبغي ألا تستخدم لأغراض أمن المعلومات.



بذرة ضعيفة لمولد أعداد زائفة عشوائية . من غير seedالآمن استخدام قيمة من مصدر غير موثوق به لأنه يولد تسلسلاً يمكن التنبؤ به.



يعتمد عمل العديد من خوارزميات التشفير على استخدام PRNG المقاوم لتحليل التشفير. يمكن لبعض الخوارزميات أن تأخذ قيمة كوسيطة إضافية seedوتولد تسلسلًا يمكن التنبؤ به لكل قيمة من هذه المعلمة. في هذه الحالة ، يعتمد أمان النظام على افتراض أن القيم seedستكون غير متوقعة.



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



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

التلاعب بالسجلات

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



التلاعب في ملف السجل عندما يكتب أحد التطبيقات بيانات غير موثوق بها في سجل الأحداث (السجل). يمكن للمتسلل تزوير إدخالات السجل أو إدخال تعليمات برمجية ضارة فيها.



عادةً ما تكتب التطبيقات محفوظات المعاملات إلى السجل لمزيد من المعالجة أو التصحيح أو جمع الإحصائيات. يمكن تحليل السجلات يدويًا أو تلقائيًا.

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



في هذا المثال ، يحاول تطبيق ويب قراءة قيمة عدد صحيح من معلمة طلب. إذا تعذر تحويل القيمة المدخلة إلى عدد صحيح ، فسيسجل التطبيق هذه القيمة مع رسالة خطأ:

String val = request.getParameter("val");
try {
    int value = Integer.parseInt(val);
}
catch (NumberFormatException nfe) {
    log.info("Failed to parse val = " + val);
}

يمكن للمهاجم إضافة إدخال عشوائي إلى السجل ، على سبيل المثال ، twenty-one%0a%0aINFO:+User+logged+out%3dbadguyسينعكس السطر في السجل على النحو التالي:

INFO: Failed to parse val=twenty-one
INFO: User logged out=badguy

وبالمثل ، يمكن تضمين السجلات التعسفية في السجل.



الخيار الآمن (الاستخدامات NumberFormatException):

public static final String NFE = "Failed to parse val. The input is required to be an integer value."

String val = request.getParameter("val");
try {
    int value = Integer.parseInt(val);
}
catch (NumberFormatException nfe) {
    log.info(NFE);
}

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

يُقبل إخراج رسائل الخطأ إلى التدفقات القياسية فقط في المراحل الأولى من التطوير.

التعامل غير الآمن مع ملفات تعريف الارتباط

إن نقاط الضعف المرتبطة بجمع ملفات تعريف الارتباط الخاصة بالمستخدم متنوعة للغاية.



التعامل غير الآمن مع ملفات تعريف الارتباط . يشتمل التطبيق على بيانات من مصدر غير موثوق به في ملف تعريف الارتباط ، مما قد يؤدي إلى تسمم ذاكرة التخزين المؤقت ، و XSS (البرمجة النصية عبر المواقع) وهجمات تقسيم الاستجابة.



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



نظرًا لأنه يتم تعيين ملفات تعريف الارتباط في رأس استجابة HTTP ، فإن الفشل في التعرف على البيانات المضمنة في ملف تعريف الارتباط يمكن أن يؤدي إلى هجوم استجابة منقسم. "تقسيم استجابة HTTP" هو هجوم يرسل فيه المتسلل طلب HTTP ، والذي سيتم قبول الرد عليه من قبل الضحية في استجابتي HTTP في وقت واحد (بدلاً من الرد الصحيح).

إذا حدد المهاجم authorسلسلة من النموذج كمعامل Hacker \r\nHTTP/1.1 200 OK\r\n...، فسيتم تقسيم الإجابة إلى قسمين على النحو التالي:

HTTP/1.1 200 OK
...
Set-Cookie: author=Hacker

HTTP/1.1 200 OK
...

محتوى الرد الثاني تحت سيطرة المهاجم تمامًا ، مما يؤدي إلى تسمم ذاكرة التخزين المؤقت ، و XSS ، وعمليات إعادة التوجيه الضارة ، وهجمات أخرى.



ملفات تعريف الارتباط بدون HttpOnly . يقوم التطبيق بإنشاء ملفات تعريف الارتباط بدون علم httpOnly. إذا تم httpOnlyتضمينه في رأس الاستجابة http، فلن يتمكن المهاجم من الحصول على ملفات تعريف الارتباط باستخدام كود JavaScript. وإذا فتح المستخدم صفحة بها ثغرة أمنية في البرمجة النصية عبر المواقع (XSS) ، فلن يكشف المتصفح عن ملفات تعريف الارتباط لأطراف ثالثة. إذا httpOnlyلم يتم تعيين العلم ، فيمكن سرقة ملفات تعريف الارتباط (عادةً ملفات تعريف ارتباط الجلسة) باستخدام برنامج نصي.



مثال على إنشاء ملف تعريف ارتباط بدون علم httpOnly:

Cookie cookie = new Cookie("emailCookie", email);
response.addCookie(cookie);

ضع العلم httpOnlyعند إنشاء ملفات تعريف الارتباط. ضع في اعتبارك ، مع ذلك ، أن هناك طرقًا لتجاوز الهجمات ، httpOnlyلذا يجب عليك أيضًا الاهتمام بالتحقق من صحة الإدخال بعناية.



ملحوظة: وفقًا لتصنيف OWASP الدولي ، تحتل الثغرات الأمنية "تسرب البيانات السرية" المرتبة الثالثة في مستوى أهمية تهديدات أمان تطبيقات الويب.



ملفات تعريف الارتباط لمجال عام للغاية . إذا كان مجال ملف تعريف الارتباط عامًا جدًا (على سبيل المثال .example.com) ، فإن الثغرة الأمنية في أحد التطبيقات تعرض التطبيقات الأخرى في نفس المجال إلى نقاط الضعف.



في المثال التالي ، يقوم تطبيق ويب آمن مثبت على عنوان http://secure.example.comبتعيين ملف تعريف ارتباط بقيمة مجال .example.com:

Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setDomain(".example.com");

إذا تم http://insecure.example.comتثبيت تطبيق يحتوي على ، على سبيل المثال ، XSS على العنوان ، http://insecure.example.comفيمكن اختراق ملفات تعريف الارتباط للمستخدم المعتمد للتطبيق الآمن الذي انتقل إلى العنوان .



يمكن للمهاجم أيضًا تنفيذ هجوم تسمم بملفات تعريف الارتباط: http://insecure.example.comستحل ملفات تعريف الارتباط ذات النطاق المشترك محل ملف تعريف الارتباط http://secure.example.com.



الخيار الآمن:

Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setDomain("secure.example.com");

ملفات تعريف الارتباط بمعامل عام للغايةpath . إذا كان المسار في ملف تعريف الارتباط غير دقيق (على سبيل المثال ، /) ، تظهر نفس المشكلة كما هو الحال مع المجال المشترك: تعرض إحدى الثغرات الأمنية في أحد التطبيقات تطبيقات أخرى في نفس المجال.



في المثال التالي ، يقوم أحد التطبيقات المثبتة على عنوان URL http://pages.example.com/forumبتعيين ملف تعريف ارتباط بالمسار /:

Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setPath("/");

بعد ذلك ، يمكن أن يؤدي تطبيق ضار مثبت على العنوان إلى http://pages.example.com/evilاختراق ملفات تعريف الارتباط الخاصة بالمستخدم. يمكن للمهاجم أيضًا تنفيذ هجوم تسمم ملفات تعريف الارتباط: ملف تعريف الارتباط الذي تم إنشاؤه بمسار مشترك /evilسيحل محل ملف تعريف الارتباط /forum.



الخيار الآمن:

Cookie cookie = new Cookie("sessionID", sessionID);
cookie.setPath("/forum");

ملفات تعريف الارتباط لا تتجاوز SSL . يقوم التطبيق بإنشاء ملفات تعريف الارتباط بدون تعيين العلامة secureمتساوية true. يمكن نقل ملفات تعريف الارتباط هذه بدون تشفير عبر HTTP. يتم استدعاء الثغرة الأمنية "استخدام بروتوكول HTTP غير الآمن" على الفور.



في المثال التالي ، يقوم التطبيق بإنشاء ملفات تعريف الارتباط بدون علامة secure:

Cookie cookie = new Cookie("emailCookie", email);
response.addCookie(cookie);

إذا كان التطبيق يستخدم HTTPS و HTTP ، ففي حالة عدم وجود علامة آمنة ، سيتم إرسال ملفات تعريف الارتباط التي تم إنشاؤها كجزء من طلب HTTPS في شكل غير مشفر على طلبات HTTP اللاحقة ، مما قد يؤدي إلى اختراق التطبيق. هذا أمر خطير بشكل خاص إذا كان ملف تعريف الارتباط يحتوي على بيانات قيمة ، ولا سيما معرّف الجلسة.



الخيار الآمن:

Cookie cookie = new Cookie("emailCookie", email);
cookie.setSecure(true);
response.addCookie(cookie);

ملفات تعريف الارتباط ذات الصلاحية غير المحدودة . إذا قمت بتخزين ملفات تعريف الارتباط القيمة لفترة طويلة جدًا ، يمكن للمهاجم الوصول إليها.



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



توصيات المطورين: تأكد من أن التطبيق لا يقوم بإنشاء ملفات تعريف ارتباط طويلة الأمد:

Cookie cookie = new Cookie("longCookie", cookie);
cookie.setMaxAge(5*365*24*3600); // 5 !

توفير حد أقصى معقول للوقت باتباع إرشادات OWASP .

تسرب المعلومات

ربما يكون أكثر أنواع الثغرات حساسية لمستخدمي التطبيق.



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



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



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







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



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



هذا هو الحال عندما يتعارض أمان التطبيق وخصوصية البيانات الشخصية مع بعضهما البعض. لأسباب أمنية ، يُنصح بتسجيل معلومات مفصلة حول النشاط في النظام من أجل اكتشاف النشاط الضار. من وجهة نظر خصوصية البيانات ، على العكس من ذلك ، عند تسجيل المعلومات السرية ، يكون خطر تسربها أكبر. بشكل عام ، يعتبر ضمان سرية البيانات الشخصية لمستخدمي التطبيق أولوية أعلى.

خاتمة

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



المؤلف: إليزافيتا خارلاموفا ، رئيس قسم التحليلات ، تطبيق Solar appScreener