[ss-ksa.com]

إقتباس: واستخدمة لغة asp في برمجتك فاتوقع ان حمايتك راح تكون مضمونه اكثر واحتمال الاختراق راح يكون اضعف على عكس استخدام الـ PHP في برمجتك

هل تقصد ان لغه asp افضل واقوى من php ؟؟؟؟؟؟


اخوي php افضل بكثير واقوى بكثير من asp

لاكن لن الهكر تعود عليها و فصفص ثغراتها اصبحت

لكن طالع لاكبر السكربات هو vb كتب فيphp لاحظ انتشار php عن asp

العيب ليس فيphp لكن العيب في مبرمج php كما هناك اخطاء وثغرات asp

لكن لا يوجد احد يستخدمها ومنتشرة يعني عطني سكربت asp اقدر احمل من النت واركبه على موقعي

مافيه اما سكربات php منتشرة بكل مكان


طيب كيف اعرف ثغرات asp وهي غير موجوده إلا في مواقع نادرة وقليله

ولا يوجد احد يستطيع تركيبها إلا اذا كان ببرمجته الخاصه

تقول الحكمه

من لا يعمل لا يخطاء

وهذا منطبق على asp

[Ayman Najjar]

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

انا عضو جديد في هذه المنتديات، وأرجو ان يكون تواجدي هنا سببا في الاستفادة وإفادة غيري بإذن الله، أثار سؤالك انتباهي و احببت ان ابدي رأيي في هذا السؤال الذي يشكل بحد ذاته مجالا خصبا لبحث يطول ولا ينتهي.

في الواقع ، أمن التطبيقات والسكربتات يعتمد بالدرجة الأولى على الاسلوب الذي يتبعه المبرمج في كتابة الكود، أما اللغة بحد ذاتها فنادرا ماتساهم في التقليل من أمن السكربت لأن معظم اللغات تعطي المزود حرية تغيير إعدادات الأمان (مثل register_globals ، display_errors بالphp) ولأن مطوروا اللغة يستمرون بتحديث لغتهم بشكل مستمر فالثغرات التي تظهر باصدارة معينة غالبا ما يتم تجاوزها بالإصدارات التي يليها.

أما فيما يخص السؤال الذي طرحه الأخ ملاك الحاسوب، فانا أرى - وقد تندهش لرأيي - ان البرمجة الخاصة عرضة للاختراق اكثر من غيرها، فإن لم يكن فريق البرمجة او المبرمج حذرا في كتابة سكربته فلن يكون هناك غيره لينتبه على عثراته، على عكس البرامج مفتوحة المصدر المطورة جماعيا open source/community-developed scripts.

قد تتساءل، كيف يمكن اختراق سكربت لاتعرف شفرته المصدرية، وهنا يأتي مايسمى بالهجمات العمياء blind attacks والتي تعتمد بالدرجة الأولى على المحاولة tiral and error، وهي انواع كثيرة ولكن معظمها تبدأ بالمحاولة على المدخلات التي يطلبها البرنامج (الـ parameters) ، لأنه المدخلات - كما تعرف - هي الوسيلة الوحيدة للوصول إلى الشفرة المصدرية، وغالبا تدخل المدخلات في معالجة processing، فإن كانت القيمة المدخلة غير متوقعة فيمكن المخترق ان يغير مسلك المعالجة على حسب مايريد

وإن كنت مهتما بانواع الهجمات التي تبدأ بالparameters فأعطيك امثلة عليها
SQL Injections
وهنا يفترض المخترق ان الparameter هو جزء من استعلام لقاعدة البيانات SQL Query، وكل ماعلى المخترق فعله هو تغيير الاستعلام ليناسب مراده
مثال، افرض ان لديك الاستعلام التالي:

إقتباس: "SELECT * FROM table WHERE field1 = '" . $_POST['f1'] . "' and field2 = '". $_POST['f2']

لو قام المختراق بادخال القيمة التالي في f1:

إقتباس: 1' or 1=1 --

فستصبح النتيجة كما يلي

إقتباس: SELECT * FROM table WHERE field1 = '1' or 1=1-- and field2 = 'value_of_f2'

وكما تعلم فإن -- تقوم بإلغاء بقية الاستعلام وتعتبره مجرد comment
بمجرد ما استطاع المخترق بإدخال or 1=1 في الاستعلام فإن نتائج الاستعلام ستكون جميع الrows وهذا يشكل كشف خطير لمحتويات قاعدة البيانات، طبعا تحل هذه المشكلة باضافة ال \ (escape sequence) عند كل علامة تنصيص ، ومعظم اللغات صممت لتقوم بإضافة ال\ على جميع الاحرف الخاصة بمدخلات HTTP (POST & GET parameters) بشكل تلقائي

ومن الهجمات الاخرى على المدخلات buffer overflows وعادة ماتكون على التطبيقات الشبكية وليس السكربتات مثل السيرفرات والbuffer overflow يقوم المخترق بإدخال parameter كبير اكثر مما هو متوقع ليتيح له الوصول إلى أماكن خارج حدود الbuffer (في الـstack أو الـheap) و إدخال أوامر معينة يرغب بتنفيذها (مثل adduser أو chmod) ، وهذه الاوامر تكون مكتوبة على شكل shellcodes بأحجام صغيرة

والحديث يطول في هذا المجال ، ولكن خلاصة الحديث انه كلما كنت حذرا في كتابة الكود كلما ضمنت حماية اكبر ودائما تأكد من التحقق من المدخلات قبل البدء في معالجتهم وتوقع جميع الاحتمالات من المدخلات... و عذرا على الإطالة

تحياتي،،
ايمن نجار