Red-Code
12-12-2003, 11:22
السلام عليكم من جديد ......
هذه هي الحلقه الثلاثه من الهجوم SQL injection واللي ماقرا الموضوعين الاولات لابد يقراهم قبل لايقرا الموضوع هذا |4|
ونبدا بسم الله :
قدمت مجموعه WebCohort لتطوير التطبيقات بحث مثير للاهتمام يركز علي ان الكثير من مطورين
التطبيقات يقعون في خطا حجب رسائل الخطا من قواعد البيانات ويضنون بذلك انهم تمكنوا من حل مشكله
SQL injection بس المشكله ان البحث هذا شرح طريقه كشف الثغره بدون رسائل الخطا من
قواعد البيانات طبعا هم افترضوا ان معلوماتهم صفر عن التطبيق وعن نوع قاعده البيانات وبنيه الجداول لاشي
تعالوا نشوف وش وصلوا له :
مثل ماقلنا عشان يعمل SQL injection يجب ان نحدد ان التطبيق مصاب بالثغره هاذي
وبوضعنا اليوم بدون رسايل خطا هذا يتطلب منا فهم ان التطبيق له حالتين اما يكون الاستعلام والطلب صالحات
او مايكونن
وش نوع رده الفعل من التطبيق اذا حاولت انشاء استعلام SQL عن طريق ادخال عادي
راح تواجه نوعين رئيسيات من الاخطاء من الويب سيرفر والتطبيق :
الاول راح يعطيك
'500: Internal Server Error'او يسويلك ري دايركشن علي الصفحه
الرئيسيه او يعطيك رساله خطا توضحلك ان الادخال خاطي ومن هالكلام
الثاني : راح يكون استجابه من نفس الكود وهذا يدل علي قوه البرمجه يعني يكون التطبيق متوقع انك راح
تختبره بزي هالطرق ويرجعلك رساله انيقه مع استجابه صحيحه 200 من السيرفر .
الان عشان تختبر الثغره لازم تقوم بتقديم مجموعه من الاستعلامات الصالحه ومراقبه كيف يتعامل التطبيق مع
الاخطاء
طيب الان يبد الاختبار :
شيك علي كل بارمتر في الاستعلام للتطبيق بالــSQL keywords مثل Or and
او بالـــMETA characters مثل الفاصله والفاصله المنقوطه وراقب رد فعل التطبيق
والبارمتر اللي يرجع رساله خطا خلي بالك منه يمكن يكون نقطه الضعف اللي تبحث عنها علي العموم ممكن
التطبيق اللي يتعامل مع استثناءات كثيره لابد يكون نسي حاجه ماشيك عليها استعمل intercepting proxy لكشف الريدايركشن علي امل ان يكون الخطا في مكان ما تبعد عنه
طيب الان كيف نحدد ان بارمتر معين معرض للهجوم :
يجب ان نفهم انواع البيانات في SQL وهي عباره عن ثلاث انواع رئيسيه Number,
String , Date كل بارمتر يرسل من التطبيق الي استعلام SQL هو واحد من هذه الثلاث
انواع
فمثلا abc هو String
و 12 هو Number
وغير ذلك Date
الان اذا كان البارمتر رقمي فهو يمرر الي سيرفر SQL زي ماهو بدون فواصل مثل التالي :
SELECT * FROM Products WHERE ProdID = 4
بينما البارمتر الحرفي يمرر محاطا بفواصل الي السيرفر كالتالي :
SELECT * FROM Products WHERE ProdName =
'Book'
سيرفر SQL اصلا مايهتم مدام الاستعلام صالح ويعود بنفس النتيجه اللي عنده
شوف هنا :
myecommercesite/proddetails.asp?ProdID=4
مثلا عشان تختبر البارمتر 4 الطريقه سهله تغير البارمتر
z '4 or 1+3
والزد عشان تظبط الفاصله ولا شيلوها فيصير الاستعلام
SELECT * FROM Products WHERE ProdID = 4'
او
SELECT * FROM Products WHERE ProdID = 3 +
1
الاستعلام الاول قطعا راح يرجع خطا لانه bad SQL syntax
اما الثاني فراح ينفذ بشكل طبيعي وكان البارمتر 4
وهذا يعني ياصدقائي ان هذا البارمتر يمكن تطبيق تقنيات SQL injection عليه
طيب الان خلصنا من البيانات الرقميه نجي علي String وتكمن الصعوبه في السلاسل الحرفيه
بانه تمرر للسيرفر محاطه بالفواصل فاول شي لازم نطلع من الفواصل الشي الثاني ان قواعد البيانات المختلفه
لها طرق مختلفه بدمج السلاسل الحرفيه بس مافيه اشكال ناخذ مثال :
myecommercesite/proddetails.asp?
ProdName=Book
عشان نشوف الوضع هنا نصدر استعلامين :
SELECT * FROM Products WHERE ProdName =
'Book''
SELECT * FROM Products WHERE ProdID = 'B'
+ 'ook'
لاحظوا بالاستعلام الثاني اذا مانجح بدل + حطوا || علشان ممكن السيرفر اوراكل لان علامه الزايد
تدمج المحارف بالاس كيو ال سيرفر و || بالاوراكل
نرجع للاستعلامين الاول راح يرجع خطا bad SQL syntax والثاني راح يضبط كان البارمتر
book وهذا معناته ان الهجوم ممكن تطبيقه
لاحظوا ان اي تعبير expression ممكن تطبيقه لاستبدال البارمتر الرئيسي بقيمه مشابهه له
ايضا هناك بعض الدوال ممكن تعيد لك كل انواع البيانات مثلا بالاوراكل sysdate ترجعلك التاريخ
ونفس الشي SQL Server فيه الداله getdate()
طبعا كان الكلام هذا عشان تثبت ان الهجوم ممكن تطبيقه الان نغوص اكثر
الان عشان نلقي الاستعلام الصحيح اللي نطبق فيه الهجوم يلزمنا الكثير من التجارب بس بشكل عام اذا كان
الاستعلام بسيط راح تلقاه ببساطه اما اذا معقد فراح يعقدك معه
الان يلزمك تجرب SELECT ... WHERE وتحاول تسوي انجكت للبارمتر بعد WHERE
بعض المرات اضافه OR 1=1 راح تكون كافيه لاستثمار الثغره وفي احيان كثيره يلزمك بعض المخمخه
الان بما ان WHERE تعيد ياصح ياخطا كثر من استعمال and or بتركيبات مختلفه يمان تحصل
الاستعلام المناسب جرب 'AND 1=2' اذا كنت تبيه تعيد خطا او 'OR 1=2' اذا تبي
صح وكمان جرب UNION SELECT Injection او stored
procedures injections اللي شرحناهم في الدروس الماضيه
لنفترض انك وجدت الاستعلام المناسب لهجومك الان كيف يمكن ان تعرف نوع قاعده البيانات
Oracle and Microsoft SQL Server
طبعا زي ماشرنا فوق ممكن تفرق بالطريقه اللي تنربط به السلاسل الحرفيه او عن طريق الفاصله المنقوطه
واللي تسمح لكتابه اكثر من امر في سطر واحد وتدل علي SQL Server بينما Oracle
لاتستخدم هذه الطريقه
علي العموم بعد ماتقدر تجمع كل هالمعلومات بيدك راح تكون قادر علي انشاء استثمار فعال عن طريق تقنيات
الكثير من المبرمجين يغفل عنها
طبعا هذا الدرس لن يكون ذو قيمه ابدا للي ماتمكن واتقن الدروس الماضية
مع تحياتي ....
هكر حايل Red-Code|4|
هذه هي الحلقه الثلاثه من الهجوم SQL injection واللي ماقرا الموضوعين الاولات لابد يقراهم قبل لايقرا الموضوع هذا |4|
ونبدا بسم الله :
قدمت مجموعه WebCohort لتطوير التطبيقات بحث مثير للاهتمام يركز علي ان الكثير من مطورين
التطبيقات يقعون في خطا حجب رسائل الخطا من قواعد البيانات ويضنون بذلك انهم تمكنوا من حل مشكله
SQL injection بس المشكله ان البحث هذا شرح طريقه كشف الثغره بدون رسائل الخطا من
قواعد البيانات طبعا هم افترضوا ان معلوماتهم صفر عن التطبيق وعن نوع قاعده البيانات وبنيه الجداول لاشي
تعالوا نشوف وش وصلوا له :
مثل ماقلنا عشان يعمل SQL injection يجب ان نحدد ان التطبيق مصاب بالثغره هاذي
وبوضعنا اليوم بدون رسايل خطا هذا يتطلب منا فهم ان التطبيق له حالتين اما يكون الاستعلام والطلب صالحات
او مايكونن
وش نوع رده الفعل من التطبيق اذا حاولت انشاء استعلام SQL عن طريق ادخال عادي
راح تواجه نوعين رئيسيات من الاخطاء من الويب سيرفر والتطبيق :
الاول راح يعطيك
'500: Internal Server Error'او يسويلك ري دايركشن علي الصفحه
الرئيسيه او يعطيك رساله خطا توضحلك ان الادخال خاطي ومن هالكلام
الثاني : راح يكون استجابه من نفس الكود وهذا يدل علي قوه البرمجه يعني يكون التطبيق متوقع انك راح
تختبره بزي هالطرق ويرجعلك رساله انيقه مع استجابه صحيحه 200 من السيرفر .
الان عشان تختبر الثغره لازم تقوم بتقديم مجموعه من الاستعلامات الصالحه ومراقبه كيف يتعامل التطبيق مع
الاخطاء
طيب الان يبد الاختبار :
شيك علي كل بارمتر في الاستعلام للتطبيق بالــSQL keywords مثل Or and
او بالـــMETA characters مثل الفاصله والفاصله المنقوطه وراقب رد فعل التطبيق
والبارمتر اللي يرجع رساله خطا خلي بالك منه يمكن يكون نقطه الضعف اللي تبحث عنها علي العموم ممكن
التطبيق اللي يتعامل مع استثناءات كثيره لابد يكون نسي حاجه ماشيك عليها استعمل intercepting proxy لكشف الريدايركشن علي امل ان يكون الخطا في مكان ما تبعد عنه
طيب الان كيف نحدد ان بارمتر معين معرض للهجوم :
يجب ان نفهم انواع البيانات في SQL وهي عباره عن ثلاث انواع رئيسيه Number,
String , Date كل بارمتر يرسل من التطبيق الي استعلام SQL هو واحد من هذه الثلاث
انواع
فمثلا abc هو String
و 12 هو Number
وغير ذلك Date
الان اذا كان البارمتر رقمي فهو يمرر الي سيرفر SQL زي ماهو بدون فواصل مثل التالي :
SELECT * FROM Products WHERE ProdID = 4
بينما البارمتر الحرفي يمرر محاطا بفواصل الي السيرفر كالتالي :
SELECT * FROM Products WHERE ProdName =
'Book'
سيرفر SQL اصلا مايهتم مدام الاستعلام صالح ويعود بنفس النتيجه اللي عنده
شوف هنا :
myecommercesite/proddetails.asp?ProdID=4
مثلا عشان تختبر البارمتر 4 الطريقه سهله تغير البارمتر
z '4 or 1+3
والزد عشان تظبط الفاصله ولا شيلوها فيصير الاستعلام
SELECT * FROM Products WHERE ProdID = 4'
او
SELECT * FROM Products WHERE ProdID = 3 +
1
الاستعلام الاول قطعا راح يرجع خطا لانه bad SQL syntax
اما الثاني فراح ينفذ بشكل طبيعي وكان البارمتر 4
وهذا يعني ياصدقائي ان هذا البارمتر يمكن تطبيق تقنيات SQL injection عليه
طيب الان خلصنا من البيانات الرقميه نجي علي String وتكمن الصعوبه في السلاسل الحرفيه
بانه تمرر للسيرفر محاطه بالفواصل فاول شي لازم نطلع من الفواصل الشي الثاني ان قواعد البيانات المختلفه
لها طرق مختلفه بدمج السلاسل الحرفيه بس مافيه اشكال ناخذ مثال :
myecommercesite/proddetails.asp?
ProdName=Book
عشان نشوف الوضع هنا نصدر استعلامين :
SELECT * FROM Products WHERE ProdName =
'Book''
SELECT * FROM Products WHERE ProdID = 'B'
+ 'ook'
لاحظوا بالاستعلام الثاني اذا مانجح بدل + حطوا || علشان ممكن السيرفر اوراكل لان علامه الزايد
تدمج المحارف بالاس كيو ال سيرفر و || بالاوراكل
نرجع للاستعلامين الاول راح يرجع خطا bad SQL syntax والثاني راح يضبط كان البارمتر
book وهذا معناته ان الهجوم ممكن تطبيقه
لاحظوا ان اي تعبير expression ممكن تطبيقه لاستبدال البارمتر الرئيسي بقيمه مشابهه له
ايضا هناك بعض الدوال ممكن تعيد لك كل انواع البيانات مثلا بالاوراكل sysdate ترجعلك التاريخ
ونفس الشي SQL Server فيه الداله getdate()
طبعا كان الكلام هذا عشان تثبت ان الهجوم ممكن تطبيقه الان نغوص اكثر
الان عشان نلقي الاستعلام الصحيح اللي نطبق فيه الهجوم يلزمنا الكثير من التجارب بس بشكل عام اذا كان
الاستعلام بسيط راح تلقاه ببساطه اما اذا معقد فراح يعقدك معه
الان يلزمك تجرب SELECT ... WHERE وتحاول تسوي انجكت للبارمتر بعد WHERE
بعض المرات اضافه OR 1=1 راح تكون كافيه لاستثمار الثغره وفي احيان كثيره يلزمك بعض المخمخه
الان بما ان WHERE تعيد ياصح ياخطا كثر من استعمال and or بتركيبات مختلفه يمان تحصل
الاستعلام المناسب جرب 'AND 1=2' اذا كنت تبيه تعيد خطا او 'OR 1=2' اذا تبي
صح وكمان جرب UNION SELECT Injection او stored
procedures injections اللي شرحناهم في الدروس الماضيه
لنفترض انك وجدت الاستعلام المناسب لهجومك الان كيف يمكن ان تعرف نوع قاعده البيانات
Oracle and Microsoft SQL Server
طبعا زي ماشرنا فوق ممكن تفرق بالطريقه اللي تنربط به السلاسل الحرفيه او عن طريق الفاصله المنقوطه
واللي تسمح لكتابه اكثر من امر في سطر واحد وتدل علي SQL Server بينما Oracle
لاتستخدم هذه الطريقه
علي العموم بعد ماتقدر تجمع كل هالمعلومات بيدك راح تكون قادر علي انشاء استثمار فعال عن طريق تقنيات
الكثير من المبرمجين يغفل عنها
طبعا هذا الدرس لن يكون ذو قيمه ابدا للي ماتمكن واتقن الدروس الماضية
مع تحياتي ....
هكر حايل Red-Code|4|