ما الذي يحتاج مطور PHP إلى معرفته حول اتصالات طبقة المقابس الآمنة https/؟

Question

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

Answer 1

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

يتكون كل طلب HTTP (أو HTTPS) من جزأين:طلب، واستجابة.عندما تطلب شيئًا ما عبر HTTPS، هناك في الواقع بعض الأشياء التي تحدث في الخلفية:

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

إذا ظل الاتصال مفتوحًا، فسيتم استخدام نفس المفتاح المتماثل لكل منهما.

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

لمعرفة المزيد عن مدة الجلسات انظر ما المدة التي يستمر فيها مفتاح HTTPS المتماثل؟

الشهادات وأسماء المضيفين

يتم تعيين اسم شائع (CN) للشهادات، وهو اسم النطاق بالنسبة لـ HTTPS.يجب أن يتطابق CN تمامًا، على سبيل المثال، الشهادة التي تحتوي على CN لـ "example.com" لن تتطابق مع المجال "www.example.com"، وسيتلقى المستخدمون تحذيرًا في متصفحهم.

قبل سني, ، لم يكن من الممكن استضافة أسماء نطاقات متعددة على عنوان IP واحد.لأنه يتم جلب الشهادة قبل أن يرسل العميل طلب HTTP الفعلي، ويحتوي طلب HTTP على المضيف:سطر الرأس الذي يخبر الخادم بعنوان URL الذي يجب استخدامه، لا توجد طريقة للخادم لمعرفة الشهادة التي سيتم تقديمها لطلب معين.يضيف SNI اسم المضيف إلى جزء من مصافحة TLS، وطالما أنه مدعوم على كل من العميل والخادم (وفي عام 2015، أصبح مدعومًا على نطاق واسع) فيمكن للخادم اختيار الشهادة الصحيحة.

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

هناك طريقة أخرى وهي استخدام شهادات البدل.من الممكن الحصول على شهادة مثل ".example.com" وفي هذه الحالة سيكون كل من "www.example.com" و"foo.example.com" صالحين لتلك الشهادة.ومع ذلك، لاحظ أن "example.com" لا يتطابق مع ".example.com"، ولا "foo.bar.example.com".إذا كنت تستخدم "www.example.com" لشهادتك ، فيجب عليك إعادة توجيه أي شخص على "example.com" إلى "www." موقع.إذا طلبوا https://example.com, ، إلا إذا قمت باستضافته على عنوان IP منفصل ولديك شهادتين، فسيحصل على خطأ في الشهادة.

بالطبع، يمكنك المزج بين كل من أحرف البدل وشبكات SAN (طالما أن المرجع المصدق الخاص بك يسمح لك بذلك) والحصول على شهادة لكل من "example.com" ومع شبكات SAN ".example.com"، و"example.net"، و".example.net"، على سبيل المثال.

نماذج

بالمعنى الدقيق للكلمة، إذا كنت ترسل نموذجًا، فلا يهم إذا كانت صفحة النموذج نفسها غير مشفرة، طالما أن عنوان URL للإرسال يذهب إلى https:// URL.في الواقع، تم تدريب المستخدمين (نظريًا على الأقل) على عدم إرسال الصفحات إلا إذا رأوا "رمز القفل" الصغير، لذا يجب تقديم النموذج نفسه عبر HTTPS للحصول على هذا.

تحميل حركة المرور والخادم

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

أفضل الممارسات

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

• يجب أن تأتي أي موارد على الصفحة من نفس المخطط المستخدم للصفحة.إذا حاولت جلب صور من http:// عند تحميل الصفحة باستخدام HTTPS، فسيتلقى المستخدم تحذيرات أمنية.يجب عليك إما استخدام عناوين URL المؤهلة بالكامل، أو هناك طريقة سهلة أخرى وهي استخدام عناوين URL المطلقة التي لا تتضمن اسم المضيف (على سبيل المثال، src="/images/foo.png") لأنها تعمل لكليهما.

  • يتضمن ذلك الموارد الخارجية (مثل Google Analytics)

• لا تقم بإجراء POSTs (إرسال النموذج) عند التغيير من HTTPS إلى HTTP.ستشير معظم المتصفحات إلى هذا كتحذير أمني.

Answer 2

لن أتعمق في SSL بشكل عام، فقد قام gregmac بعمل رائع في هذا الشأن، انظر أدناه ؛-).

ومع ذلك، فإن بعض الأخطاء الأكثر شيوعًا (والخطيرة) التي تم ارتكابها (وليس PHP على وجه التحديد) فيما يتعلق باستخدام SSL/TLS:

1. السماح بـ HTTP عندما يتعين عليك فرض HTTPS
2. استرداد بعض الموارد عبر HTTP من صفحة HTTPS (على سبيل المثال:الصور وإطارات IFRAME وما إلى ذلك)

3. التوجيه إلى صفحة HTTP من صفحة HTTPS دون قصد - لاحظ أن هذا يتضمن صفحات "مزيفة"، مثل "about:blank" (لقد رأيت هذا يستخدم كعناصر نائبة لـ IFRAME)، وسيؤدي ذلك إلى ظهور تحذير منبثق دون داعٍ وبشكل مزعج.

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

5. تم تكوين خادم الويب لدعم أجنحة تشفير غير آمنة (لقد رأيت الأصفار الخالية فقط قيد الاستخدام ، والتي توفر بشكل أساسي أي تشفير) (DITTO)

6. الشهادات الموقعة ذاتيًا - تمنع المستخدمين من التحقق من هوية الموقع.

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

8. ملف تعريف الارتباط غير الآمن - ملفات تعريف الارتباط ذات الصلة بالأمان (مثل معرف الجلسة، ورمز المصادقة، ورمز الوصول، وما إلى ذلك) يجب يتم تعيينها مع مجموعة السمات "الآمنة".هذا مهم!إذا لم يتم تعيينه على التأمين، فإن ملف تعريف ارتباط الأمان، على سبيل المثال.يمكن إرسال SessionId عبر HTTP (!) - ويمكن للمهاجمين التأكد من حدوث ذلك - وبالتالي السماح باختطاف الجلسة وما إلى ذلك.أثناء قيامك بذلك (على الرغم من أن هذا لا يرتبط بشكل مباشر)، قم بتعيين سمة HttpOnly على ملفات تعريف الارتباط الخاصة بك أيضًا (يساعد في تخفيف بعض XSS).

9. الشهادات شديدة التسامح - لنفترض أن لديك عدة نطاقات فرعية، ولكن ليست جميعها على نفس مستوى الثقة.على سبيل المثال، لديك www.yourdomain.com، وdowload.yourdomain.com، وpublicaccess.yourdomain.com.لذلك قد تفكر في استخدام شهادة بدل....ولكن لديك أيضًا Secure.yourdomain.com، أو Finance.yourdomain.com - حتى على خادم مختلف.سيكون publicaccess.yourdomain.com قادرًا بعد ذلك على انتحال شخصية Secure.yourdomain.com....على الرغم من أنه قد تكون هناك حالات يكون فيها هذا أمرًا جيدًا، إلا أنك عادةً ما تريد فصل بعض الامتيازات...

هذا كل ما أذكره الآن، وربما أعيد تعديله لاحقا..

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

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

وأيضًا، يجب أن تكون كلمات المرور (وبيانات الاعتماد الأخرى) ومعلومات بطاقة الائتمان وما إلى ذلك دائمًا عبر SSL/TLS.

Answer 3

تأكد من أنه عندما تكون في صفحة HTTPS، فإن جميع العناصر الموجودة في الصفحة تأتي من عنوان HTTPS.وهذا يعني أن العناصر يجب أن يكون لها مسارات نسبية (على سبيل المثال."/images/banner.jpg") بحيث يتم توريث البروتوكول، أو أنك تحتاج إلى إجراء فحص في كل صفحة للعثور على البروتوكول، واستخدام ذلك لجميع العناصر.

ملحوظة:يتضمن ذلك جميع الموارد الخارجية (مثل ملفات جافا سكريبت الخاصة بـ Google Analytics)!

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

Answer 4

أود أن أقول إن الأخطاء الأكثر شيوعًا عند العمل مع موقع يدعم طبقة المقابس الآمنة (SSL) هي

1. يقوم الموقع بإعادة توجيه المستخدمين عن طريق الخطأ إلى http من صفحة باسم https
2. لا يتحول الموقع تلقائيًا إلى https عندما يكون ذلك ضروريًا
3. يتم تحميل الصور والأصول الأخرى الموجودة على صفحة https عبر http، مما سيؤدي إلى إطلاق تنبيه أمني من المتصفح.تأكد من أن جميع الأصول تستخدم معرفات URI مؤهلة بالكامل والتي تحدد https.
4. تعمل شهادة الأمان فقط لنطاق فرعي واحد (مثل www) ولكن موقعك يستخدم في الواقع نطاقات فرعية متعددة.تأكد من الحصول على شهادة بدل إذا كنت ستحتاج إليها.

Answer 5

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

مؤشر واحد إذا كنت تستخدم https

جعله بحيث إذا كتب المستخدمhttp://www.website-that-needs-https.com/etc/yadda.phpسيتم إعادة توجيههم تلقائيًا إلىhttps://www.website-that-needs-https.com/etc/yadda.php(غيظ الحيوانات الأليفة الشخصية)

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

Answer 6

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

باختصار، قم بإنشاء الصفحة التي تسجل فيها الدخول من خلال ssl، بدلاً من النشر على صفحة ssl.

Answer 7

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