الدالة $_REQUEST

[soma]

السلام عليكم
هل استخدام $_REQUEST يمكن أن يؤدي الى ثغرة امنية بطريقة ما .... ؟

وشكراً ...

"$_REQUEST ليست داله وانما متغير عام"

[وضاء]

و عليكم السلام .
اخوي الاستعمال العام للمصفوفة لا يمكن ان يشكل خطراً و الافضل ان تقوم بحمايتها عبر دوال الحماية الشهيرة.
هذا و الله اعلم .

[ArabCoders]

عفواًُ اخى لماذا تريد إستخدام $_REQUEST وأنت تستطيع تحديد المدخل عن طريق $_GET او $_POST ؟

[أبونجم]

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

اخوي سواء $_REQUEST او غيره من المصفوفات, سواء بتعالجها بدوال في الكود او فقط للعرض , لازم تطبق عليها الحماية بالفلترة من اي ادخال خارجي

[محب الله ورسوله]

الشباب هنا صار عندهم هاجس من المدخلات لدرجة حماية كل شيئ
أنت غير مطالب نهائي بحماية المدخلات بشكل دائم

فمثلاً لو كان المدخل هو تحديد لل action المراد تنفيذها يكفي إستخدام الدالة الشرطية أو ال case لتحديد الدالة المرادة مع إستخدام else لو كان المدخل ليس مما حددت
وفي حالة case تضع default لو كان المدخل ليس مما حددت

يخرج له خطأ

فلما تحمي المدخل إذا إذا كنت محدد من البداية ما هي المدخلات التي تريدها وكل ما عداها ترفضه ؟

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

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

بالنسبة للأخ السائل

$_REQUEST تقوم بالقراءة للمتغير سواء أكان قادم من post أو get
ولا أدري له له أفضلية للبوست أم لا
ولكن بكل تأكيد يفضل لو كنت تقرأ من post أن تحددها حتي لا يتم التلاعب وإرسال get لمتغير مشابه

وإستخدامها بشكل عام هو نفس إستخدام الأخرين تتعامل معه بحسب الحالة

[أبونجم]

الشباب هنا صار عندهم هاجس من المدخلات لدرجة حماية كل شيئ
أنت غير مطالب نهائي بحماية المدخلات بشكل دائم

فمثلاً لو كان المدخل هو تحديد لل action المراد تنفيذها يكفي إستخدام الدالة الشرطية أو ال case لتحديد الدالة المرادة مع إستخدام else لو كان المدخل ليس مما حددت
وفي حالة case تضع default لو كان المدخل ليس مما حددت

يخرج له خطأ

فلما تحمي المدخل إذا إذا كنت محدد من البداية ما هي المدخلات التي تريدها وكل ما عداها ترفضه ؟

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

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

بالنسبة للأخ السائل

$_REQUEST تقوم بالقراءة للمتغير سواء أكان قادم من post أو get
ولا أدري له له أفضلية للبوست أم لا
ولكن بكل تأكيد يفضل لو كنت تقرأ من post أن تحددها حتي لا يتم التلاعب وإرسال get لمتغير مشابه

وإستخدامها بشكل عام هو نفس إستخدام الأخرين تتعامل معه بحسب الحالة

الرجال كتب "سلام عليكم" في البداية هذه اولاً

ثانياً بالنسبة لأول جزئية, اي ادخال للمعلومات من خارج الصفحة يعني اي input هو معرض لشي اسمه استغلال ... رابط

مثال لكود تافه تعطيه كلمة في مربع ادخال ويطبعها لك:

<?php
echo "<form method='get'>
<input type='text' name='search' >
<input type='submit' name='do' >
</form>";

if($_GET['do'])
echo "<p style='color:red'>you searched for".$_GET[search]."</p>";
?>

كود مثل هذا مرفوع ع موقعك يخليني اسرقلك حسابك وايميلك وكل شي يخصك ع اقل تقدير! "مو انا الهكر يعني "

كود بسيط تحطه في المربع حق هالكود
<script>alert(000)</script>



فلا تقلل من شأن موضوع الحماية
+
لا تقلل من شأن اي واحد تكلمه في المنتدى


بالنسبة للي بالأحمر رابط


وشكرا

[أشرف السمهوري]

أبونجم ، المجروح يقصد ان الحماية تكون في حالتين عادة : إما في استعلامات SQL ، أو طباعة العنصر ..

if ($_GET['action'] == 'edit') {
 
} 

هو أراد أن في هذه الحالة مثلاً لا نحتاج لتمرير العنصر action من المصفوفة إلى دوال الحماية ..

في نفس الوقت سنحتاج الحماية من XSS عند طباعته:

echo $_GET['action']; 

وكذلك الحماية من SQL Injection في أي استعلام SQL ..

القصد أن الحماية تكون فقط عند الحاجة ( عندما يؤدي تغيير قيمة العنصر إلى إحداث خلل في عمل البرنامج ) ..

أطيب التحيات، أشرف السمهوري

[أبونجم]

أبونجم ، المجروح يقصد ان الحماية تكون في حالتين عادة : إما في استعلامات SQL ، أو طباعة العنصر ..

نسيت دوال الانكليود ^_^

بالرغم ان if else او case لتحديد دوال مستخدمة او قيم داخله فيه طريقة مو دايما عملية لكن لو سلمنا بهالكلام وبالفعل ملفك اللي فيه بضع من الاسطر مافي امكانية لاستغلاله هل تضمن انك رح تكون متنبه لل 5 او 6 متغيرات اللي عندك مع الزمن والتطوير المستمر لها وازديادها ؟

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


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

[أشرف السمهوري]

نعم نسيت دوال التضمين ( include, include_once, require, require_once ) ، لأني لا أستخدم فيها متغيرات إطلاقاً .. أو على الأقل لا أستخدم متغيرات غير مأمونة الجانب ( عناصر مصفوفات خارجية مثلاً ) ..

لكن القصد بشكل عام كان حول أن دوال الحماية يجب أن تطبّق فقط في المواقع التي تحتاج ذلك، وأمثلتي كانت على سبيل المثال لا الحصر ..

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

أن تكتشف ثغرات في برنامجك نتيجة سهوك ستجعلك أكثر خبرة في مواقع الثغرات وتأمين برامجك منها، على خلاف استخدامك لدوال قد تؤدي أحياناً إلى تخريب وظائف أخرى في البرنامج والتقليل من حسن أداء برنامجك ..

تحياتي، أشرف السمهوري

[أبونجم]

- انت لا تستخدمها لكن يمكن غيرك نعم ,,, نقاشنا مو لبعضنا البعض هو لكل زائر وقارئ

- موضوع الأداء هذا يختلف حسب طريقة الحماية اكيد فرق في زمن التعقيد بين while, عن if لشروط محدودة

- لما يصير عندك مئات او آلاف الأسطر مع تعدد الملفات ماعاد صار الموضوع موضوع خبرة , صار موضوع "تحدي ماله داعي لنفسه!"

[أشرف السمهوري]

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

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

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

تحياتي، أشرف السمهوري

[Isaac Wahb]

مرحبا
ليس شرطا ساعطيك مثال تكزن فيه المتغير $_REQUEST بمثابة ثغرة :

$content = $_REQUEST["post"];
$sql = "INSERT INTO topic VALUES ($member_id,$content,$post_id)";
mysql_query($sql); 

هنا بامكان الشخص ان يقوم بتمرير بعض الاشياء غير المرغوب بها عن طريق الرابط اي باستخدام $_GET

http://site/?post="<script20%type=text/javascript>alert('Hacked');</script>" 

بامكانه ايضا تمرير نفس الشيء عن طريق $_POST

لكن بامكانك ان تستخدم دالة للفلترة والاستبدال ولا تصبح مشكلة
لكن في حالة ان امكانية $_GET متاحة اذا اليس من الممكن عمل ما يشبه الفلود ؟
باستدعاء الرابط اكثر من مرة باستخدام AUTO REFRECH او باستخدام برانامج او سكريبت ؟

لذلك يفضل تجديد الطلب بدقة ان كان بوست او جات

موفق

[أبونجم]

نعم الحماية مكلفة وهالشي سبب عدم امكانية الافراط فيها, بالتالي مانقدر ننفي مقولة "there is no such thing as 100% security", لكن يبقى تطبيق الحماية امر نسبي ع حسب البرنامج وحجمه وطبيعة الموقع والسيرفر اللي يشتغل عليه.
مثلاً تطبيق الحماية بشكل كامل ع كل المتغيرات من البداية, مثل $_XXX لبرنامج محدود غير لبرنامج ضخم وهنا يجي تأثير time complexity


نقطة هامة أخرى اذا كنت انت "مبرمج متمكن" تضمن بعدم ارتكاب اي خطأ فني يؤدي لخرق امني لبرنامجك فانت تمثل عُشر بالمئة من المبرمجين واذا حاب تعرف ليش خذلك جولة في مواقع السكيروتي واطلع ع آخر ثغرات البرامج والبرامج الشهيرة منها .

طبعاً الأسباب كثيرة احدها اللي ذكرته بالبداية + ان هالبرنامج قد لا يعمل عليه شخص واحد وانما فريق يوزع عليهم العمل اضف لهالشي موضوع التطوير المستمر للبرنامج
كمثال بهالشي سكربت الجووملا , هالسكربت ثغراته ملئت مواقع السكيورتي السبب هو تعدد فرق العمل والتطوير الذي قد يخرج عن ذلك التنظيم الممكن يتواجد في شركة مغلقة, بالتالي ضاع اجراء الحماية او عقولة اهل الشام "ضاعت الطاسة!"
حتى الآن لايوجد جهة ثابتة لدعم السكربت بالكامل حتى!

اذا قد يكون هناك الحاجة لبناء دالة او كلاسات تستلم العناصر وتطبق عليها الحماية وتعيدها للبرنامج وبالفعل هالشي موجود ببعض السكربتات.. نعم كلاسات خاصة للحماية "مع وجود المفاضلة المستمرة بين مخاوف الثغرات + مخاوف الاداء"


أبونجم

[محب الله ورسوله]

نعم الحماية مكلفة وهالشي سبب عدم امكانية الافراط فيها, بالتالي مانقدر ننفي مقولة "there is no such thing as 100% security", لكن يبقى تطبيق الحماية امر نسبي ع حسب البرنامج وحجمه وطبيعة الموقع والسيرفر اللي يشتغل عليه.
مثلاً تطبيق الحماية بشكل كامل ع كل المتغيرات من البداية, مثل $_XXX لبرنامج محدود غير لبرنامج ضخم وهنا يجي تأثير time complexity


نقطة هامة أخرى اذا كنت انت "مبرمج متمكن" تضمن بعدم ارتكاب اي خطأ فني يؤدي لخرق امني لبرنامجك فانت تمثل عُشر بالمئة من المبرمجين واذا حاب تعرف ليش خذلك جولة في مواقع السكيروتي واطلع ع آخر ثغرات البرامج والبرامج الشهيرة منها .

طبعاً الأسباب كثيرة احدها اللي ذكرته بالبداية + ان هالبرنامج قد لا يعمل عليه شخص واحد وانما فريق يوزع عليهم العمل اضف لهالشي موضوع التطوير المستمر للبرنامج
كمثال بهالشي سكربت الجووملا , هالسكربت ثغراته ملئت مواقع السكيورتي السبب هو تعدد فرق العمل والتطوير الذي قد يخرج عن ذلك التنظيم الممكن يتواجد في شركة مغلقة, بالتالي ضاع اجراء الحماية او عقولة اهل الشام "ضاعت الطاسة!"
حتى الآن لايوجد جهة ثابتة لدعم السكربت بالكامل حتى!

اذا قد يكون هناك الحاجة لبناء دالة او كلاسات تستلم العناصر وتطبق عليها الحماية وتعيدها للبرنامج وبالفعل هالشي موجود ببعض السكربتات.. نعم كلاسات خاصة للحماية "مع وجود المفاضلة المستمرة بين مخاوف الثغرات + مخاوف الاداء"


أبونجم

اخي أبو نجم ماله داعي كل هذا الكلام

بإختصار حماية المدخلات تتم فقط علي ما يمكن أن يكون ثغرة
يعني مدخل من شخص ستحفظه في قاعدة البيانات او تجلب به بيان او سيتم عرضه للزائر
لكن مدخل لجلب صفحة يمكن إستخدامه مباشرة مع دالة التحقق من وجود الملف علي السيرفر
مدخل لجلب دالة يمكن إستخدامه علي الفور مع شرط التحقق من وجود الدالة

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

أما عن قولك علي كلاسات الحماية فال php 5.2 جاءت معها كلاس مدمجة للحماية للمدخلات بنظامين

validate
Sanitize

فلا داعي لإستخدام كلاسات خارجية

وأخيرا أتمني حقاً أن تتعرف علي أنواع الثغرات لأن الكثير من المبرمجين صار لديهم هاجس وصار يحمل كل مدخل او مخرج وذلك لعدم معرفته كيف وأين تستغل المدخلات من الأساس !!

[soma]

شكرا للجميع بارك الله فيكم