المدخلات والمخرجات
الضعف الأمني الأكثر شيوعا للتطبيقات الحالية هو الفشل في معالجة البيانات التي يتم تلقيها من مصادر خارجية بشكل صحيح، خاصة إدخال المستخدم. يجب عليك دائمًا إلقاء نظرة فاحصة على أي إدخال للتأكد من صحته قبل استخدامه. يمكن أن يؤدي الفشل في تحليل مدخلات المستخدم للهجمات المحتملة إلى فقدان البيانات أو الكشف عنها، أو رفع الامتياز، أو حتى تنفيذ تعليمات برمجية ضارة على أجهزة الكمبيوتر الخاصة بالمستخدمين الآخرين.
المأساة في هذا الوضع هو أن هذا السيناريو مشكلة سهلة الحل. في هذه الوحدة، سنغطي كيفية التعامل مع البيانات عند تلقيها، ومتى يتم عرضها على الشاشة، ومتى يتم تخزينها لاستخدامها لاحقا.
لماذا نحتاج إلى التحقق من صحة مدخلاتنا؟
تخيل أنك تقوم بإنشاء واجهة للسماح للمستخدم بإنشاء حساب على موقع الويب الخاص بك. تتضمن بيانات ملف التعريف الخاصة بنا اسما وبريدا إلكترونيا واسما كنيا سنعرضه لكل شخص يزور الموقع. ماذا لو قام مستخدم جديد بإنشاء ملف تعريف وإدخال كنية تتضمن بعض أوامر SQL؟ على سبيل المثال، ماذا لو أدخل مستخدم ضار شيئا مثل المقتطف التالي:
Eve'); DROP TABLE Users;--
إذا قمنا بإدراج هذه القيمة بشكل عشوائي في قاعدة بيانات، فمن المحتمل أن تغير عبارة SQL لتنفيذ الأوامر نحن لا نريد تشغيلها بالتأكيد! يشار إلى هذا المثال باسم هجوم "حقن SQL"، وهو أحد أنواع الاستغلال العديدة التي يمكن القيام بها عندما لا تتعامل مع إدخال المستخدم بشكل صحيح. لذا، ماذا يمكننا أن نفعل لإصلاح هذا الموقف؟ سوف تعلمك هذه الوحدة متى يتعين عليك التحقق من صحة المدخلات، وكيفية ترميز المخرجات، وكيفية إنشاء الاستعلامات ذات معلمات (التي تحل الهجمة المذكورة أعلاه). هذه التقنيات هي تقنيات الدفاع الرئيسية الثلاث ضد إدخال ضار يتم إدخاله في التطبيقات الخاصة بك.
متى أحتاج إلى التحقق من صحة الإدخال؟
الجواب هو دائما. يجب التحقق من صحة كل إدخال للتطبيق الخاص بك. يتضمن ذلك المعلمات في عنوان URL، والإدخل من المستخدم، والبيانات من قاعدة البيانات، والبيانات من واجهة برمجة التطبيقات، وأي شيء يتم تمريره بوضوح يمكن للمستخدم معالجته. استخدم دائما نهج قائمة السماح، ما يعني أنك تقبل فقط إدخال "جيد معروف"، بدلا من قائمة حظر (حيث تبحث عن إدخال غير صالح على وجه التحديد) لأنه من المستحيل التفكير في قائمة كاملة من الإدخالات التي يحتمل أن تكون خطيرة. قم بهذا العمل على الخادم، وليس من جانب العميل (أو بالإضافة إلى جانب العميل)، للتأكد من أنه لا يمكن التحايل على دفاعاتك. تعامل مع جميع البيانات على أنها غير موثوق بها، وستحمي نفسك من معظم نقاط الضعف الشائعة في تطبيق الويب.
إذا كنت تستخدم ASP.NET، يوفر إطار العمل دعما كبيرا للتحقق من صحة الإدخال على جانب العميل والخادم.
إذا كنت تستخدم إطار عمل ويب آخر، فهناك بعض التقنيات الرائعة لإجراء التحقق من صحة الإدخال المتوفرة في ورقة المعلومات المرجعية للتحقق من صحة إدخال OWASP.
استخدم الاستعلامات ذات المعلمات دائمًا
تستخدم قواعد بيانات SQL عادة لتخزين البيانات؛ على سبيل المثال، يمكن لتطبيقك تخزين معلومات ملف تعريف المستخدم في قاعدة بيانات. يجب عدم إنشاء SQL مضمن أو استعلامات قاعدة بيانات أخرى في التعليمات البرمجية الخاصة بك باستخدام إدخال المستخدم البسيط وإرساله مباشرة إلى قاعدة البيانات؛ هذا السلوك هو وصفة لكارثة، كما رأينا سابقا.
على سبيل المثال، لا تنشئ تعليمة برمجية مثل مثال SQL المضمن التالي:
string userName = Request.QueryString["username"]; // receive input from the user BEWARE!
...
string query = "SELECT * FROM [dbo].[users] WHERE userName = '" + userName + "'";
في هذا المثال، نُسلسل سلاسل نصية معًا لإنشاء الاستعلام، بأخذ الإدخال من المستخدم وإنشاء استعلام SQL ديناميكية للبحث عن المستخدم. مرة أخرى، إذا أدرك مستخدم ضار أننا نقوم بذلك، أو حاول للتو أنماط إدخال مختلفة لمعرفة ما إذا كانت هناك ثغرة أمنية، فقد ينتهي الأمر بكارثة كبيرة. بدلاً من ذلك، استخدم عبارات SQL ذات المعلمات أو الإجراءات المخزنة مثل هذا:
-- Lookup a user
CREATE PROCEDURE sp_findUser
(
@UserName varchar(50)
)
SELECT * FROM [dbo].[users] WHERE userName = @UserName
باستخدام هذا الأسلوب، يمكنك استدعاء الإجراء من التعليمات البرمجية الخاصة بك بأمان، وتمرير السلسلة userName دون القلق بشأن معاملتها كجزء من عبارة SQL.
شفّر المخرجات دائمًا
يجب أن يكون أي إخراج تعرضه سواءً بصريًا أو داخل وثيقة مشفرًا وتم تجاوزه. يمكن أن يحميك هذا في حالة فقد شيء ما في تصريح التعقيم أو أن التعليمات البرمجية تنشئ عن طريق الخطأ شيئا يمكن استخدامه بشكل ضار. سيتأكد مبدأ التصميم هذا من عرض كل شيء كمخرجات وعدم تفسيره عن غير قصد على أنه شيء يجب تنفيذه، وهو أسلوب هجوم شائع آخر يشار إليه باسم "البرمجة النصية عبر المواقع" (XSS).
نظرًا إلى أن منع XSS هو مطلب تطبيق شائع، فإن تقنية الأمان هذه هي مجال آخر حيث سيقوم ASP.NET بالعمل نيابة عنك. بشكل افتراضي، يتم ترميز كافة المُخرجات بالفعل. إذا كنت تستخدم إطار عمل ويب آخر، يمكنك التحقق من خيارات ترميز الإخراج على مواقع الويب باستخدام OWASP XSS Prevention Cheatsheet.
الملخص
يعد تعقيم الإدخال والتحقق منه مطلبًا ضروريًا لضمان صلاحية الإدخال وأمان الاستخدام والتخزين. تقدم معظم أطر العمل الحديثة على شبكة الإنترنت ميزات مدمجة يمكنها أتمتة بعضًا من هذا العمل. يمكنك التحقق من وثائق إطار العمل المفضل لديك ومعرفة الميزات التي يوفرها. في حين أن تطبيقات الويب هي المكان الأكثر شيوعًا لحدوث هذا، فإنه عليك أن تضع في اعتبارك أن الأنواع الأخرى من التطبيقات يمكن أن تكون عرضة للخطر. لا تعتقد أنك آمن فقط لأن تطبيقك الجديد هو تطبيق لسطح المكتب. ستظل بحاجة إلى معالجة إدخال المستخدم بشكل صحيح لضمان عدم استخدام شخص ما لتطبيقك لإفساد بياناتك أو الإضرار بسمعة شركتك.