1. مبدأ الهجوم
تستخدم ملفات تعريف الارتباط التي تتمثل بشكل أساسي في الممارسة غير الآمنة لتخزين معلومات تسجيل الدخول إلى المستخدم على الشبكة الحالية.
نحن نعلم أن نظام المستخدم العام المستند إلى ملفات تعريف الارتباط سيقوم بتخزين متغيرين على الأقل في ملفات تعريف الارتباط: اسم المستخدم و userLevel ، حيث يكون اسم المستخدم هو اسم المستخدم ومستخدم المستخدم هو مستوى المستخدم. عندما يصل متصفحنا إلى صفحة ASP ، فإنه سوف ينبعث منه شيء مثل
get /.../file.asp http 1.0
...
ملفات تعريف الارتباط: اسم المستخدم = المستخدم و userLevel = 1
...
بعد ذلك ، طالما أننا نعرف اسم المستخدم للمسؤول وقيم استخدام المستخدم (بافتراض المسؤول و 5 على التوالي) ، يمكننا نقله
get /.../file.asp http 1.0
...
ملفات تعريف الارتباط: اسم المستخدم = admin & userLevel = 5
...
للحصول على أذونات المسؤول. بسيطة جدا ، أليس كذلك؟ ومع ذلك ، قبل اكتشاف الضعف ، تعتمد جميع أنظمة إدارة المستخدم تقريبًا على ملفات تعريف الارتباط.
2. تخزين معلومات المستخدم بأمان
نظرًا لأن ملفات تعريف الارتباط غير آمنة ويجب علينا تخزين معلومات تسجيل الدخول إلى المستخدم ، أين يجب تخزينها؟
لاحظنا أنه في ASP ، بالإضافة إلى ملفات تعريف الارتباط ، هناك أيضًا جلسة يمكنها تخزين المعلومات. يتم تخزين الجلسة على الخادم ولا يمكن تغييرها من قبل العميل في الإرادة ، لذلك لديها أمان مرتفع للغاية. وبهذه الطريقة ، يمكن للجميع تغيير رمز جميع ملفات تعريف الارتباط إلى الجلسة.
3. تخزين معلومات المستخدم لفترة طويلة
يتم استخدام الجلسة لحفظ معلومات تسجيل الدخول إلى المستخدم. يتم توليد الطريقة الموصوفة في هذا القسم.
هناك متغيرات من هذه الطريقة. توفيرها وفقًا لملفات تعريف الارتباط. الرمز لتنفيذ هذه الطريقة هو كما يلي:
VBS:
<٪
اسم المستخدم الخافت ، كلمة المرور
اسم المستخدم = الجلسة (اسم المستخدم)
إذا كان اسم المستخدم = إذن
لا توجد معلومات تسجيل دخول المستخدم في الجلسة
اسم المستخدم = request.cookies (اسم المستخدم)
كلمة المرور = request.cookies (كلمة المرور)
"انتبه إلى اسم المستخدم وكلمة المرور التي تم الحصول عليها في الجملتين أعلاه لمنع نقاط الضعف في حقن SQL (أي تصفية عروض الأسعار المفردة") ، تم حذفها هنا
إذا كان اسم المستخدم = أو كلمة المرور = إذن
لا يتم تسجيل الدخول إلى المستخدم
...
آخر
"من المفترض هنا إنشاء كائنات Conn و RS
RS.Open حدد TOP 1 * من [user] where username = '& username &' و password = '& password &' ، conn ، 1 ، 3
إذا rs.eof ثم
المعلومات الموجودة في ملفات تعريف الارتباط غير قانونية
...
آخر
المعلومات الموجودة في ملفات تعريف الارتباط قانونية وتسجيل الدخول تلقائيًا
الجلسة (اسم المستخدم) = اسم المستخدم
...
إنهاء إذا
إنهاء إذا
آخر
توجد معلومات المستخدم بالفعل في الجلسة ويتم قراءتها مباشرة
...
إنهاء إذا
٪>
JS:
<٪
var اسم المستخدم ، كلمة المرور ؛
اسم المستخدم = الجلسة (اسم المستخدم) + ؛
if (username == || اسم المستخدم == غير محدد) {
// لا توجد معلومات مستخدم في الجلسة
username = request.cookies (اسم المستخدم) + ؛
password = request.cookies (كلمة المرور) + ؛
// انتبه إلى اسم المستخدم وكلمة المرور التي تم الحصول عليها في جملتين أعلاه لمنع نقاط الضعف في حقن SQL (أي تصفية عروض الأسعار المفردة) ، تم حذفها هنا
if (username == || username == undefined || password == || password == undefined) {
// لم يتم تسجيل الدخول إلى المستخدم
...
}
آخر {
// هنا من المفترض أن يتم إنشاء كائنات Conn و RS
Rs.Open (حدد TOP 1 * من [user] where username = ' + username +' و password = ' + password +' ، conn ، 1 ، 3) ؛
إذا (rs.eof) {
// المعلومات الموجودة في ملفات تعريف الارتباط غير قانونية
...
}
آخر {
// المعلومات الموجودة في ملفات تعريف الارتباط قانونية وتسجيل الدخول تلقائيًا
الجلسة (اسم المستخدم) = اسم المستخدم + ؛
...
}
}
}
آخر {
// معلومات المستخدم موجودة بالفعل في الجلسة ويتم قراءتها مباشرة
...
}
٪>
ومع ذلك ، فإن هذه الطريقة ليست آمنة للغاية للمستخدمين ، لأن المتصفح سوف ينقل ملفات تعريف الارتباط في كل مرة يزور فيها الصفحة ، وسيتم سرقة حساب المستخدم بمجرد الحصول على ملفات تعريف الارتباط التي تحتوي على كلمة المرور من قبل الآخرين. بالنسبة لهذه الحالة ، تظهر الطريقة الثانية ، إضافة رمز التحقق من الحقل إلى قاعدة بيانات معلومات المستخدم. تتم إضافة قيمة الكود. عند التحقق من معلومات المستخدم في ملفات تعريف الارتباط ، يتم التحقق من اسم المستخدم و VERIMECODE فقط. تتمثل ميزة هذه الطريقة في أنه حتى إذا تم الحصول على ملفات تعريف الارتباط الخاصة بالمستخدم من قبل المتسلل ، فيمكنه فقط استخدام رمز التحقق المؤقت هذا لتسجيل الدخول ، ولا يمكنه الحصول على كلمة مرور المستخدم. طالما أن هذا المستخدم يقوم بتسجيل الدخول باستخدام اسم المستخدم وكلمة المرور مرة أخرى ، فسيتغير قيمة التحقق من الرمز ولن يتمكن المتسلل من تسجيل الدخول عبر رمز التحقق الأصلي.
يتطلب تنفيذ هذه الطريقة فقط تغييرات طفيفة على رمز الطريقة المذكورة أعلاه. أولاً ، في برنامج تسجيل الدخول الخاص بك ، تحتاج إلى إضافة فقرة حيث يمر التحقق لتخزين معلومات المستخدم:
VBS:
<٪
استجابة.
٪>
JS:
<٪
Response.Cookies (VerifyCode) = Math.Floor (Math.Random () * 2100000000) ؛
٪>
بعد ذلك ، في رمز التحقق المذكور أعلاه ، قم بتغيير التحقق من ملفات تعريف الارتباط (كلمة المرور) إلى التحقق من ملفات تعريف الارتباط (VerifyCode).
4. الخلاصة
من خلال تحليلنا ومعالجتنا ، تم حل تعرض ملفات تعريف الارتباط بالكامل ، ومنذ ذلك الحين ، أصبحت برامج ASP أكثر أمانًا.
2007-08-05 20:37 تبدأ الكتابة
2007-08-05 21:14 تم الانتهاء من الإصدار الأول