مقدمة سريعة لأمن الويب

تمهيدي لمطور الويب عن CORS و CSP و HSTS وجميع اختصارات أمان الويب!

هناك العديد من الأسباب للتعرف على أمان الويب ، مثل:

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

وهلم جرا.

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

قبل أن نفعل ذلك ، لنتأكد من فهمنا لمفهومين أساسيين للأمان.

مفهومان أساسيان للأمن

لا أحد آمن بنسبة 100٪.

لا توجد فكرة أن تكون محميًا بنسبة 100٪ من التعرض للاختراق. إذا أخبرك أحد بذلك ، فهو مخطئ.

طبقة واحدة من الحماية لا تكفي.

لا يمكنك أن تقول فقط ...

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

ربما يكون هذا معطى للبعض ، لكن من السهل أن تجد نفسك تفكر بهذه الطريقة. أعتقد أن أحد الأسباب التي تجعل المبرمجين يجدون أنفسهم بسهولة يفكرون بهذه الطريقة هو أن الكثير من الترميز بالأبيض والأسود ، 0 أو 1 ، صحيح أو خطأ. الأمن ليس بهذه البساطة.

سنبدأ بواحد يواجهه الجميع مبكرًا إلى حد ما في رحلة تطوير الويب الخاصة بهم. ثم تنظر إلى StackOverflow وتجد مجموعة من الإجابات تخبرك بكيفية تجاوزها.

مشاركة الموارد عبر الأصول (CORS)

هل سبق لك أن حصلت على خطأ يشبه هذا؟

No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.

أنت بالتأكيد لست وحدك. وبعد ذلك يمكنك البحث في Google ، ويخبرك شخص ما بالحصول على هذا الامتداد الذي سيجعل كل مشاكلك تختفي!

عظيم ، أليس كذلك؟

CORS موجود لحمايتك وليس لإيذائك!

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

لنفترض أنك قمت بتسجيل الدخول إلى Facebook ، وأنهم يستخدمون ملفات تعريف ارتباط المصادقة. تضغط على bit.ly/r43nugiالذي يعيد توجيهك إلى superevilwebsite.rocks. يقوم البرنامج النصي الموجود بداخله superevilwebsite.rocksبعمل طلب من جانب العميل facebook.comيقوم بإرسال ملف تعريف ارتباط المصادقة الخاص بك إليه!

في حالة عدم وجود CORS ، يمكنهم إجراء تغييرات على حسابك دون علمك. إلى أن ينشروا ، بالطبع ، bit.ly/r43nugiعلى جدولك الزمني ، وينقر جميع أصدقائك عليه ، ثم ينشرون bit.ly/r43nugiعلى جميع الجداول الزمنية لأصدقائك ثم تستمر الدورة في مخطط شرير أولًا ينتصر على جميع مستخدمي Facebook ، ويستهلك العالم superevilwebsite.rocks. ؟

ومع ذلك ، في عالم CORS ، سيسمح Facebook فقط بالطلبات ذات الأصل facebook.comلتحرير البيانات على الخادم الخاص بهم. وبعبارة أخرى ، فإنها ستحد من مشاركة الموارد عبر المنشأ. قد تسأل بعد ذلك ...

حسنًا ، هل يمكن لـ superevilwebsite.rocks تغيير رأس الأصل بناءً على طلبهم ، بحيث يبدو أنه قادم من facebook.com؟

يمكنهم المحاولة ، لكنها لن تنجح لأن المتصفح سيتجاهلها فقط ويستخدم الأصل الحقيقي.

حسنًا ، ولكن ماذا لو جعل superevilwebsite.rocks الطلب من جانب الخادم؟

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

سياسة أمان المحتوى (CSP)

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

XSS هو عندما يقوم شخص شرير بحقن JavaScript في كود العميل الخاص بك. قد تعتقد ...

ماذا سيفعلون؟ تغيير اللون من الأحمر إلى الأزرق؟

لنفترض أن شخصًا ما قد نجح في إدخال JavaScript في رمز جانب العميل لموقع الويب الذي تزوره.

ما الذي يمكن أن يفعلوه سيكون ضارًا؟

  • يمكنهم تقديم طلبات HTTP إلى موقع آخر يتظاهرون بهويتك.
  • يمكنهم إضافة علامة ارتساء ترسلك إلى موقع ويب يبدو متطابقًا مع الموقع الذي تستخدمه مع بعض الخصائص الضارة والمختلفة قليلاً.
  • يمكنهم إضافة علامة برنامج نصي مع JavaScript مضمنة.
  • يمكنهم إضافة علامة نصية تجلب ملف JavaScript بعيد في مكان ما.
  • يمكنهم إضافة إطار iframe يغطي الصفحة ويبدو وكأنه جزء من موقع الويب يطالبك بإدخال كلمة مرورك.

الاحتمالات لا حصر لها.

يحاول CSP منع حدوث ذلك عن طريق الحد من:

  • ما يمكن فتحه في إطار iframe
  • ما هي أوراق الأنماط التي يمكن تحميلها
  • حيث يمكن تقديم الطلبات ، إلخ.

فكيف يعمل؟

عندما تنقر فوق ارتباط أو تكتب عنوان URL لموقع ويب في شريط العناوين في متصفحك ، يقوم المستعرض الخاص بك بتقديم طلب GET. في النهاية يشق طريقه إلى خادم يقدم HTML مع بعض رؤوس HTTP. إذا كنت مهتمًا بشأن الرؤوس التي تتلقاها ، فافتح علامة التبويب الشبكة في وحدة التحكم الخاصة بك ، وقم بزيارة بعض مواقع الويب.

قد ترى رأس استجابة يبدو كالتالي:

content-security-policy: default-src * data: blob:;script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self';style-src data: blob: 'unsafe-inline' *;connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* //fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

هذه هي سياسة أمان المحتوى الخاصة بـ facebook.com. دعنا نعيد تنسيقها لتسهيل قراءتها:

content-security-policy: default-src * data: blob:; script-src *.facebook.com *.fbcdn.net *.facebook.net *.google-analytics.com *.virtualearth.net *.google.com 127.0.0.1:* *.spotilocal.com:* 'unsafe-inline' 'unsafe-eval' *.atlassolutions.com blob: data: 'self'; style-src data: blob: 'unsafe-inline' *; connect-src *.facebook.com facebook.com *.fbcdn.net *.facebook.net *.spotilocal.com:* wss://*.facebook.com:* //fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;

الآن ، دعونا نكسر التوجيهات.

  • default-src يقيد جميع توجيهات CSP الأخرى غير المدرجة بشكل صريح.
  • script-srcيقيد البرامج النصية التي يمكن تحميلها.
  • style-src يقيد أوراق الأنماط التي يمكن تحميلها.
  • connect-src يقيد عناوين URL التي يمكن تحميلها باستخدام واجهات البرنامج النصي ، لذلك الجلب ، XHR ، ajax ، إلخ.

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

إذا لم يكن هناك رأس CSP موجودًا ، فسيتم كل شيء ، ولن يتم تقييد أي شيء. في كل مكان تراه *، هذا هو البدل. يمكنك أن تتخيل استبدال *أي شيء وسوف يُسمح بذلك.

HTTPS أو HTTP آمن

بالتأكيد سمعت عن HTTPS. ربما سمعت بعض الناس يقولون ...

لماذا يهمني استخدام HTTPS إذا كنت فقط على موقع ويب ألعب لعبة.

أو ربما سمعت الجانب الآخر ...

أنت مجنون إذا كان موقعك لا يحتوي على HTTPS. إنه 2018! لا تثق في أي شخص يقول غير ذلك.

ربما سمعت أن Chrome سيضع علامة على موقعك على أنه غير آمن إذا لم يكن HTTPS.

يعتبر HTTPS في جوهره مباشرًا إلى حد ما. يتم تشفير HTTPS و HTTP ليس كذلك.

فلماذا هذا مهم إذا كنت لا ترسل بيانات حساسة؟

استعد لاختصار آخر… MITM ، والذي يرمز إلى Man in the Middle.

إذا كنت تستخدم شبكة Wi-Fi عامة بدون كلمة مرور في المقهى ، فمن السهل جدًا أن يتصرف شخص ما مثل جهاز التوجيه الخاص بك ، بحيث تمر جميع الطلبات والردود عليها. إذا لم يتم تشفير بياناتك ، فيمكنهم فعل ما يريدون بها. يمكنهم تحرير HTML أو CSS أو JavaScript قبل أن يصلوا إلى متصفحك. بالنظر إلى ما نعرفه عن XSS ، يمكنك تخيل مدى سوء هذا الأمر.

حسنًا ، ولكن كيف يعرف جهاز الكمبيوتر الخاص بي والخادم كيفية التشفير / فك التشفير ولكن هذا MITM لا يعرف؟

That’s where SSL (Secure Sockets Layer) and more recently, TLS (Transport Layer Security) come in. TLS took over for SSL in 1999 as the encryption technology used within HTTPS. Exactly how TLS works is outside of the scope of this post.

HTTP Strict-Transport-Security (HSTS)

This one is pretty straightforward. Let’s use Facebook’s header as an example again:

strict-transport-security: max-age=15552000; preload
  • max-age specifies how long a browser should remember to force the user to access a website using HTTPS.
  • preload is not important for our purposes. It is a service hosted by Google and not part of the HSTS specification.

This header only applies if you accessed the site using HTTPS. If you accessed the site via HTTP, the header is ignored. The reason is that, quite simply, HTTP is so insecure that it can’t be trusted.

Let’s use the Facebook example to further illustrate how this is helpful in practice. You are accessing facebook.com for the first time, and you know HTTPS is safer than HTTP, so you access it over HTTPS, //facebook.com. When your browser receives the HTML, it receives the header above which tells your browser to force-redirect you to HTTPS for future requests. One month later, someone sends you a link to Facebook using HTTP, //facebook.com, and you click on it. Since one month is less than the 15552000 seconds specified by the max-age directive, your browser will send the request as HTTPS, preventing a potential MITM attack.

Closing Thoughts

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