اتصال آمن بين العميل والخادم

Question

أقوم بتطوير مكون خادم يخدم طلبات العميل المضمن، والذي يقع أيضًا تحت سيطرتي.

الآن كل شيء تجريبي ويعمل الأمان على النحو التالي:

1. يرسل العميل اسم المستخدم / كلمة المرور عبر https.

2. يقوم الخادم بإرجاع رمز الوصول.

3. يقدم العميل المزيد من الطلبات عبر http باستخدام رمز الوصول في رأس مخصص.

يعد هذا أمرًا جيدًا بالنسبة للإصدار التجريبي، ولكن به بعض المشكلات التي يجب إصلاحها قبل إصداره:

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

• يمكن لأي شخص الاستماع والحصول على مفتاح الوصول بمجرد فحص رؤوس الطلب.

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

شكرا جزيلا على البصيرة.

ملاحظة:أنا أستخدم Java للخادم ويتم ترميز العميل بلغة C++، فقط في حالة حدوث ذلك.

Answer 1

لا أحصل على الجزء الأول، إذا كان طلب تسجيل الدخول هو https، فكيف يمكن لأي شخص نسخه فقط؟

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

في متصفح، في الأساس كل ما لديك هو عنوان IP (الذي ليس جيدا جدا)، ولكن في حالتك قد تكون قادرا على التعبير عن شيء محدد حول جهازك الذي تتحقق منه مقابل الطلب لضمان عدم وجود نفس الرمز تستخدم من مكان آخر.

تحرير: هل يمكن أن تكون محظوظا هنا وكن قادرا على استبعاد عنوان IP المتغير وراء الوكلاء، واستخدامه في الواقع لهذا الغرض.

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

Answer 2

السؤال الأول، فقط للحصول عليه هناك: إذا كنت مهتما بما فيه الكفاية بشأن الوصول إلى العميل الشديد، فلماذا لا تنفذ المحادثة بأكملها على https؟ هل ضرب الأداء الأدنى كبيرا بما يكفي لهذا التطبيق أنه لا يستحق الطبقة المضافة للأمن؟

ثانيا، كيف يمكن لشخص ما إعادة طلب تسجيل الدخول؟ إذا لم أكن مخطئا، فهذا يحدث على https؛ إذا تم إعداد الاتصال بشكل صحيح، فإن HTTPS يمنع اعادتها الهجمات باستخدام أونسات لمرة واحدة (انظر هنا).

Answer 3

إحدى التوصيات الشائعة هي - استخدم https

يجب أن يكون الهجوم على رجل https في المنتصف جانبًا باستخدام https للجلسة بأكملها موثوقًا بدرجة كافية.لا داعي للقلق بشأن رموز الوصول - حيث يعتني https بهذا الأمر نيابةً عنك.

يبدو أن استخدام http لمزيد من الطلبات يؤدي إلى ظهور بعض نقاط الضعف.الآن يمكن لأي شخص لديه متسلل للشبكة اعتراض حركة المرور الخاصة بك وسرقة الرمز المميز وانتحال طلباتك.يمكنك إنشاء حماية لمنع ذلك - تشفير الرمز المميز، واستخدام الرموز المميزة مرة واحدة، وما إلى ذلك.ولكن من خلال القيام بذلك سوف تقوم بإعادة إنشاء https.

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

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

يحرر

ثانيًا Yishai - نعم، هناك بعض النفقات العامة، خاصة وحدة المعالجة المركزية (CPU)، ولكن إذا كانت هذه النفقات الإضافية تدفع خادمك إلى الخارج، فستواجه مشكلات أكبر في تطبيقك