The Fundamental Cause of Injection Attacks

ثغرات الـ Injection Attack  والعوامل المشتركة بين هذا النوع من الثغرات

 

·      أمور يجب عليك معرفتها مُسبقًا قبل قراءة هذه المقالة:

o     ماهو الـ Parser: تجد الإجابة باللغة العربية هنا

o     ماهي ثغرات الـ Injection Attack: تجد الإجابة باللغة العربية هنا (SQLi & XSS) ، وهنا (Buffer Overflow) ، وهنا ( OS Command Injection )

·      الزبدة للمستعجلين:

o     إذا لم يقم المُبرمج بوضع قيود على مُدخلات المستخدمين لمنعها من أن تأتي على شكل كود برمجي سيتم الخَلط بين مُدخلات المستخدمين و الكود البرمجي وسيعبران كـ جزءًا واحدًا الى الـ Parser والذي سيقوم بدوره بتنفيـذ هذا الجزء أيًا كان. ومن هذه النقطة تحديدًا تبدأ تحدث العديد من ثغرات الـ Injection Attack!

 

السلام عليكم ورحمة الله وبركاته،

 

 ذكر Wenliang  صاحب كتاب: Computer Security - A hands-on Approach

أن خلط مُدخلات المستخدمين مع الكود البرمجي هي السبب في حدوث الكثير من ثغرات الـ Injection Attack

·      ماذا نقصد بثغرات الـ Injection Attack؟ نقصد أحد هذه الثغرات:

o     SQL Injection

o     XSS

o     Command Injection

o     Format String Vulnerability

o     Buffer Overflow Vulnerability

·      ماذا نقصد بـ مُدخلات المستخدمين ؟

o     هي البيانات التي يقوم المستخدم بتزويد البرنامج بها.

 

الرسم الآتي يُلخّص كيف تحدث مختلف هذه الأنواع من الثغرات

 

 

 

 

 

 

 

 

 

 

 

 

 

 

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

العامل المشترك الأول (رقم ١ في الرسم): كل هذه الثغرات تقوم بخلط نوعين من البيانات

·      النوع الأول من البيانات هو الـ Untrusted User Data:

o     وهي البيانات التي يستقبلها البرنامج من المستخدم ويجري عليها بعض العمليات حسب طبيعة البرنامج، نصنّف هذا النّوع من البيانات بـ بيانات غير موثوقة.

·      النوع الثاني من البيانات هو الـ Trusted Code:

o     وهو الكود البرمجي الخاص بالبرنامج، وهذا النوع من البيانات موثوق، لأنه قادم من المُبرمج نفسه.

قبل أن يتم الخَلط (سنعرف لاحقًا ما المقصود بالخلط وأين يحدث تحديدًا؟) بين هذين النوعين من البيانات، المُبرمج على دراية بالحدود أو ما يُسمى بالـ Boundaries  بين هذين النوعين، بعد أن يتم الخَلط بين هذين النوعين ستختفي الحدود أو الـ Boundaries بينهما.

مثال في حالة الـ SQL Injection:

قبل الخوض في تفاصيل المثال، دعونا ننسى التصنيف السابق الذي قمنا بإعطائه لبيانات المستخدم، ونبدأ بالتحليل حتى نصل لسبب تصنيفها بـ بيانات غير موثوقة

نعود للمثال الخاص بثغرات الـSQL Injection ، المُبرمج عندما يقوم ببناء التّعليمة التي يتم إرسالها لقاعدة البياناتSQL Statement  يعلم أين سيتم إدراج بيانات المستخدم في هذه التعليمة، (بتفصيل أكثر: يعلم المُتغير الذي يحمل بيانات المستخدم)، بعدما يستقبل البرنامج بيانات المستخدم سيقوم بإدراجها ضمن التعليمة التي ستُرسَل لقاعدة البيانات، ولنتوقف هنا لدقائق ونقوم بتحليل هذه العملية:

·      الحالة الأولى: بيانات المستخدم جاءت كما يُفترض منها أن تكون (اسم المستخدم، كلمة المرور، ... إلخ)

·      الحالة الثانية: بيانات المستخدم تحمل Keywords  خاصة باللغة البرمجية أو كود برمجي

في الحالة الأولى، لا يوجد أي مشاكل ولا زالت الحدود بين مُدخلات المستخدمين مع الكود البرمجي سَليمة.

في الحالة الثانية، اختفت الحدود بين هذين النوعين من البيانات وأصبحت جزءًا واحدًا، وهنا يبدأ يحدث الخَلط (عُد للرسم البياني ولاحظ الرقم ٢ و ٣ )!

 

لننتقل الآن الى إيجاد عامل مشترك آخر بين هذه الثّغرات،

 

·      العامل المشترك الثاني (رقم ٤ في الرسم): مُدخلات المستخدمين و الكود البرمجي (اللذان تم خلطهما وأصبحا جزءًا واحدًا) سيتم إرسالهما إلى الـ Parser  ليقوم بعمله.

نستكمل مثالنا السابق الخاص بالـ SQL Injection ، في هذه الحالة الـ Parser  هنا هو الـ SQL Parser  

لنبدأ الخوض قليلًا في طريقة عمل الـ Parser  بشكل عام (أيًا كان اللغة التي يخدمها)،

الـ Parser  يستقبل في الأساس مُدخلات المستخدمين و الكود البرمجي ، مُدخلات المستخدمين مُخزنة داخل متغيرات، سيقوم الـ Parser بالمرور على الكود البرمجي (الذي يحمل المتغيرات المخزن بها مُدخلات المستخدمين) لتنفيذه، في الحالة الأولى من المثال، لا يوجد أي مشكلة، في الحالة الثانية من المثال ( والتي كانت بها مُدخلات المستخدمين عبارة عن Keywords  خاصة باللغة البرمجية أو كود برمجي ) سيقوم الـ Parser  بعمل تنفيذ أو execute لـ مُدخلات المستخدمين ، لماذا؟ لأن الـ Parser  يراها كـ كود برمجي ولا يُدرك ماهي الحدود بين مُدخلات المستخدمين و الكود البرمجي مثلما يُدركها المُبرمج! بتعبير آخر:

إذا لم يقم المُبرمج بوضع قيود على مُدخلات المستخدمين لمنعها من أن تأتي على شكل كود برمجي

سيتم الخَلط بين مُدخلات المستخدمين و الكود البرمجي وسيعبران كـ جزءًا واحدًا الى الـ Parser والذي سيقوم بدوره بتنفيـذ هذا الجزء أيًا كان.

ومن هذه النقطة تحديدًا تبدأ تحدث العديد من ثغرات الـ Injection Attack !

 

المرجع:

كتاب: Computer Security - A hands-on Approach

فصل: SQL Injection Attack

الموضوع: The Fundamental Cause

صفحة: 194-195