مع الأخذ في الاعتبار أن تطوير ASP يمكن أن يستخدم لغتين: vbs وjs، يتم توفير أكواد البرنامج باللغتين هنا (نسخة ثنائية اللغة؟ وسط YY...) جملة أخيرة، الجهاز الذي استخدمته لكتابة هذه المقالة لا يحتوي على بيئة ASP، لذلك لم يتم اختبار الكود المقدم، وأنا أعتذر عن ذلك. إذا وجدت أي مشاكل في الكود، فلا تتردد في التعليق ~لدي بشرة سميكة ~
1. مبدأ الهجوم
يستغل انتحال ملفات تعريف الارتباط بشكل أساسي الممارسة غير الآمنة المتمثلة في تخزين معلومات تسجيل دخول المستخدم في ملفات تعريف الارتباط بواسطة بعض أنظمة إدارة المستخدم على الشبكة الحالية. تعتبر طريقة الهجوم الخاصة به صعبة نسبيًا مقارنة بنقاط الضعف مثل ثغرات حقن SQL، ولكنها لا تزال غبية جدًا.
نحن نعلم أن نظام المستخدم العام الذي يعتمد على ملفات تعريف الارتباط سيخزن متغيرين على الأقل في ملفات تعريف الارتباط: اسم المستخدم ومستوى المستخدم، حيث اسم المستخدم هو اسم المستخدم ومستوى المستخدم هو مستوى المستخدم. عندما يصل متصفحنا إلى صفحة ASP، فإنه سيرسل شيئًا مثل
احصل على /.../file.asp HTTP 1.0
...
ملفات تعريف الارتباط: اسم المستخدم=مستوى المستخدم&مستوى المستخدم=1
...
الحزمة، فطالما أننا نعرف اسم مستخدم المسؤول وقيم مستوى المستخدم (من المفترض أن يكون admin و5 على التوالي)، فيمكننا الإرسال
احصل على /.../file.asp HTTP 1.0
...
ملفات تعريف الارتباط: اسم المستخدم=admin&userlevel=5
...
للحصول على حقوق المسؤول. بسيط جدا أليس كذلك؟ ومع ذلك، قبل اكتشاف هذه الثغرة الأمنية، كانت جميع أنظمة إدارة المستخدم تقريبًا تعتمد على ملفات تعريف الارتباط.
2. تخزين معلومات المستخدم بشكل آمن
بما أن ملفات تعريف الارتباط ليست آمنة، ويجب علينا تخزين معلومات تسجيل دخول المستخدم، فأين يجب تخزينها؟
لاحظنا أنه في ASP، بالإضافة إلى ملفات تعريف الارتباط، هناك أيضًا جلسة يمكنها تخزين المعلومات. يتم تخزين الجلسة على الخادم ولا يمكن للعميل تغييرها بشكل عرضي، لذا فهي تتمتع بأمان عالٍ للغاية. بهذه الطريقة، يمكنك استبدال جميع رموز ملفات تعريف الارتباط بـ Session.
3. تخزين معلومات المستخدم لفترة طويلة
استخدام الجلسة لحفظ معلومات تسجيل دخول المستخدم، على الرغم من التخلص من مشكلة خداع ملفات تعريف الارتباط، إلا أنه لا يمكن تخزين الجلسة لفترة طويلة (تنتهي جلسة IIS الافتراضية بعد 20 دقيقة من توقف المستخدم عن الاستجابة)، لذلك تم وصف طريقة التخزين المختلط لملفات تعريف الارتباط + الجلسة يتم إنتاجه في هذا القسم.
هناك نوعان مختلفان من هذه الطريقة. الأول هو تخزين اسم المستخدم وكلمة المرور في ملفات تعريف الارتباط. عندما يزور المستخدم إحدى الصفحات، تتم قراءة الجلسة أولاً. إذا كان هناك محتوى، فستسود ملفات تعريف الارتباط يجب قراءتها واستخدام المعلومات المقدمة في ملفات تعريف الارتباط. قم بتسجيل الدخول بشكل غير شفاف باستخدام اسم المستخدم وكلمة المرور الخاصة بك لتحديد ما إذا كان المحتوى الموجود في ملفات تعريف الارتباط قانونيًا أم لا، وسيتم تخزينه في الجلسة. رمز تنفيذ هذه الطريقة هو كما يلي:
فبس:
انسخ رمز الكود كما يلي:
<%
اسم المستخدم خافت، كلمة المرور
اسم المستخدم = الجلسة (اسم المستخدم)
إذا كان اسم المستخدم = إذن
' لا توجد معلومات تسجيل دخول للمستخدم في الجلسة
اسم المستخدم = طلب ملفات تعريف الارتباط (اسم المستخدم)
كلمة المرور = طلب ملفات تعريف الارتباط (كلمة المرور)
"لاحظ أن اسم المستخدم وكلمة المرور اللذين تم الحصول عليهما في الجملتين أعلاه يجب منعهما من الثغرات الأمنية لإدخال SQL (أي يتم تصفية علامات الاقتباس المفردة")، والتي تم حذفها هنا.
إذا كان اسم المستخدم = أو كلمة المرور = إذن
'لم يتم تسجيل دخول المستخدم
...
آخر
'يفترض هذا أنه تم إنشاء كائنات conn و rs
rs.Open حدد TOP 1 * من [المستخدم] حيث اسم المستخدم =' & اسم المستخدم & ' وكلمة المرور =' & كلمة المرور & '، conn، 1، 3
إذا rs.eof بعد ذلك
'المعلومات الموجودة في ملفات تعريف الارتباط غير قانونية
...
آخر
'المعلومات الموجودة في ملفات تعريف الارتباط قانونية، قم بتسجيل الدخول تلقائيًا
الجلسة (اسم المستخدم) = اسم المستخدم
...
نهاية إذا
نهاية إذا
آخر
'معلومات المستخدم موجودة بالفعل في الجلسة، اقرأها مباشرة
...
نهاية إذا
%>
شبيبة:
انسخ رمز الكود كما يلي:
<%
فار اسم المستخدم وكلمة المرور؛
اسم المستخدم = الجلسة (اسم المستخدم) + ;
إذا (اسم المستخدم == || اسم المستخدم == غير محدد) {
// لا توجد معلومات مستخدم في الجلسة
اسم المستخدم = Request.Cookies(اسم المستخدم) + ;
كلمة المرور = Request.Cookies(password) + ;
// لاحظ أن اسم المستخدم وكلمة المرور اللذين تم الحصول عليهما في الجملتين أعلاه يجب أن يمنعا ثغرات حقن SQL (أي تصفية علامات الاقتباس المفردة ')، والتي تم حذفها هنا.
إذا (اسم المستخدم == || اسم المستخدم == غير محدد || كلمة المرور == || كلمة المرور == غير محددة) {
// لم يتم تسجيل دخول المستخدم
...
}
آخر {
// هذا يفترض أنه تم إنشاء كائنات conn و rs
rs.Open(SELECT TOP 1 * FROM [user] WHERE username=' + username + 'ANDpassword=' +password+', conn, 1, 3);
إذا (rs.eof) {
// المعلومات الموجودة في ملفات تعريف الارتباط غير قانونية
...
}
آخر {
// المعلومات الموجودة في ملفات تعريف الارتباط قانونية، قم بتسجيل الدخول تلقائيًا
جلسة (اسم المستخدم) = اسم المستخدم + ;
...
}
}
}
آخر {
// معلومات المستخدم موجودة بالفعل في الجلسة، اقرأها مباشرة
...
}
%>
ومع ذلك، فإن هذه الطريقة ليست آمنة جدًا للمستخدمين لأن المتصفح سيرسل ملفات تعريف الارتباط في كل مرة يزورون فيها الصفحة، وبمجرد حصول الآخرين على ملفات تعريف الارتباط التي تحتوي على كلمات مرور، سيتم سرقة حساب المستخدم. في هذه الحالة، هناك طريقة ثانية، وهي إضافة حقل رمز التحقق في قاعدة بيانات معلومات المستخدم. عندما يقوم المستخدم بتسجيل الدخول، يتم إنشاء قيمة تحقق صحيحة طويلة بشكل عشوائي وتخزينها في حقل رمز التحقق، واسم المستخدم ورمز التحقق هذا. تتم إضافة قيمة ملفات تعريف الارتباط الخاصة بالمتجر بدلاً من كلمة المرور. عند التحقق من معلومات المستخدم في ملفات تعريف الارتباط، يتم التحقق من اسم المستخدم ورمز التحقق فقط. وتتمثل ميزة هذه الطريقة في أنه حتى إذا حصل أحد المتسللين على ملفات تعريف الارتباط الخاصة بالمستخدم، فيمكنه فقط استخدام رمز التحقق الذي تم إنشاؤه مؤقتًا لتسجيل الدخول، ولكن لا يمكنه الحصول على كلمة مرور المستخدم. وطالما قام هذا المستخدم بتسجيل الدخول باستخدام اسم المستخدم وكلمة المرور مرة أخرى، ستتغير قيمة رمز التحقق، ولن يتمكن المتسللون من تسجيل الدخول من خلال رمز التحقق الأصلي.
لا يتطلب تنفيذ هذه الطريقة سوى تغييرات طفيفة في كود الطريقة الأولى أعلاه. أولاً، في برنامج تسجيل الدخول الخاص بك، تحتاج إلى إضافة فقرة يتم فيها تخزين معلومات المستخدم بعد التحقق:
فبس:
انسخ رمز الكود كما يلي:
<%
الاستجابة. ملفات تعريف الارتباط (رمز التحقق) = int(rnd * 2100000000)
%>
شبيبة:
انسخ رمز الكود كما يلي:
<%
Response.Cookies(verifycode) = Math.floor(Math.random() * 2100000000);
%>
ثم قم بتغيير التحقق من ملفات تعريف الارتباط (كلمة المرور) إلى التحقق من ملفات تعريف الارتباط (رمز التحقق) في رمز التحقق المذكور أعلاه.
4. الاستنتاج
ومن خلال تحليلنا ومعالجتنا، تم حل مشكلة عدم حصانة ملفات تعريف الارتباط بشكل كامل، ومنذ ذلك الحين، أصبح برنامج ASP الخاص بنا أكثر أمانًا.