مقدمة
في نموذج تطوير الفصل بين الواجهة الأمامية والخلفية ، فإن التغيير الأكثر وضوحًا من حيث أدوار ووظائف التطوير هو: في الماضي ، كان الطلاب الأماميون المسؤولون فقط عن التطوير في بيئة المتصفح اللازمة لاستكشاف مستوى نهاية خادم وكتابة رمز خادم الخادم. والسؤال الأساسي أمامنا هو كيفية ضمان أمان الويب؟
تقترح هذه المقالة حلولًا لمشاكل الأمان التي يواجهها وضع الفصل الأمامي والخلفي في تطوير الويب من الواجهة الأمامية ، وكذلك التدابير المضادة والاحتياطات.
الدفاع عن هجوم البرمجة النصية عبر المواقع (XSS)
المشاكل والحلول
تعد البرمجة النصية عبر المواقع (XSS ، البرمجة النصية عبر المواقع) الطريقة الأكثر شيوعًا والأساسي لمهاجمة مواقع الويب. يمكن للمهاجم نشر بيانات تحتوي على رمز مسيء على صفحة ويب. عندما يرى المتصفح صفحة الويب هذه ، سيتم تنفيذ برنامج نصي محدد كهوية وأذونات مستخدم المتصفح. يمكن تعديل XSS بسهولة أكبر ، وسرقة بيانات المستخدم ، ومعلومات المستخدم والتسبب في أنواع أخرى من الهجمات ، مثل هجمات CSRF.
تتمثل الطريقة الأساسية لمنع هجمات XSS في التأكد من هروب أي إخراج بيانات إلى صفحة HTML في HTML (HTML Escape). على سبيل المثال ، رمز القالب التالي:
نسخة الكود كما يلي:
<textarea name = "description"> $ الوصف </textarea>
وصف $ في هذا الرمز هو متغير للقالب (بناء جملة المتغيرات المحددة في قوالب مختلفة مختلفة ، إليك مجرد رسم بياني). يمكن للبيانات المقدمة من المستخدم إدخال جزء من الرمز الذي يحتوي على "javaScript" لإصدار نتيجة بيان القالب أعلاه تصبح النتيجة التالية:
نسخة الكود كما يلي:
<textarea name = "description">
</dextarea> <script> ALERT ('Hello') '</script>
</textarea>
سيتم تنفيذ الكود أعلاه ، المقدم في المتصفح ، رمز JavaScript وينبه على الشاشة. بالطبع ، هذا الرمز غير ضار ، ولكن يمكن للمهاجم إنشاء JavaScript لتعديل معلومات المستخدم أو سرقة بيانات ملفات تعريف الارتباط.
الحل بسيط للغاية ، وهو HTML الهروب من قيمة وصف $. رمز الإخراج بعد الهروب كما يلي
نسخة الكود كما يلي:
<textarea name = "description">
</dextarea> <script> ALERT (Hello!) </script>
</textarea>
رمز HTML النار أعلاه ليس ضارًا.
حل منتصف الطريق
الهروب من جميع بيانات إخراج المستخدم في الصفحة
هناك العديد من المواقف وطرق الهروب من البيانات:
1. الهروب باستخدام الآلية المقدمة داخل القالب
يستخدم Midway Quicy xtemplate كلغة القالب.
في تنفيذ XtEmplate ، يتم تحليل بيانات القالب باستخدام قوسين ({{val}}). بشكل افتراضي ، تم هروب البيانات HTML ، بحيث يمكن للمطورين كتابة قوالب مثل هذا:
نسخة الكود كما يلي:
<textarea name = "description"> {{description}} </textarea>
في xtemplate ، إذا كنت لا تريد الهروب من بيانات الإخراج ، فأنت بحاجة إلى استخدام ثلاثة قوسين ({{val}}}).
2. استدعاء وظائف الهروب بشكل لا لبس فيه في منتصف الطريق
يمكن للمطورين استدعاء طريقة HTML Escape مباشرة التي توفرها Midway في برنامج Node.js أو قالب للهروب من البيانات المعروضة ، على النحو التالي:
الطريقة 1: HTML Escape Data في برنامج Node.js
نسخة الكود كما يلي:
var security = require ('midway-security') ؛
// بيانات من الخادم ، على سبيل المثال {html: '</textarea>' ، والآخر: ""}
data.html = security.escapehtml (data.html) ؛
xtpl = xtpl.render (data) ؛
الطريقة 2: بيانات HTML Escape HTML في القالب
نسخة الكود كما يلي:
<textarea name = "description"> security.escapehtml ({{{description}}}) </swertarea>
ملاحظة: يتم استخدام Security.escapehtml للهروب فقط عندما لا يتم هروب البيانات داخل القالب. خلاف ذلك ، فإن القالب الداخلي والبرنامج سوف يهرب من التراكب مرتين ، مما يؤدي إلى إخراج لا يفي بالتوقعات.
الموصى به: إذا كنت تستخدم Xtemplate ، فمن المستحسن استخدام {{}} من القالب للهروب مباشرة ؛ إذا كنت تستخدم قوالب أخرى ، فمن المستحسن استخدام الأمان. SESCAPEHTML للهروب.
تصفية إخراج النص الغني من المستخدمين على الصفحة
قد تفكر: "في الواقع ، أريد فقط إخراج نص غني ، مثل بعض لوحات الرسائل والمنتديات لتزويد المستخدمين ببعض حجم الخطوط واللون والخلفية وغيرها من الوظائف. فكيف يجب أن أتعامل مع مثل هذا النص الغني لمنع XSS؟"
1. استخدم وظيفة RichText التي توفرها الأمان في منتصف الطريق
يوفر Midway طريقة RichText ، والتي تُستخدم خصيصًا لتصفية النص الغني ومنع نقاط الضعف مثل XSS ، والتصيد ، وسرقة ملفات تعريف الارتباط.
هناك لوحة رسائل ، وقد يكون رمز القالب كما يلي:
نسخة الكود كما يلي:
<viv>
{{{رسالة}}}
</div>
نظرًا لأن الرسالة هي بيانات إدخال المستخدم ، فإن محتوى لوحة الرسائل الخاصة به يحتوي على معلومات نصية غنية ، وهنا يتم استخدام ثلاثة أقواس في Xtemplate ، ولا يتم تنفيذ HTML Escapes افتراضيًا ؛ ثم البيانات التي أدخلها المستخدم كما يلي:
نسخة الكود كما يلي:
<script src = "http://eval.com/eval.js"> </script> <span style = "color: Red ؛ font-size: 20px ؛ الموضع: ثابت ؛"> سأترك رسالة </span>
إذا تم إخراج البيانات النصية الغنية أعلاه مباشرة إلى الصفحة ، فستؤدي حتماً إلى حقن JS من موقع eval.com إلى الصفحة الحالية ، مما تسبب في هجوم XSS. لمنع هذه الثغرة الأمنية ، نستدعي فقط طريقة security.richtext في القالب أو البرنامج لمعالجة إدخال النص الغني من قبل المستخدم.
تشبه طريقة الاتصال بـ EscapeHTML ، وهناك طريقتان لذلك
الطريقة 1: اتصل مباشرة في برنامج Node.js
نسخة الكود كما يلي:
message = security.richtext (message) ؛
var html = xtpl.render (رسالة)
الطريقة 2: اتصل في القالب
نسخة الكود كما يلي:
<viv>
security.richtext ({{{message}}})
</div>
بعد استدعاء طريقة الأمن RichText ، يكون الإخراج النهائي كما يلي:
نسخة الكود كما يلي:
<viv>
<span style = "اللون: أحمر ؛ حجم الخط: 20 بكسل ؛"> سأترك رسالة </span>
</div>
يمكن ملاحظة ذلك أولاً: سيتم ترشيح علامة البرنامج النصي التي ستتسبب في هجمات XSS مباشرة ؛ في الوقت نفسه ، موضع سمة CSS: ثابت ؛ يتم تصفية النمط في علامة النمط أيضًا. أخيرًا ، يتم إخراج النص HTML Rich
تعرف على طرق أخرى لإعادة هجمات XSS
بالإضافة إلى هجوم XSS المحتمل في قالب الصفحة ، هناك العديد من الطرق الأخرى في تطبيقات الويب التي قد تكون محفوفة بالمخاطر.
1. الضعف في صفحة الخطأ
إذا تعذر العثور على صفحة ، فقد يقوم النظام بالإبلاغ عن خطأ 404 غير موجود ، على سبيل المثال: http: // localhost/page/not/found
404 Notfound
الصفحة/الصفحة/لا/تم العثور عليها لا exsit
من الواضح: يمكن للمهاجم استخدام هذه الصفحة لإنشاء اتصال مثل هذا ، http: // localhost/٪ 3cscript ٪ 3ealert ٪ 28 ٪ 27hello ٪ 27 ٪ 29 ٪ 3C ٪ 2fscript ٪ 3e ، وجذب الضحية للنقر ؛ إذا لم تفلت صفحة الخطأ من متغير الإخراج ، فسيتم تنفيذ <script> Alert ('hello') </script> المخفية في الاتصال.
في Express ، طريقة إرسال صفحة 404 هي كما يلي
Res.Send (404 ، "آسف ، لا نجد ذلك!")
هنا ، يحتاج المطورون إلى الانتباه إلى معالجة صفحة الخطأ (404 أو حالة خطأ أخرى). إذا كان محتوى الإرجاع لرسالة الخطأ يحتوي على معلومات المسار (في الواقع ، لتكون أكثر دقة ، معلومات إدخال المستخدم) ، يجب عليك تنفيذ EscapeHTML.
بعد ذلك ، سيتم الانتهاء من آلية الأمان للتعامل مع الأخطاء على مستوى إطار Midway.
ملاحظات إضافية لحلول Midway
محركات النماذج الأخرى
يدعم Midway قوالب Xtemplate بشكل افتراضي ، ولكنها قد تدعم أيضًا قوالب أخرى في المستقبل: مثل Jade و Matache و EJS ، إلخ.
دعم آخر للهروب
بالإضافة إلى إخراج البيانات النصية العادية والغنية على الصفحة ، تتضمن بعض السيناريوهات أيضًا مواقف أخرى قد تتطلب الهروب. يوفر Midway أساليب الهروب الشائعة الاستخدام للمطورين لاستخدامها:
EscapeHTML تقوم بتصفية الأحرف في HTML المحددة لمنع نقاط الضعف XSS
JSencode JavaScript الهروب من سلاسل المدخلات. يونيكود الهروب من الصينية ، اقتباسات واحدة ، ونقلت مزدوجة الهروب
EscapeJson لا يدمر وظيفة الهروب لهيكل JSON ، ولا يؤدي سوى معالجة EscapeHTML على الاسم و Vaule في بنية JSON
EscapeJsonforjsvar هو Jsencode+EscapeJson بشكل مفهوم
الأمثلة على النحو التالي
نسخة الكود كما يلي:
var jsontext = "{/" <script>/":/" <script>/"}" ؛
console.log (securityutil.escapejson (jsontext)) ؛ // {"<script>": "<script>"}
var jsontext = "{/" hello/":/" <script>/"}" ؛
console.log (securityutil.escapejsonforjsvar (jsontext)) ؛ // {/"/u4f60/u597d/":/"<script>/"}
var str = "Alert (/" hello/")" ؛
console.log (securityutil.jsencode (str)) ؛ // Alert (/"/u4f60/u597d/")
الوقاية من هجوم التزوير عبر المواقع (CSRF)
المشاكل والحلول
تعريف المصطلحات: النموذج: يشير بشكل عام إلى النموذج المستخدم من قبل المتصفح لتقديم البيانات على العميل ؛ بما في ذلك علامة ، بيانات تقديم AJAX ، بيانات تقديم النموذج ، إلخ ، بدلاً من علامات النموذج المساوية لـ HTML.
يعد التزوير عبر المواقع (CSRF ، تزوير طلب المواقع) هجومًا مشتركًا آخر. قام المهاجم بتقديم طلب من خلال طرق مختلفة وقام بتقليد سلوك المستخدم لتقديم النماذج ، وبالتالي تحقيق الغرض من تعديل بيانات المستخدم أو تنفيذ مهام محددة.
من أجل التظاهر بأنه مستخدم ، غالبًا ما يتم دمج هجمات CSRF مع هجمات XSS ، ولكن يمكن استخدام وسائل أخرى: على سبيل المثال ، لحث المستخدمين على النقر على رابط يحتوي على الهجوم.
تنقسم فكرة حل هجمات CSRF إلى خطوتين.
1. زيادة صعوبة الهجوم. الحصول على الطلبات سهلة الإنشاء. يمكن للمستخدمين بدء طلبات Get-Type بالنقر فوق رابط. طلبات النشر صعبة نسبيا. غالبًا ما يحتاج المهاجمون إلى استخدام JavaScript لتنفيذها. لذلك ، فإن التأكد من أن نماذج النماذج أو واجهات الخادم تقبل فقط طلبات تقديم ما بعد النوع يمكن أن تزيد من أمان النظام.
2. مصادقة طلب التأكد من أن الطلب قد تم ملء النموذج بالفعل أو بدء الطلب وتقديمه من قبل المستخدم ، بدلاً من أن يزوره طرف ثالث.
عملية تعديل المستخدم العادي تعديل الموقع هي كما يلي
طلبات المستخدم لتعديل المعلومات (1) -> يعرض موقع الويب نموذج المعلومات المعدلة للمستخدم (2) -> معلومات تعديل المستخدم ويخضع (3) -> يقبل موقع الويب بيانات وحفظ المستخدم (4)
لن يأخذ هجوم CSRF هذا المسار ، ولكنه سيؤدي مباشرة إلى وضع معلومات تقديم المستخدم في الخطوة 2.
تخطي مباشرة إلى الخطوة 2 (1) -> صياغة المعلومات المراد تعديلها وإرسالها (2) -> يقبل الموقع المهاجم لتعديل بيانات المعلمة وحفظ (3)
طالما أنه يمكن تمييز هاتين الموقفين ، يمكن منع هجمات CSRF. فكيف تميزه؟ هو التحقق من المعلومات المقدمة في الخطوة 2 للتأكد من أن البيانات تأتي من النموذج في الخطوة 1. عملية التحقق المحددة هي كما يلي:
طلبات المستخدم لتعديل المعلومات (1) -> يعرض الموقع نموذجًا فارغًا يستخدم لتعديل المعلومات. يحتوي النموذج على رمز خاص ويحفظ الرمز المميز في الجلسة (2) -> يقوم المستخدم بتعديل المعلومات ويقدمها ، ويرسل معلومات الرمز المميز إلى الخادم (3) -> يقارن موقع الويب الرمز المميز الذي أرسله المستخدم والرمز المميز في الجلسة. يجب أن تكون متسقة. ثم يتم قبول البيانات التي تم تعديلها بواسطة المستخدم وحفظها.
وبهذه الطريقة ، إذا قام المهاجم بتزوير المعلومات التي سيتم تعديلها وتقديمها ، فلن يتمكن من الوصول مباشرة إلى الجلسة ، لذلك لن يتمكن من الحصول على قيمة الرمز المميز الفعلي ؛ إذا تم إرسال الطلب إلى الخادم ، عندما قام الخادم بإجراء التحقق من الرمز المميز ، فسيتم العثور على أنه غير متسق ، وتم رفض الطلب مباشرة.
حلول Midway
تعطيل الحصول على نموذج التقديم
إذا لم يقبل الخادم بيانات النموذج المقدمة عن طريق GET ، فسوف يتسبب ذلك في صعوبة كبيرة للمهاجم ؛ نظرًا لأنه من السهل جدًا إنشاء سمة HREF A-Label أو سمة SRC IMG-LABEL على الصفحة لإنشاء طلب ، ولكن إذا كنت ترغب في إرساله ، فيجب عليك استخدام برنامج نصي لتنفيذه.
تحقق من الطلبات باستخدام رمز CSRF
نظرًا لأن Midway لا يتضمن منطق جلسة Taobao الموزعة والتحقق من الرمز المميز ، في إطار Midway ، يتم إعادة توجيه الرموز المميزة فقط بين الخادم والعميل ، ولا تقوم بعمل التحقق الفعلي. العملية كما يلي:
بعد ذلك: في منتصف الطريق ، بعد أن يتم توصيل الجلسة الموزعة لـ Node.js و Taobao ، يمكنك التفكير تلقائيًا في إجراء التحقق الرمزي في طبقة منتصف الطريق ؛ بعد كل شيء ، يتم إجراء التحقق الأمني في وقت مبكر ، كلما انخفض التكلفة.
اقتراح: في منتصف الطريق ، يمكنك تحديد ما إذا كانت هناك قيمة رمزية في الطلب. إذا لم يكن لعملية التعديل رمزًا ، فيمكنك النظر مباشرة في طبقة منتصف الطريق لتكون غير آمنة وتجاهل الطلب.
قضايا أمنية أخرى
هناك العديد من مشكلات أمان الويب الشائعة. فيما يلي بعض المقدمات وسيستمر ورثها في إطار منتصف الطريق في المستقبل.
HTTP رؤوس الأمن
يجد المهاجمون في حقن CRLF طرقًا لحقن شخصين خاصين CRLF في رأس الاستجابة ، مما يؤدي إلى تنسيق بيانات استجابة استثنائي ، وبالتالي حقن البرنامج النصي ، إلخ.
تم رفض الهجمات التي تم الوصول إليها من الوصول إلى كل طلب لأن ملفات تعريف الارتباط يتم إحضارها افتراضيًا ، ويحد الخادم عمومًا من حجم ملفات تعريف الارتباط ، مما يؤدي إلى ذلك إذا تم تعيين ملفات تعريف الارتباط لعميل المستخدم لتجاوز عتبة معينة ، فلن يتمكن المستخدم من الوصول إلى موقع الويب.
الوقاية من ملفات تعريف الارتباط والتحكم فيها ، يتم الحصول على سرقة ملفات تعريف الارتباط العامة من خلال JavaScript)
فيما يتعلق بقضايا أمان ملفات تعريف الارتباط ، كان لدى WebX بالفعل حلًا جيدًا من قبل ؛ هذه المرة في منتصف الطريق ليست مسؤولة عن إعداد ملفات تعريف الارتباط والتحقق منها ، وهو مسؤول فقط عن إعادة توجيه مستوى الويب للتحقق.
حول node.js
تعتبر نقاط الضعف عن طريق الحقن مثل XSS هي الأسهل التي يتم تجاهلها بين جميع نقاط الضعف ، حيث تمثل أكثر من 70 ٪ من إجمالي هجمات الإنترنت ؛ عند كتابة رمز Node.js ، يجب على المطورين دائمًا تذكير أنفسهم ولا يثقون أبدًا في مدخلات المستخدمين.
على سبيل المثال ، الأمثلة التالية.
var mod = fs.readfilesync ('path') ؛ إذا كان المسار يأتي من إدخال المستخدم ، في افتراض أن المستخدم يدخل /إلخ /كلمة المرور ، فسيتم قراءة المحتوى الذي لا ينبغي قراءته ، مما يتسبب في خطر تسرب كلمة المرور
var result = eval (jsonval) ؛ تأكد من التأكد من أن Jsonval هو JSON ، وليس إدخال المستخدم
... في أماكن أخرى قد تحتوي على إدخال المستخدم ، تأكد من تأكيد أن إدخال المستخدم هو القيمة التي نتوقعها.
لخص
في وضع الفصل بين الواجهة الأمامية والخلفية ، يمكن للمطورين التقليديين في الواجهة التقليدية البدء في كتابة التعليمات البرمجية الخلفية. على الرغم من أن الهندسة المعمارية مسؤولة فقط عن طبقة القالب ، إلا أنها ستتعرض أيضًا لكمية كبيرة من الكود الخلفي ؛ لذلك ، يمثل الأمن تحديًا كبيرًا للواجهة الأمامية.