كيف تتجنب هجمات CSRF

[abshammeri 1,432]

السلام عليكم ،

الموضوع متداخل ما بين " تطوير تطبيقات الويب " ، وما بين " أمن المعلومات " ، و من محاسن الصدف أني لا أفقه في كليهما شيء ، ولكن لامانع من أن أدلو بدلوي ..

المشكلة

لو فرضنا أن اسمك الحركي هو " هاكر العرب " ، و تقوم بتطوير نظام منتديات بإسم " منتديات الصامد " .. لتقوم ببيعه لاحقاً على كبرى الشركات في العالم .. وهناك " زر " خطير في موقعك مخصص لإدارة الموقع ، مهمته حذف جميع مواضيع منتداك ، حيث يقوم هذا الزر بإرسال هذا الطلب :

index.php?do=deleteAll

طبعاً أنت لست غبياً .. حتى تنسى أهم شيء ممكن تعمله في الصفحة index.php ، حيث من المؤكد أنك ستتأكد أن من يقوم بضغط الزر هو عضو مسجل في المنتدى و لديه الصلاحيات اللازمة :

$do = $CleanParameter($GET['do']);
if ( $do == "deleteALL" )
{
	if ($currentMember) // registered user
	{
		if( $currentMemberPrivileges['deleteAll']) // the user has the privilege 
		{
			$Database->deleteAllTopics();
		}
	}
}

لاحظ أنك قمت بكل شيء من تدقيق على المستخدم ، ومن التأكد أنه يملك الصلاحيات ، بل وحتى قمت بتطهير البارمتر do من أي شوائب قد تؤدي إلى SQL Injection ( اسم "هاكر العرب " لم يأت من فراغ ) .. لكن هل هذا يكفي ؟

لاتنسى أنك ستبيع منتجك لملايين المستخدمين حول العالم ، وكل مستخدم يملك نسخة من نظامك .. فهو بلا شك سيدخل على لوحة التحكم وسيعرف URL أو http request المسؤول عن حذف جميع المواضيع .

ولكن كيف يمكن أن يستفيد من هذه الثغرة ؟ في الحقيقة هو لا يستطيع أن ينفذ هذا request على مواقع أخرى لا يملكها .. ولكن يمكنه وببساطة أن يفتح تذكرة Ticket .. بما أنه " زبون عندك " ، يقول فيها :

أخي " هاكر العرب " ،

لقد اشتريت منك نظام المنتديات الرائع .. المسمّى "بمنتديات الصامد " ، أعجبني جداً ، لكن هناك وظيفة لم أستطع تنفيذها و في الرابط صورة توضح المشكلة .. أتمنى حلها .. وسأقدم لك ماتريد من مبلغ مالي إن لزم الامر .. تحياتي :

الصورة هنا

الرابط في الرسالة .. يحتوي على هذا URL :

http://www.alsamid-forums/index.php?do=deleteAll

ولو فرضنا أنك قمت بتخزين جلسة العمل session على موقعك " الصامد " وتستخدم cookies أيضاً ، وهذا شبه مؤكد ( لأنك تدخل على موقعك كل ساعة على الاقل ) .. فهذا يعني أنه وبمجرد نقرك على ذلك الرابط .. فإنه سيتم حذف جميع المواضيع في منتديات " الصامد " ، وعندها أنصحك أن لا تتسمّى بتسميات أنت لست أهلاً لها :P .

ماهو الحل ؟

أحد الحلول التي أعرفها هي باستخدام security key وممكن تجده بإسم Auth Key ، وببساطة تضع لكل شخص سجل دخوله على موقعك key معين ، بحيث من الصعوبة أن يكتشفه أحد ( هذا Key يتغير عند كل عملية تسجيل دخول ) ، و عندها يجب أن يحتوي request على key مطابقة للموجودة في جلسة العمل الحالية session .. وبالتالي سيصبح url و Index.php كالتالي :

//   index.php?do=deleteAll&security_key=1111116803f175cba8e08b68c84f37ba


$do = $CleanParameter($GET['do']);

// -- SECURITY KEY
$security_key = $CleanParameter($GET['security_key']);

if ( $do == "deleteALL" )
{
	if ($currentMember) // registered user
	{
		if( $currentMemberPrivileges['deleteAll']) // the user has the privilege 
		{
			if ($security_key == $currentSecurityKey) // SECURITY KEY
				$Database->deleteAllTopics();
		}
	}
}

ولا شك و لا ريب ، أن " زبونك المحترم " ، لن يخمّن هذا الـ Key ، ولن يحاول ..

إن كان هناك خطأ في أي معلومة فالرجاء التصحيح فلا تنسى :

الموضوع متداخل ما بين " تطوير تطبيقات الويب " ، وما بين " أمن المعلومات " ، و من محاسن الصدف أني لا أفقه في كليهما شيء ، ولكن لامانع من أن أدلو بدلوي ..

_{المصدر : wikipedia+ Xacker}

[kldoon 236]

ههههههههههه و هاقد أجبت عن السؤال الذي يدور في خاطري دائما، من خلال موضوعك اللذيذ هذا :happy:

http://www.arabteam2000-forum.com/index.php?showtopic=241342

ماذا تعني ال s في هذا الرابط

*واضح ان ال s حذفت من الرابط ولكنها موجودة لدي :)

يعطيك العافية فائدة جميله :)

تم تعديل 6 May 2011 بواسطه *خلدون خالد*

[abshammeri 1,432]

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

بالمناسبة /

أظن أنه من الممكن أن تتخلص من هذه الثغرة لو قمت بتخزين Session id في URL وليس في Cookies .. عندها ستكون ضربت عصفورين :

* عصفور الإبقاء على جلسة العمل مفعّلة في حالة عدم تفعيل Cookies في جهاز المستخدم،

* وعصفور آخر للحماية من CSRF .. دون الحاجة لتوليد رقم آخر لـ security key أو دون الحاجة لإضافة بارمتر آخر لـ security key ..

ولكن ستكون قتلت أهم العصافير وهو URL مشوّه :P .. لذلك أظن أنه من الأفضل استخدام security key أو session id عند الحاجة فقط .. وإن لم تحتاجه تكتفي بتخزينه في Cookies ..

طبعاً هذا مجرد تخمين لما فهمته من الموضوع ..

[System Down 557]

ولكن لم تضع العملية في الـURL أصلاً؟ :)

[abshammeri 1,432]

تقصد post مثلاً ؟

إذا كان كذلك فالأمر سيّان*

_{* سيّان == مثل بعض ,}

[System Down 557]

بشكل عام من الأفضل تجنب وضع العمليات في الـQuery String ويكتفى بوضع المعلومات التي توصف المحتوى (رقم الصفحة، رقم المقالة ... إلخ). وإذا كنا نريد أن نتبع أسلوب الـMVC فعملية الـDelete (وأي عملية في الواقع) يجب أن تكون لها صفحة منفصلة. أي شئ كهذا

http://www.alsamid-forums/index/deleteAll

الذي يؤدي إلى صفحة تطلب التأكيد قبل المضي في العملية.

[abshammeri 1,432]

أظن حتى هذه الصفحة التي تطلب التأكيد يمكن استغلالها إذا لم يكن هناك Auth key في request ؟ يمكن الأمر أصعب ، ولكن بغض النظر عن صفحات التأكيد التي تستخدم عادة في الأمور المهمة ، هناك الكثير من العمليات التي لا تحتاج صفحة تأكيد .. والتي قد تكون مهمة .

في SO مثلاً ، عندما تقوم بالتصويت على إجابة معينة :

http://stackoverflow.com/posts/5917516/vote/2

ونوع الطلب هو post ( أجاكس طبعاً ) ، و البارمتر المرسل :

fkey=cd11faaf49be5f094c4de75e6b9b5b15

لذلك ما أعتقده ، أنه في كل الأحوال وبغض النظر عن أسلوبك في الطلب request ، في النهاية أنت مضطر لتستخدم شيء يشبه auth key ، طبعاً هذا على حسب فهمي و يمكن أكون مخطئ .

[System Down 557]

لذلك ما أعتقده ، أنه في كل الأحوال وبغض النظر عن أسلوبك في الطلب request ، في النهاية أنت مضطر لتستخدم شيء يشبه auth key ، طبعاً هذا على حسب فهمي و يمكن أكون مخطئ .

أو أن تستخدم بسكوتة cookie :)

مثلاً الـASP.NET تعتمد على الـcookie كمفتاح للاحتفاظ بمعلومات الجلسة (بما فيها بيانات الـauthentication) ولكن إذا قلبت وضع تطبيقك إلى cookiless (رجيم يعني) فسوف يضع هذا المفتاح (مؤقت وله مدة صلاحية) داخل الـquery string ويصبح لديك URL مخربط :)

[password123 56]

الشمري

أخي " هاكر العرب " ،

لقد اشتريت منك نظام المنتديات الرائع .. المسمّى "بمنتديات الصامد " ، أعجبني جداً ، لكن هناك وظيفة لم أستطع تنفيذها و في الرابط صورة توضح المشكلة .. أتمنى حلها .. وسأقدم لك ماتريد من مبلغ مالي إن لزم الامر .. تحياتي :

الصورة هنا

هذا social engineering ليس إلا، حاله حال الphishing والحل الذي اقترحته جيد لكنه fool--proof فقط ليعض السيناريوز

[abshammeri 1,432]

هذا social engineering ليس إلا، حاله حال الphishing والحل الذي اقترحته جيد لكنه fool--proof فقط ليعض السيناريوز

شكراً أخي ، لكن أعرف أنها هندسة اجتماعية ، لكن أحد أبسط الطرق لاستغلال هذه الثغرة هي بخداع المستخدم سواءً بهندسة اجتماعية ، أو بملف " ملغوم " وفي الغالب الطريقة الأولى أسهل .. لكن ماهي " الحلول " الأخرى التي تحل الاشكال ؟

هناك حلول ، لكن مكلفة .. في البنوك مثلاً ، يتبنون شيء باسم MFA ، أي Multi-factor Authentication ، وهي عملية طلب نوع آخر من Authentication ، أثناء تنفيذ بعض العمليات الحساسة . فمثلاً في عملية التحويل من حساب لحساب .. يجب أن تضيف Beneficiary ( مستفيد ) ، هذا المستفيد ، يجب إضافته بعد إدخال رقم سري يصل إلى " موبايلك - sms " ، أو باستخدام Soft token أو Hard token .. وبالتالي مستحيل أن ينفذ عملية التحويل إلا وصاحب الحساب يعلم أنه يقوم بعملية التحويل .. لذلك من المستحيل خداعه .

هذه الأساليب أكثر أماناً ، لكن مكلفة ، و لم أرها مستخدمة إلا في البنوك فقط .

[password123 56]

الشمري

نعم هي هندسة اجتماعية، ومغزاها من النهاية انك تقنع الطرف الآخر بالقيام بعدة اشياء بنفسه حتى يوقع نفسه بيده في المصيدة

وهناك حلول ايضا classifiers تقوم بمعاينة الرسائل (سواء ايميل او مسج..الخ) وتحاول مسك هذه العمليات التي تستغل غباء المستخدم.

مثال آخر هو salting للpassword بوضع الdomain للموقع من خلال مقابس في المتصفح لكنه يحل مشكلة أخرى وهي ان الرسالة تطلب من المستخدم كتابة الpassword في input form في موقع آخر مزور يشبه الموقع الحقيقي.. وهذه في ورقة مؤتبر سنة 2005 تقريبا في مؤتمر USENIX

وكل هذه الحلول هي fool-proof

بالنسبة للحلول المكلفة التي تقول اتفق معك ايضا... للاسف هذه ليست مفيدة في هذه الأيام كما كانت سابقا بسبب man-in-the-browser attacks او MitB

امثلة ك Zeus و SpyEye تحتوي على add-ons لهذه الحركات الاجرامية e-crime

هناك حل آخر وهو توعية المستخدم حتى لا يكون fool والذي بدوره لن يحتاج fool-proof systems

لكن الواقع يقول ان البني آدمين ادمغتم متحجرة ومشغولين بأمور الحياة وتعلمهم صعب.. ولذا fool-proof systems جيدة

Only two things are infinite, the universe and human stupidity, and I'm not sure about the former

Albert Einstein

الحركة التي قمت أنت بذكرها حركة ذكية وانا اعتبرها fool-proof system قوي لحل ثغرة امنية مفتوحة من خلال الهندسة الاجتماعية

وهذه ليست مجاملة لانك كما تعلم انا صريح جدا :ph34r:

خلاصة الكلام انا فقط اتحدث عن امور تقنية لأنني مصاب بالملل قليلا وتعجبني هذه النقاشات الهادفة لتبادل الخبرات

لو تقرأ كلامي مرة أخرى فأنا لا أعترض على كلامك... فقط اضيف عليه: انه يعتبر هندسة اجتماعية والحلول fool-proof

وطبعا لو انت في يوم من الايام ذكرت معلومة خطأ في رأيي سأقولها لك... ونفس الشيء العكس (انت تقول لي)...

ولا يوجد من يقعد في زاوية للبكاء لانه هناك شخص random في الانترنت بيشتم :D

[abshammeri 1,432]

طبعا طبعاً .. مستمتع بما تقول ، وأذكّرك أني جاهل في أمن المعلومات ، و فاتح wikipedia الآن لأتفلسف عليكم :D ..

ماذا تقصد بـ fool-proof systems ؟

لم أستطع فهم ما تقصد بصراحة ..

أيضاً :

بالنسبة للحلول المكلفة التي تقول اتفق معك ايضا... للاسف هذه ليست مفيدة في هذه الأيام كما كانت سابقا بسبب man-in-the-browser attacks او MitB

تقصد أن MFA غير مجدية الآن ؟

امم ، أظن أن دور MFA من اسمها ، حل مشكلة Authentication ، مسألة اصطياد و اعتراض الطلب هذه قصة أخرى و أعتقد صعبة ونادرة الحدوث ، أسمع عنها كثيراً لكن لا أظنها موجودة :-) ، وإن وجدت فكيف سيستغلونها ؟ لا أعرف .. أسمع كثيراً كثيراً عن Man-in-the-middle .. لدرجة أن أي اتصال بين نقطتين أصبح معرض لهذا النوع من الهجوم ..

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

http://google-news.wordpress.com/2007/06/13/elle-effect/

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

[password123 56]

انت على راسي.. انا كذلك فاتح الويكي بيديا :blush:

لا اقصد ان MFA غير مجدية. كل الذي اقوله انه ليس مجديا في زمننا الآن كما كان في الماضي

قديما كان جوابا قاطعا لمحاربة من يسرق الكلمات السرية

لكن الآن مع man-in-the-browser attacks ممكن سرقة اموال واضرار و MFA لن يفيد في هذه الحالة

بالنسبة لغباء المستخدم فمثالك غير صحيح.. المتصفحات لا ترسل cookies على redirects إلا وفقط عندما يقوم الموقع الاساسي (الredirector) نفسه بوضع تلك الكوكيز...

ولو كان كلامك صحيحا لفسدت الانترنت... وممكن تجرب عمليا بهذه التجربة البسيطة

واذا كان لديك اي متصفح يقوم بعكس ذلك فبإمكانك ارسال bug report لان هذا يتعارض نصا مع rfc 2109

المصدر http://www.w3.org/Protocols/rfc2109/rfc2109 اقرأ قسم 4.3.5 Sending Cookies in Unverifiable Transactions

الكوكيز يتم ارسالها فقط للverifiable transactions

لذا المشكلة لا تزال غباء من المستخدم فالتطبيق (متصفح الانترنت) ذكي كفاية بحيث ان لا يرسل كوكيز لredirects (الناس فكروا فيها مسبقا) :D

بالنسبة للfoolproof (بالخط الصغير نظرا لقلة اهميته حتى لا ياخذ مساحة)

اقصد بfool-proof مصطلح عام يطلق على اي حركة تقوم بها حتى تتجنب الfools اي الحمقى

على سبيل المثال... بعض الساعات مكتوب عليها water proof...وتعني ضد الماء

عندما نقول fool proof يعني ضد الحمقى :D

المصطلع منشأه فكاهي كما ترى.. لكني شاهدت له استخدامات تقنية..

مثلا العديد من توزيعات اللينكس تفعل ماتامرها دون مسالتك كثيرا (وهكذا ياما مسحت ملفات مهمة بالخطأ :D)

بينما الوندوز foolproof نوعا ما لان يسالك في كل خطوة هل انت متاكد؟ شارب حاجة؟ ... الخ. وبعدها يفعل ما تأمره

طبعا foolproof systems افضل للfools، لكن يكون مزعج لغير الfools

وهناك سؤال قديم هل انا fool؟ كل بني آدم يظن انه ذكي.. ولهذا السبب لدينا fools :ph34r: وربما انا واحد منهم (قطعا بعض الناس يظن انني احمق خاصة انني لا اجامل)