أين يجب عليك تمكين SSL؟

Question

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

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

Answer 1

أنا شخصياً أختار "SSL from go to woe".

إذا لم يُدخل المستخدم رقم بطاقة الائتمان مطلقًا، فبالتأكيد، لا يوجد SSL.

ولكن هناك تسرب أمني محتمل متأصل من إعادة تشغيل ملف تعريف الارتباط.

1. يزور المستخدم الموقع ويتم تعيين ملف تعريف الارتباط له.
2. يتصفح المستخدم الموقع ويضيف البيانات إلى سلة التسوق (باستخدام ملف تعريف الارتباط)
3. ينتقل المستخدم إلى صفحة الدفع باستخدام ملف تعريف الارتباط.

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

يتعين عليك نقل المعلومات من النطاق غير الآمن إلى النطاق الآمن، والعودة مرة أخرى، دون أي ضمانات للحماية.

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

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

Answer 2

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

تمتلك المتصفحات أيضًا في بعض الأحيان سياسة تخزين مؤقت مختلفة لـ HTTPS عن HTTP.

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

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

Answer 3

لقد فعلت ذلك دائمًا على الموقع بأكمله.

Answer 4

أنا أيضًا سأستخدم HTTPS على طول الطريق.ليس لهذا تأثير كبير على الأداء (نظرًا لأن المتصفح يقوم بتخزين المفتاح المتماثل الذي تم التفاوض عليه بعد الاتصال الأول) ويحمي من الاستنشاق.

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

Answer 5

أعتقد أن القاعدة الأساسية الجيدة هي فرض طبقة المقابس الآمنة (SSL) في أي مكان حيث من المحتمل أن يتم نقل المعلومات الحساسة.على سبيل المثال:أنا عضو في Wescom Credit Union.يوجد قسم في الصفحة الأولى يسمح لي بتسجيل الدخول إلى حسابي المصرفي عبر الإنترنت.ولذلك، تفرض الصفحة الجذر SSL.

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

Answer 6

في مؤسستنا لدينا ثلاثة تصنيفات للتطبيقات -

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

نحن نستخدم هذه المعايير لتحديد تقسيم البيانات، وأي جوانب الموقع تتطلب SSL.يتم حساب SSL إما على الخادم أو من خلال المسرعات مثل Netscaler.مع زيادة مستوى معلومات تحديد الهوية الشخصية (PII)، يزداد أيضًا تعقيد عملية التدقيق ونمذجة التهديدات.

كما يمكنك أن تتخيل، نحن نفضل القيام بتطبيقات LBI.

Answer 7

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

Answer 8

بشكل عام، في أي وقت تقوم فيه بنقل بيانات حساسة أو شخصية، يجب عليك استخدام SSL - على سبيل المثال.ربما لا تحتاج إضافة عنصر إلى سلة إلى SSL، أو يجب أن يكون تسجيل الدخول باستخدام اسم المستخدم/كلمة المرور الخاصة بك، أو إدخال تفاصيل CC الخاصة بك مشفرًا.

Answer 9

هناك جانب سلبي رئيسي واحد للكامل https الموقع وليس السرعة (هذا جيد).

سيكون من الصعب جدًا تشغيل YouTube ومربعات "الإعجاب" وما إلى ذلك دون تحذير غير آمن.

نحن ندير موقعًا إلكترونيًا آمنًا بالكامل ونتسوق لمدة عامين حتى الآن، وهذا هو العيب الأكبر.لقد تمكنا من تشغيل Youtube الآن ولكن "إضافة هذا" لا يزال يمثل تحديًا كبيرًا.وإذا قاموا بتغيير أي شيء في البروتوكول، فمن الممكن أن تكون جميع أفلامنا على اليوتيوب فارغة...

Answer 10

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

Answer 11

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