01-10-1394، 09:49 ب.ظ
02-10-1394، 03:25 ب.ظ
خیلی خلاصه: مشکل از PHP نیست. برنامه هایی که نوشته شده، از این باگ جلوگیری نکرده بودن و طبیعیه که مشکل پیش میاد. این قبیل مقالات که اشکالات برنامه نویس رو به پای زبان برنامه نویسی میگذارن توی ایران خیلی زیاده. البته حجم بیشتر کدهایی که با PHP نوشته شدن نسبت به سایر زبانهای برنامه نویسی سمت سرور وب هم میتونه علت مهمی در پررنگ تر بنظر رسیدن این قبیل مسائل بشه.
08-10-1394، 08:08 ب.ظ
نقل قول:خیلی خلاصه: مشکل از PHP نیست.بنظر من الان دیگه تاحدی مشکل از PHP هم هست.
زبانی که برداشته عملگر == رو طوری پیاده کرده که استفاده ازش براحتی میتونه منجر به رفتارهای پیشبینی نشده بشه، به ایجاد حفره های امنیتی کمک میکنه.
اینو بعنوان یک متخصص و آدم مطلع در امور امنیت میگم. میخواید قبول کنید میخواید نکنید، ولی من دیگه بعد از چند سال مطالعه و تحقیق قهارانه در زمینهء امنیت میدونم دارم چی میگم و بارها دیدم بهم ثابت شده که سواد و تخصصم در امور امنیت در حد استانداردهای روز دنیاست! پس دارم این نظر رو بصورت رسمی و با تخصص و صلاحیت میدم.
من با کلی زحمت برداشتم تقریبا تمام موارد == در پروژهء خودم رو به === تبدیل کردم به همین خاطر. وقتی یک متخصص امنیت نمیتونه با این عملگر از امنیت برنامه اش اطمینان داشته باشه، دیگران هم نمیتونن. ضمنا یک مورد حفرهء SQL Injection توی برنامم کشف کردم که دقیقا بخاطر رفتار غیرعاقلانهء این عملگر ایجاد شده بود.
حالا شما بیا همش از PHP دفاع کن!
نخیر دوست عزیز طراحان PHP هم بنظر من ناشی گری ها و اشتباهات واضحی کردن و میکنن که برای خود من به شخصه جای تعجب و سواله که چرا، واقعا از روی چیه آیا سواد و بینش لازم رو ندارن یا مسئلهء دیگریست!
از همون اول هم در PHP یکسری این تصمیمات غلط در طراحی دیده شده که روشن ترین نمونهء تاریخی اون register globals است که گمونم در کل تاریخ برنامه نویس چنین طراحی ناشیانه ای در هیچ زبانی دیده نشده تاحالا! من اون موقع سالها پیش که هنوز اینقدر سواد امنیت نداشتم فهمیدم که این چیز مسخره ایه. تازه آخرش هم که خودشون مجبور شدن حذفش کنن، باوجودیکه یکی از ویژگیهای پایه و محبوب در PHP بود (ولی محبوب از دید چه کسانی، مسئله اینه، از دید مبتدی ها و آدمهای کم سواد و کم بینش در زمینهء امنیت).
***
توی هیچ زبانی والا چنین افراط کاری هایی ندیدم تاحالا که اونقدر یه عملگر پر استفاده رو بد طراحی کنن که آدم مجبور بشه عملا استفاده از اونو کنار بذاره!
تمام زبانها تبدیل نوع خودکار و این حرفها دارن، ولی هیچکدام به افراط و سرخودی کارهایی که در PHP صورت میگیره نیست.
اینقدر این تصمیمات طراحی اینا غیرمنطقی و عجیبه که من شخصا دیگه شک کردم ذهنم گهگاه میره طرف تئوری های توطئه که این ضعف ها رو بقول بعضیا عمدا در زبان برنامه نویسی میذارن که سازمانهای امنیتی مثل موساد و NSA بعدا ازشون بهره ببرن! یا بهرحال یه سیاست و هدف مخفی دیگری در کاره. میدونیم که PHP محصول اسرائیله (زند شرکتی اسرائیلیه)، و این به این شک و بدبینی بیشتر دامن میزنه.
09-10-1394، 10:18 ق.ظ
در اینکه PHP مشکلات زیادی داره شکی نیست و هر زبان دیگری هم کم و بیش مشکلات خاص خودش رو داره ولی منظور من اینه که خیلی از این آمار و ارقام بخاطر ناشیانه بودن کدنویسی هست نه خود زبان برنامه نویسی. چرا سایتهایی که ما درست میکنیم چنین باگهایی توش در نمیاد؟ مگه ما با همین PHP نمینویسیم؟ اینقدر هم صحبتهای حاشیه ای مثل شرکت اسرائیلی و... مطرح نکنید چون PHP یک زبان بازمتن هست و قطعاً اگه حفره امنیتی عمدی و خاصی داخلش بود تا حالا لو رفته بود. ما خودمون نتونستیم یه زبان در حد یک هزارم PHP بسازیم و مدام داریم از ابزارهای بقیه استفاده میکنیم و بعد تا یه چیزی میشه میگیم فلانی داره جاسوسی میکنه و فلان ابزار جاسوسیه. اگه معادل بهتری سراغ دارین خوب از همون استفاده کنید ولی اگه نیست، با همین ابزارهای موجود بسازین. باز هم میگم اگه برنامه نویس، برنامه نویس باشه (به معنای واقعی)، با همین PHP هم میتونه امن ترین سایت جهان رو بسازه. کار زیاد سختی هم نیست و یه سری اصول پایه ای داره که اگه رعایت بشه، حداقل جلوی 90 درصد هکرهای معمولی رو میگیره. همون عملگری که میگین مشکل داره رو اینطوری استفاده کنید ببینید درست میشه یا نه:
یعنی Literal رو بیارین اول. این روش توی خیلی از زبانهای دیگه هم توصیه شده.
if('hello' == $name) { ... }
یعنی Literal رو بیارین اول. این روش توی خیلی از زبانهای دیگه هم توصیه شده.
10-10-1394، 01:08 ق.ظ
(09-10-1394، 10:18 ق.ظ)ADMIN نوشته: [ -> ]همون عملگری که میگین مشکل داره رو اینطوری استفاده کنید ببینید درست میشه یا نه:الان وقت و حوصله ندارم همهء حالات رو دوباره پیدا و تست کنم. چون قبلا در این مورد زیاد تحقیق و تست و بحث کرده بودم و یادم شکل های مختلفی داشت که الان نسبت بهشون حضور ذهن کافی ندارم (معمولا آدم چیزای بی منطق و رندوم یادش نمیمونه!). بهرحال بعید میدونم این کار بتونه تمام موارد یا حتی بیشتر موارد رو حل بکنه، چون اگر اینطور بود که حتما قبلا در جریان تحقیق و اینها فهمیده بودم و در منابع بعنوان راهکار ارائه کرده بودن. ضمنا لزوما که یک طرف Literal نیست، ممکنه دو طرف متغییری چیزی باشن.
if('hello' == $name) { ... }
نقل قول:یعنی Literal رو بیارین اول. این روش توی خیلی از زبانهای دیگه هم توصیه شده.بله میدونم بارها در منابع و زبانهای مختلف این توصیه رو خوندم. ولی این روش در اصل بخاطر مسئله و خطای برنامه نویسی روشنی هست و نه بخاطر مسائلی مشابه اونچه در عملگر == پی اچ پی دیده میشه.
اینکه میگن Literal رو بذارید اول بخاطر اینه که در زبانهایی مثل C و PHP شما میتونی در قسمت شرط از assignment هم استفاده کنی، یعنی بجای == از = استفاده کنی، ولی خیلی وقتا برنامه نویسها صرفا یادشون میره این دو عملگر رو با هم اشتباه میکنن یا اشتباه تایپی میکنن و بجای == توی شرط = میذارن، که این باعث باگهای پنهان در برنامه میشه، چون زبان برنامه نویسی نمیتونه تشخیص بده هدف برنامه نویس در اصل چی بوده آیا قصدش مقایسه دو طرف بوده یا assignment. پس بخاطر کاهش احتمال این خطا میگن Literal رو سمت چپ بذارید (البته اینم صرفا در حالتی معنی داره که یک طرف Literal یا مثلا فراخوانی تابعی چیزی داشته باشیم و نه اینکه دو طرف متغییر باشن)، چون اینطوری اگر اشتباها بجای == از = استفاده بشه اونوقت این دستور از نظر سینتاکس زبان برنامه نویسی اشتباه است و 100% موقع کامپایل یا اجرا خطا میده و برنامه نویس متوجه اشتباه خودش میشه. ولی اگر سمت چپ متغییر باشه اونوقت مقدار سمت راست توی متغییر ریخته میشه و هیچ خطای سینتاکسی وجود نداره و شرط هم بسته به مقداری که توی متغییر ریخته شده ممکنه true یا false بشه.
ولی من خودم هیچوقت از این توصیه تبعیت نکردم! بنظر من یخورده مسخره میاد که برنامه نویس حواسش به این نکته باشه اما چطور اونوقت حواسش نیست که داره == میذاره یا =! مگر اینکه بگیم این یجورایی عادت دائمیش بشه، که بازم بنظر من کمی غیرمعقول و دست و پا گیر میاد.
بهرحال بنظرم میشه تمام کدها رو برای بررسی وجود این نوع خطا، با رگولار اکسپرشن های مناسب سرچ کرد که اگر موردی از زیر دست در رفته دربیاد.
10-10-1394، 09:16 ق.ظ
بهرصورت باز هم من سر حرف خودم هستم: چرا توی سایتهای ما چنین باگهای وحشتناکی که میگن وجود نداره؟ چرا هنوز هم بزرگترین سایتهای جهان که امنیت قابل قبولی هم دارن با PHP نوشته میشن؟ این نشون میده که با وجود نواقصی که توی طراحی وجود داره، باز هم برنامه نویس میتونه برنامه امن بسازه. اصلاً هم کار دردسرآفرینی نیست چون هرروزه داریم این کار رو انجام میدیم و اذیت هم نشدیم!
10-10-1394، 10:39 ق.ظ
(10-10-1394، 09:16 ق.ظ)ADMIN نوشته: [ -> ]بهرصورت باز هم من سر حرف خودم هستم: چرا توی سایتهای ما چنین باگهای وحشتناکی که میگن وجود نداره؟از کجا معلوم وجود نداره؟
شاید وجود داره ولی خودتون متوجه نشدید.
وجود حفره با کشف و سوء استفاده ازش برابر نیست.
بعدم من و شما شاید بنا به سطح ودانش و تجربهء خودمون، از یکسری موارد مطلع هستیم جلوگیری میکنیم، مثل منکه در پروژه هام دیگه از == استفاده نمیکنم، ولی به ازای ما دو نفر، 20 نفر دیگه هستن که متوجه این مسائل نیستن. خب شما میگی تقصیر خودشونه باید مطلع باشن، ولی اینطور شما فرق تعداد موارد امنیتی در زبانها رو نادیده گرفتی. مسلما زبانی که موارد خطرناک بیشتری داشته باشه، آمار حفره های امنیتی برنامه نویسانش هم در کل بالاتر میره. بعدم من به شخصه تقصیر برنامه نویس بیچاره نمیدونم که ندونه عملگر == در PHP چقدر غافلگیرانه عمل میکنه، چون چیز منطقی و قابل انتظاری نیست و توی تمام زبانهای دیگر هم چنین چیزی درموردش دیده نمیشه.
نقل قول:چرا هنوز هم بزرگترین سایتهای جهان که امنیت قابل قبولی هم دارن با PHP نوشته میشن؟بخاطر بازمتن بودن و رایگان بودن PHP و یکسری مزایای دیگر PHP رو انتخاب میکنن، که این مزایا در کل واسشون بر معایبش میچربه. بعدم چون خوب حرفه ای هستن خب میتونن امنیتش رو هم تامین کنن.
شما اینجا یه مسئله ای رو نادیده میگیرید. اونم میزان نیاز به حرفه ای بودن و دانش و تلاشی که برای تامین امنیت در هر زبانی نیازه. مسلما زبان تا زبان میتونه از این نظر تفاوت داشته باشه. اگر PHP اون طراحی های غلط رو نداشت، میزان نیاز به این حرفه ای بودن و دانش و تلاش کمتر میشد، که این باعث میشد آمار کلی ضعف در امنیت هم مقداری پایین تر بیاد.
حالا بله من و شما و شرکتهای بزرگ، افراد خبره، میتونن به پشتوانهء دانش و خبرگی زیادی که دارن و احتمالا کمی تلاش و هزینهء بیشتر، امنیت رو تامین کنن و به سطح قابل قبول برسونن، ولی خیلی های دیگه که اینطور نیستن نمیتونن و در نتیجه آمار حفره های امنیتی در تناسب با ویژگیهای خود زبان میتونه کم و زیاد بشه. البته این تنها عامل تاثیرگذار نیست، ولی سهم خودش رو در آمار داره.
نقل قول:این نشون میده که با وجود نواقصی که توی طراحی وجود داره، باز هم برنامه نویس میتونه برنامه امن بسازه. اصلاً هم کار دردسرآفرینی نیست چون هرروزه داریم این کار رو انجام میدیم و اذیت هم نشدیم!دردسر آفرین که هست. ولی بعد از مدتی که تجربه پیدا کردی و مسلط شدی اونوقت هست که تاحد زیادی ایمن میشی.
من خودم یادمه اولین برنامه ای که با PHP نوشتم دوستی داشتم که اومد یه مثال داد که *** بهش با یک URL خاص بسادگی برنامم رو منهدم کرد! من خیلی شوکه و ناراحت شدم، و وقتی کمی بررسی کردم فهمیدم که اینکه تونسته این کار رو بکنه بخاطر ویژگی register globals در PHP بوده. واقعا آیا register globals تقصیر من برنامه نویس بود؟ منکه فکر نمیکنم! حتی الان باوجود تخصص امنیتی که دارم میگم در درجهء اول تقصیر برنامه نویس نیست، بلکه در درجهء اول تقصیر طراحان زبان است. چون register globals یک طراحی ناشیانه بود و منطق آدم هیچوقت احتمال چنین چیزی رو نمیده.
حالا فرض کنید اون دوستم منو آگاه نمیکرد و من اون برنامه رو همونطوری مدتها در کارهای واقعی استفاده میکردم! خب نمونه همین میشه که آمار حفره های امنیتی رو بالا میبره.
آخرین مورد هم که همین رفتارهای غیرمنتظره عملگر == بود که باعث ایجاد حفرهء امنیتی در پروژم هم شده بود. مجبور شدم بخاطرش در تمام اون همه کد، == رو با === عوض کنم، و 100% مطمئن نیستم بخاطر این تغییر مشکلی در جایی از کدهام ایجاد نشده باشه (دیگه حال و حوصله و وقتش رو نداشتم تمام برنامه رو دوباره تست های جامعی بکنم).
بعدم گفتم که بهرحال خیلی حفره ها رو به آسونی و هرکسی نمیتونه کشف کنه. بعضیا رو عمدتا با مطالعهء کد میشه کشف کرد. بعضی وقتا تصادفی کشف میشن. اینکه شما خودت کشف نکردی کس دیگری هم ظاهرا کشف نکرده، حالا برای هرچند سال، دلیل نمیشه که لزوما وجود نداشته باشه! من بعنوان یه متخصص امنیت مثلا کی وقت دارم حال دارم واسه چی باید بیام کد و برنامهء شما رو بررسی کنم ضعفهای امنیتش رو دربیارم؟ هنوز وقت و حوصله ندارم پروژهء خودم رو هم کامل بررسی کنم! باید یه چیزی باشه ارزشش رو داشته باشه دلیل کافی براش باشه خب.