يقول مؤلف المادة ، التي ننشر ترجمتها اليوم ، أن هناك العديد من الأسباب لدراسة أمن الويب. على سبيل المثال ، يهتم مستخدمو مواقع الويب المهتمون بسرقة بياناتهم الشخصية بمشكلات الأمان. يتعلق الأمان بمطوري الويب الذين يسعون إلى زيادة مستوى الحماية لمشاريعهم. ويمكن قول الشيء نفسه عن المبرمجين المبتدئين الذين يبحثون عن عمل ويستعدون للمقابلات. الغرض من هذه المقالة هو فهم بعض تقنيات أمان الويب المهمة بلغة مفهومة. قبل أن نبدأ في الحديث عن هذه التقنيات ، والتي يشار إليها عادةً باسم الاختصارات مثل CORS و CSP و HSTS ، سنلقي نظرة على بضعة مفاهيم أمنية أساسية.
مفهومان أساسيان لأمان الويب
▍ 100٪ حماية أسطورة
في عالم الأمن ، لا يوجد شيء اسمه "حماية 100٪ من القرصنة". إذا أخبرك شخص ما عن هذا المستوى من الحماية ، فكن على دراية بأنه مخطئ.
ne مستوى واحد من الحماية لا يكفي
افترض أن شخصًا ما يعتقد أنه من خلال تنفيذ CSP ، قام بحماية مشروعه بالكامل من هجمات XSS. ربما يدرك شخص ما أن الحماية المطلقة لا وجود لها ، ولكن أفكارًا مثل تلك المذكورة أعلاه يمكن أن تزور أي شخص. إذا تحدثنا عن المبرمجين الذين قرروا فهم القضايا الأمنية ، فربما يكون سبب هذه الأفكار هو حقيقة أنهم عند كتابة كود البرنامج ، يعملون بشكل أساسي مع مفاهيم مثل "أسود" و "أبيض" ، 1 و 0 "صواب" و "خطأ". لكن السلامة ليست بهذه البساطة.
تقنيات أمن الويب
لنبدأ المناقشة حول أمان الويب باستخدام التكنولوجيا ، والتي يهتم بها المطورون عادةً في وقت مبكر جدًا ، على سبيل المثال ، في بداية مسارهم المهني. بالمناسبة ، إذا كنت تريد تجاوز طريقة الحماية هذه ، فيمكنك العثور على الكثير من المعلومات حول كيفية القيام بذلك على StackOverflow. حول CORS.
ORCORS
هل سبق لك أن رأيت مثل هذا الخطأ:
No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'null' is therefore not allowed access.
في مواجهة هذا ، تعتقد أنك بالتأكيد لست أول من حدث معه هذا. Googling ، تكتشف أنه من أجل حل هذه المشكلة ، يكفي تثبيت نوع من التمديد. حسنًا ، أليست رائعة؟ ومع ذلك ، لا توجد تقنية CORS (مشاركة الموارد عبر المصدر ، مشاركة الموارد بين مصادر مختلفة) من أجل التدخل مع المطورين ، ولكن من أجل حماية مشاريعهم.
لفهم كيفية حماية CORS لمشاريع الويب ، سنتحدث أولاً عن ملفات تعريف الارتباط ، على وجه الخصوص ، ملفات تعريف الارتباط المستخدمة لمصادقة المستخدمين. يتم استخدام ملفات تعريف الارتباط هذه عند العمل مع مورد ويب معين لإبلاغ الخادم بتسجيل دخول المستخدم. يتم إرسالها تلقائيًا مع تشغيل الطلبات إلى الخادم المقابل.
افترض أنك قمت بتسجيل الدخول إلى حساب Facebook الخاص بك ، ويستخدم Facebook ملفات تعريف الارتباط للمصادقة. من خلال العمل على الإنترنت ، انقر فوق الرابط
bit.ly/r43nugi ، تتم إعادة توجيهك إلى موقع ويب ضار ، على سبيل المثال ، شيء مثل
superevilwebsite.rocks . يُجري النص البرمجي الذي تم تنزيله مع الصفحة على هذا الموقع طلب عميل إلى
facebook.com باستخدام ملف تعريف الارتباط للمصادقة.
في عالم خالٍ من CORS ، يمكن أن يقوم برنامج نصي من
superevilwebsite.rocks سرًا بإجراء تغييرات على ملف تعريف FB الخاص بك ، ويمكن أن يسرق بعض المعلومات ، مع كل العواقب المترتبة على ذلك. في مثل هذا العالم ، كان من الممكن أن تنشأ بسهولة "وباء superevilwebsite.rocks" ، عندما ينشر نص برمجي يلتقط إدارة حساب المستخدم رابطًا على صفحته ، وينقر على أصدقاء هذا المستخدم "يصابون بأنفسهم" ، ومن خلال الروابط المنشورة على صفحاتهم ، وباء يغطي في نهاية المطاف كل الفيسبوك.
ومع ذلك ، في عالم يوجد فيه CORS ، سيسمح Facebook فقط بطلبات تعديل بيانات الحساب من
facebook.com . بعبارة أخرى ، ستحد إدارة الموقع من تقاسم الموارد بين المصادر المختلفة.
هنا قد يكون لديك السؤال التالي: "لكن superevilwebsite.rocks يمكن ببساطة تغيير رأس المصدر في طلباتها وستبدو وكأنها تأتي من facebook.com؟"
قد يحاول موقع احتيالي القيام بذلك ، لكنه لن ينجح ، لأن المتصفح سيتجاهل هذا العنوان ويستخدم بيانات حقيقية.
"ماذا لو قام superevilwebsite.rocks بطلب مشابه من الخادم؟" ، تسأل.
في وضع مماثل ، يمكن التحايل على CORS ، ولكن لن يكون هناك أي فائدة في ذلك ، لأنه من خلال تنفيذ طلب من الخادم ، لن يكون من الممكن إرسال ملف تعريف ارتباط المصادقة إلى Facebook. لذلك ، يجب تنفيذ البرنامج النصي ، من أجل إكمال هذا الطلب بنجاح ، من جانب العميل والحصول على ملفات تعريف الارتباط المخزنة على العميل.
SP CSP
لفهم ماهية CSP (سياسة أمان المحتوى وسياسة حماية المحتوى) ، تحتاج أولاً إلى التحدث عن واحدة من أكثر نقاط الضعف على الويب شيوعًا. يتعلق الأمر بـ XSS (برمجة نصية عبر المواقع ، برمجة نصية عبر المواقع).
عند تنفيذ هجوم XSS ، يقوم المهاجم بحقن شفرة JavaScript خاصة في جزء العميل من موقع معين. قد تعتقد: "حسنًا ، ماذا سيفعل هذا النص البرمجي؟ هل تريد تغيير ألوان عناصر الصفحة؟ "
افترض أن أحد الأشخاص نجح في تضمين نص JS النصي الخاص به في صفحات الموقع الذي تزوره. ما الذي يمكن أن يفعله نص مماثل؟ في الواقع ، الكثير من الأشياء:
- يمكنه تقديم طلبات HTTP إلى مواقع أخرى ، متظاهرًا بأنك تفعلها.
- يمكنه إعادة توجيهك إلى موقع يبدو تمامًا مثل الموقع الذي قمت بتسجيل الدخول إليه ، ولكنه مصمم ، على سبيل المثال ، لسرقة بيانات الاعتماد.
- إنه قادر على إضافة علامات
<script> إلى الصفحات التي تحتوي على بعض تعليمات JavaScript البرمجية أو المصممة لتحميل نوع من ملفات JS. - يمكنه إضافة عنصر
<iframe> إلى الصفحة ، والذي ، على سبيل المثال ، سيبدو تمامًا مثل حقول إدخال الاسم وكلمة المرور للدخول إلى الموقع. في هذه الحالة ، سيتم إخفاء هذه الحقول لإدخال هذه البيانات.
في الواقع ، الاحتمالات التي تفتح أمام المهاجم لتنفيذ هجوم XSS بنجاح لا حصر لها.
تحاول سياسة حماية المحتوى منع ذلك من خلال تطبيق القيود التالية:
- قيود على ما يمكن فتحه في
<iframe> . - القيود التي يمكن تحميل أوراق الأنماط.
- قيود على الاستفسارات التي يمكن تنفيذها.
كيف يعمل CSP؟
عندما تنقر على الرابط أو تدخل عنوان URL لموقع الويب في شريط عنوان المتصفح ، يقوم المتصفح بطلب GET. يأتي الطلب إلى الخادم ، الذي يمرر بعض تعليمات HTML البرمجية إلى المتصفح مع رؤوس HTTP. إذا كنت مهتمًا بالنظر إلى هذه العناوين ، فافتح علامة التبويب Network (الشبكة) في أدوات مطور المتصفح وقم بزيارة عدة مواقع. قد يبدو رأس الاستجابة كالتالي:
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:* https://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:* https://fb.scanandcleanlocal.com:* *.atlassolutions.com attachment.fbsbx.com ws://localhost:* blob: *.cdninstagram.com 'self' chrome-extension://boadgeojelhgndaghljhdicfkmllpafd chrome-extension://dliochdbjfkdbacpmhlcpmleaejidimm;
خذ بعين الاعتبار توجيهات CSP المعروضة هنا:
default-src - يحظر كل ما لم يتم تعيينه بشكل صريح.script-src - يقدم قيودًا على البرامج النصية القابلة للتنزيل.style-src - تفرض قيودًا على أوراق الأنماط المحملة.connect-src - يقدم قيودًا على عناوين URL التي يمكن تحميل الموارد منها باستخدام واجهات البرمجة النصية ، مثل fetch و XHR و ajax وما إلى ذلك.
لاحظ أنه في الواقع ، هناك العديد من هذه التوجيهات. يقرأ المتصفح رأس CSP ويطبق القواعد المناسبة داخل ملف HTML الذي تم تحميله. تسمح التوجيهات التي تم تكوينها بشكل صحيح فقط بالإجراءات الضرورية للتشغيل الصحيح للصفحة.
إذا كانت الصفحة لا تحتوي على رأس CSP ، فلن يتم تطبيق أي حظر عليها. الأحرف * في رأس CSP هي أحرف بدل. يمكن استبدال هذه العلامة بأي شيء ، وما سيحدث سيسمح به.
▍HTTPS
بالتأكيد سمعت عن HTTPS (HTTP Secure). ربما صادفت شيئًا مثل هذا: "لماذا يجب أن أقلق بشأن HTTPS إذا كنت ألعب لعبة على الموقع؟" أو ربما توصلت إلى الفكرة التالية: "إذا لم يكن لديك HTTPS ، فهذا جنون. في الفناء 2018 سنة! لا تصدق أي شخص يقول HTTPS يمكن الاستغناء عنه. "
ربما سمعت أن Chrome يصنف الموقع الآن على أنه غير آمن إذا لم يكن يستخدم HTTPS.
الفرق الرئيسي بين HTTPS و HTTP هو أنه عند نقل البيانات عبر HTTPS ، يتم تشفيرها ، ولكن عند الإرسال عبر HTTP ، لا يتم تشفيرها.
لماذا يجدر الانتباه عند نقل البيانات القيمة؟ الشيء هو أنه عند تنظيم تبادل البيانات عبر قناة اتصال غير آمنة ، هناك احتمال لهجوم MITM (رجل في الوسط ، هجوم وسيط ، أو رجل في الهجوم الأوسط).
إذا كنت ، وأنت جالسًا في مقهى ، يمكنك الوصول إلى الإنترنت من خلال نقطة وصول Wi-Fi مفتوحة ، يمكن لشخص ما ببساطة أن يتظاهر بأنه جهاز توجيه تمر من خلاله جميع طلباتك وإجاباتك. إذا لم يتم تشفير بياناتك ، فيمكن للوسيط أن يفعل بها ما يشاء. لنفترض أنه يمكنه تعديل كود HTML أو CSS أو JavaScript قبل وصوله من الخادم في متصفحك. بالنظر إلى ما نعرفه بالفعل عن هجمات XSS ، يمكنك أن تتخيل العواقب.
"كيف هذا ممكن: يعرف جهاز الكمبيوتر الخاص بي والخادم كيفية تشفير وفك تشفير البيانات التي نتبادلها ، لكن الوسيط الضار لا يفعل ذلك؟" ، تسأل. هذا ممكن بفضل استخدام بروتوكول SSL (طبقة المقابس الآمنة) وبروتوكول TLS (أمان طبقة النقل) الأحدث. حل TLS محل طبقة المقابس الآمنة (SSL) في عام 1999 باعتباره تقنية التشفير المستخدمة في HTTPS. مناقشة ميزات TLS خارج نطاق هذه المقالة.
▍HSTS
تقنية HSTS (HTTP Strict-Transport-Security ، آلية التنشيط القسري لاتصال آمن عبر بروتوكول HTTPS) بسيطة للغاية. كمثال ، ضع في اعتبارك رأس Facebook المقابل مرة أخرى:
strict-transport-security: max-age=15552000; preload
دعونا نحللها:
- يحدد
max-age الوقت الذي يجب أن يجبر فيه المتصفح المستخدم على العمل مع موقع الويب عبر HTTPS. preload - لأغراضنا هذه ليست مهمة.
ينطبق هذا الرأس فقط إذا كنت تدخل إلى الموقع باستخدام HTTPS. إذا كنت تعمل مع الموقع عبر HTTP ، فسيتم تجاهل هذا الرأس. والسبب في ذلك بسيط للغاية: اتصال HTTP ضعيف جدًا لدرجة أنه لا يمكن الوثوق بمثل هذا الرأس.
دعنا نستخدم مثال Facebook مرة أخرى لإثبات الفائدة العملية لآلية HSTS. افترض أنك قمت بتسجيل الدخول إلى facebook.com لأول مرة وتعلم أن HTTPS أكثر أمانًا من HTTP ، لذلك يمكنك استخدام هذا الرابط:
https://facebook.com . عندما يتلقى متصفحك شفرة HTML ، فإنه يتلقى أيضًا رأسًا يخبر المتصفح أنه يجب أن يجبرك على التبديل إلى HTTPS عند تقديم الطلبات المستقبلية. بعد شهر ، يرسل لك شخص رابط HTTP إلى Facebook ،
http://facebook.com ،
http://facebook.com عليه. نظرًا لأن الشهر أقل من فترة 15552000 ثانية محددة بواسطة توجيه
max-age ، سيرسل المتصفح طلبًا عبر HTTPS ، مما يمنع هجوم MITM محتمل.
الملخص
ناقشنا اليوم بعض التقنيات المستخدمة عالميًا لضمان أمان مشاريع الويب. نحن نؤمن بأن مشكلات الأمان مهمة جدًا ، لأنها تتعلق تمامًا بكل شخص متصل بالإنترنت. إن موضوع أمان الويب ضخم ، لذا لا يمكنك القول أنه بعد قراءة عدة مقالات ، سيصبح شخص ما خبيرًا في هذا المجال أو على الأقل يتعلم بما يكفي لحماية مشروع الويب أو بياناتك الشخصية بشكل فعال. ولكن ، كما هو الحال في أي مجال آخر ، تتراكم المعرفة في مجال الأمن ، إذا كانت هناك رغبة في الحصول عليها ، وتتحول كميتها تدريجياً إلى نوعية. نأمل أن تكون هذه المادة قد أسهمت في معرفتك بأمان الويب.
أعزائي القراء! هل واجهت مخاوف أمنية غير متناسقة من مطوري الويب؟
