النتائج 1 إلى 6 من 6

الموضوع: مناقشات حول حماية الموقع و السكريبتات من الهاكر

  1. #1
    عضو نشيط
    تاريخ التسجيل
    Sep 2002
    المشاركات
    77

    مناقشات حول حماية الموقع و السكريبتات من الهاكر



    سنقسم الحوار حول الثغرات إلى قسمين :
    1- بيئة العمل من PHP,Apache,MySql,OS.
    2- ثغرات بالسكريبت.

    ثغرات بيئة العمل عديدة و كثيرة و متشعبة بالتعقيد لكن لدي نصائح سريعة لأصحاب المواقع:
    أ- تحديث بريمجات السيرفر إلى النسخ المعروفة بثباتها (لا أعني النسخ الأخيرة لأنها قد تحوي ثغرات فيصبح سيرفرك فأر تجارب).
    ب- دائماً يجب الحذر من الأعدادات الافتراضية بالأضافة إلى كلمات السر الافتراضية للنظام و قواعد البيانات أو أي بريمج آخر.
    جـ- متابعة آخر مستجدات الثغرات و كيفية التخلص منها.
    د- إعطاء الصلاحيات المناسبة لكل مجلد .
    و الحديث يطول حول حماية السيرفر لكنه ليس حديثنا...

    لأننا في هذا الموضوع سنناقش الثغرات التي من الممكن حصولها في السكريبتات و كيفية تلافي وقوع ذلك.
    أكيد بأننا سنتكلم عن الـ PHP حصراً .
    1- مدى خطورة استخدام الـ Sessions و كيفية حمايتها.
    2- Magic_qoutes و الاستثمار الشهير لاستعلامات الـ SQL .
    3- الـ FileUpload كيفية التعامل الصحيح معه لتجنب وقوع بأخطاء شهيرة و لكن قاتلة.
    4- حول البيانات التي يرسلها المستخدم و توقع وجود كود HTML .
    5- خطر السكريبتات الجاهزة الغير موثوقة المصدر (أو السكريبتات المعربة!).
    6- إعدادات عامة بالـ PHP ...
    7- تعليمات عامة و أخطاء عامة عن طريقة كتابة الكود.

    هذا ما في ذهني حتى هذه اللحظة !.
    اختارو أحد المواضيع و دعونا نناقشه ليكون حوار تفاعلي -علمي- بناء .
    لكني أخشى من أن يتم استخدام هذا النقاش من قبل البعض لأعمال الهاكر، عندها إذا ساهمنا بمساعدة 10 أسخاص على حماية سكريبتاتهم سنزيد بنفس الوقت عدد المواقع التي سيتم اختراقها.
    لأننا إن لم نشرح استثمار الثغرة من قبل الهاكر فلن تقتنع بوجود الثغرة من أصله.





    rocker غير متواجد حالياً


  2. #2


    أقترح لو يكون النقاش عن السيزونز sessions يكون أفضل

    لأنه اختراقهم سهل

    بس نبدي سيزون ونسوي واحد وهمي

    علشان ندخل على موقع ثاني





    __________________
    ArabBB ... SoooooN!
    Al Mobarmeg المبرمج غير متواجد حالياً

  3. #3
    عضو نشيط
    تاريخ التسجيل
    Feb 2003
    المشاركات
    76

    Re: مناقشات حول حماية الموقع و السكريبتات من الهاكر



    رد مقتبس من rocker


    1- مدى خطورة استخدام الـ Sessions و كيفية حمايتها.
    ( هذه محتاجة خبير في الهاكر و خبير في الـ php حتى يستطيع سد هذه الثغرة )
    2- Magic_qoutes و الاستثمار الشهير لاستعلامات الـ SQL .
    ( لا اعرف عنها شيء )
    3- الـ FileUpload كيفية التعامل الصحيح معه لتجنب وقوع بأخطاء شهيرة و لكن قاتلة.
    ( هذه الكل يقع فيها دائماً للأسف )
    4- حول البيانات التي يرسلها المستخدم و توقع وجود كود HTML .
    ( هذه معروفة .. لكن يجب ان تقال )
    5- خطر السكريبتات الجاهزة الغير موثوقة المصدر (أو السكريبتات المعربة!).
    ( دائماً ما تكون هذه السكربتات ملغومة )







    __________________

    * * * * * * *
    مع تحيات أبو حميد
    * * * * * * *
    abohamed غير متواجد حالياً

  4. #4
    عضو سوبر نشيط
    تاريخ التسجيل
    Dec 2000
    المشاركات
    998


    فيما يتعلق بـ

    حول البيانات التي يرسلها المستخدم و توقع وجود كود HTML

    على المبرمج أن يضع هذا الافتراض دائما، فإذا كان المتغير يتضمن رقما تعريفيا ID فإن عليك التأكد من أن المتغير لم يمرر عبر المتصفح

    ويكون ذلك بعدة طرق بحيث تلغي شفرة HTML إن كانت موجودة

    ولهذا يتفرض ألا يتعامل المبرمج مع النصوص في المتغيرات الممرة عبرة المتصفح، بل يتعامل بالأرقام ثم يطلب توابعها في الملف نفسه

    الدالة المستخدمة هي :

    strip_tags

    http://www.php.net/manual/en/function.strip-tags.php


    وقد تستخدم نظام الاستبدال بحيث تلغي <>


    $userMessage = ereg_replace('<([^>]|\n)*>', '', $userMessage);



    ويمكنك تحديد بعض الأوامر المتاحة :

    function escapeBadHTML($str) {
    $allowed = "br|b|i|p|u|a";
    $str = preg_replace("/< # match the open bracket
    ( # begin gathering
    (?! # followed by anything except...
    \/? # maybe a slash...
    ($allowed) # and one of the allowed chunks...
    \b # and a word boundary.
    ) #
    [^>]* # and any of not-">"'s
    ) # end gathering
    > # followed by the >
    /xis", "&lt;\\1&gt;", $str);
    return $str;
    }


    أو :

    function safeHTML($text) {
    $text = stripslashes($text);
    $text = strip_tags($text, '<b><i><u><a>');
    $text = ereg_replace ("<a[^>]+href *= *([^ ]+)[^>]*>", "<a href=\\1>", $text);
    $text = ereg_replace ("<([b|i|u])[^>]*>", "<\\1>", $text);
    return $text;
    }


    وهناك عدة نماذج في الرابط :

    http://www.php.net/manual/en/function.strip-tags.php





    __________________
    لا تعاند من إذا قال فعل
    الشنكبوتية
    اللغة العربية سياج هويتنا
    عبد الرحمن غير متواجد حالياً

  5. #5
    عضو نشيط
    تاريخ التسجيل
    Sep 2002
    المشاركات
    77


    عن سرقة الـ Session .
    هل تعلم بأن استخدام السيشن المضمن بالـ PHP غير آمن 100% !؟
    افتراضياً تكون كتابة السيشن إلى ملفات اسم كل ملف هو باسم السيشن و رقمها و بيانات الملف هي بيانات السيشن المسجلة بعد عمل Serialize ...
    يتم كتابة هذه الملفات إلى مجلد الـ /tmp . تكمن المشكلة في ذلك، هو بفرض أن السيرفر عليه عدة حسابات Virtual Hosts فيستطيع كل منهم الوصول إلى هذا المجلد فبمجرد أن يطلب قائمة للملفات ls سيحصل على أرقام السيشنز Sessions و بالتالي يستطيع استكمال أي سيشن أو يقرأ ملف السيشن المحفوظ ليجد ما به من بيانات (باسووردات أو غيرها).
    لحل هذه المشكلة عليك تغيير مكان المجلد الذي تريد أن يتم حفظ بيانات السيشن فيه عبر دالة session_save_path أو (أفضل) اعمل دوال خاصة للتعامل مع السيشن و تحفظ بيانات السيشن بالداتابيز session_set_save_handler .

    مشكلة أخرى:
    تعلم بأنه من الممكن حفظ متغير السيشن على طرف الكلينت إما عبر الكوكي أو عبر الـ URI و إن كانت session.use_trans_sid .مفعلة بإعدادات الـ PHP.INI فسيتم تعديل كل الارتباطات لتحوي على متغير السيشن -احذر من ذلك- .
    إن كان يوجد بموقعك ارتباطات لصفحات خارجية و كنت حافظ رقم السيشن عبر الـ URL فإذا نقر المستخدم على الارتباط للموقع الخارجي فيصبح هذا الموقع قادر على جلب رقم السيشن و استثمارها عبر الـ Referrer .
    الحل: لا تستخدم طريقة حفظ رقم السيشن عبر الـ URL إذا كنت تريد حفظ معلومات هامة عن المستخدم كاسمه أو الباسوورد أو تخويل الدخول تحت اسم هذه السيشن.
    استخدم بدلاً عنها الحفظ عبر الـ Cookie فقط وتأكد من تحديد خصائص الكوكي من الـ Domain و الـ path عبر session_set_cookie_params .

    راجع خصائص الـ Session في ملف إعداد PHP الـ PHP.INI تحت القسم [session] .
    عدّل الأعدادات إن قضت الحاجة (لكن عدّلها بعناية بالغة).





    rocker غير متواجد حالياً

  6. #6
    عضو سوبر نشيط
    تاريخ التسجيل
    Dec 2000
    المشاركات
    998


    هناك حل لمشكلة ملفات Session

    وهو حفظ في قاعدة البيانات وبهذا تسلم من أمرين :

    الأول : الخلل الأمني الذي قد يحصل

    الثاني : تضخم المجلد الذي تحفظ فيه الملفات


    بشرط أن تضع جدولا لوقت دخول الزائر أو العضو وعن طلب الصفحة الرئيسة نحذف من القاعدة ملفات Session التي مضى عليها ست ساعات مثلا





    __________________
    لا تعاند من إذا قال فعل
    الشنكبوتية
    اللغة العربية سياج هويتنا
    عبد الرحمن غير متواجد حالياً





ضوابط المشاركة

  • لا تستطيع إضافة مواضيع جديدة
  • لا تستطيع الرد على المواضيع
  • لا تستطيع إرفاق ملفات
  • لا تستطيع تعديل مشاركاتك
  •  

أضف موقعك هنا| اخبار السيارات | حراج | شقق للايجار في الكويت | بيوت للبيع في الكويت | دليل الكويت العقاري | مقروء | شركة كشف تسربات المياه | شركة عزل اسطح بالرياض | عزل فوم بالرياض| عزل اسطح بالرياض | كشف تسربات المياة بالرياض | شركة عزل اسطح بالرياض