Transcript ‌تست امنیتی جاوا‌کارت

‫بسمه‌تعالی‬
‫تست امنیتی ریسک‌مبنا‬
‫‪1‬‬
‫رسول جلیلی‬
‫به ــار‪92‬‬
‫‪2‬‬
‫‪‬‬
‫مرور تکـ صفحه‌ای جل ـ ــسه قبلـ‬
‫‪‬‬
‫مباحث ـ ت ـسـت امنیتی ریسک‪-‬مبنا‬
‫‪ ‬معرفـی تست ریسک‌مبنا‬
‫‪3‬‬
‫‪ ‬تست نفوذ (تست در موقعیت عملیاتی)‬
‫‪ ‬جعبه‌سیاه ــی ولی با دو کاله‬
‫‪ ‬مفید و ضرو‌ ‌ری ولی دیــر‪ ،‬هزینه جبران باال‬
‫‪4‬‬
‫انجام هزار تست برای یافتن یک تهدید خوب می ارزد‬
‫‪Boris Beizer‬‬
‫‪‬‬
‫فتار برنامه‬
‫تست امنیت موضوعی ورای پویش پورت‌ها برای بررس ی ر ‌‬
‫‌تر ‌از تست جعبه‌سیاهی‬
‫نیاز به تستی خیلی عمیق ‌‬
‫‪‌ ‬‬
‫‪‬‬
‫حتی ورای تست کارکردی مکانیزم‌های امنیتی‬
‫‪‬‬
‫نظر گرفتن حقایق معمارانه‬
‫در ‌‬
‫ی تستر‌ها <<< ‌‬
‫نیاز به اتخاذ رویکرد ریسک‌مبنا ‌از سو ‌‬
‫‌‬
‫افکار حمله‌کننده‬
‫‌‬
‫سیستم بعالوه‬
‫‪‬‬
‫تمرکز کند‬
‫‌‬
‫تستر دقیقا می‌تواند روی بخش‌هایی ‌از کد که حمله روی آن موفق می‌شود‬
‫‌‬
‫بر اساس آنها‬
‫در سیستم ‌و خلق تست‌هایی ‌‬
‫<<< شناسایی ریسک‌ها ‌‬
‫‪5‬‬
‫‪6‬‬
‫•‬
‫تست‌های عادی نرم‌افزار (تست‌های غیر امنیتی) نگران رفتار نرم‌افزار در شرایط شکست (‪ )fail‬هستند‪.‬‬
‫•‬
‫بی آنکه به انگیزه‌ شکست توجه کنند‬
‫•‬
‫تست امنیتی نرم‌افزار (تست ایمنی نرم‌افزار) فرض بر حمله خصمانه دشمن هوشمند است‪.‬‬
‫•‬
‫بیشتر سیستم‌های به لحاظ ایمنی بحرانی و یا سیستم‌های با تضمین باال در دنیای کاله سفیدی سیر می‌کنند‪.‬‬
‫•‬
‫واقعیت چیز دیگری است‪ ،‬در دنیای ما کاله سیاه‌های زیادی هستند‬
‫•‬
‫حمله کننده توجهی ندارد که یک آسیب‌پذیری ناش ی از یک اشکال زمان پیاده‌سازی است یا یک عیب طراحی‬
‫<<< اشکاالت راحت‌تر‪ ،‬اکسپلویت می‌شوند‪ <<< .‬به همین نسبت عیوب طراحی سخت‌تر کشف و رفع‬
‫می‌شوند‪.‬‬
‫‪7‬‬
‫‪‬‬
‫نکته مثبت تست امنیتی مولفه‪ ،‬شکستن امنیت سیستم به بخش‌های جدا از هم ‪...‬‬
‫‪‬‬
‫از نظر تئوری‪ ،‬اگر هر مولفه ایمن پیاده‌سازی شده باشد و مسائل بین اجزاء را هم به لحاظ طراحی ‌رعایت‬
‫کرده باشد سیستم نهایی باید شکلی منطقی داشته باشد‬
‫‪‬‬
‫اما تست امنیتی باید در سطح سیستم نیز ادامه بیابد و سطح تجمیع شده را نیز در بر بگیرد‬
‫‪‬‬
‫نقطه تالقی تست نفوذ و تست امنیتی‬
‫‪‬‬
‫سناریو‌های سوء‌کاربردی که در زیست چرخه زودتر تهیه شده‌اند برای اغنای طرح های تست استفاده‬
‫می‌شوند‬
‫‪‬‬
‫همانقدر کاله‌سیاهی که کاله‌سفیدی!‬
‫‪‬‬
‫بزرگ‌ترین مشکل امنیتی نرم‌افزار<<<< نرم‌افزار‬
‫ورودی می گیرد‬
‫‪‬‬
‫سوالی که توسعه‌دهندگان باید به آن فکر کنند<<< آیا‬
‫می توان به ورودی اعتماد کرد؟‬
‫‪‬‬
‫بافر تا‬
‫اعتماد به ورودی ریشه اصلی مشترک از سرریز ‌‬
‫تزریق ‪ sql‬یا حتی ‪XSS‬‬
‫‪‬‬
‫نیاز به کنترل دقیق ورودی‬
‫‪‬‬
‫ابزارهای حمله تا حد زیادی روی ورودی تمرکز دارد‬
‫‪‬‬
‫البته تست نفوذ نیز روی ورودی ها تمرکز می کند‬
‫‪‬‬
‫رویکرد لیست سیاهی (برای نپذیرفتن ورودی های بد )‬
‫جواب نمی دهد نیاز است که همه ورودی ها را بجز‬
‫لیست سفید رد کند‬
‫‪8‬‬
‫‪ ‬تست ورودی مخرب الزم است ولی کافی نیست‬
‫‪ ‬تس تتت امنیت تتی همین تتین بای تتد ب تته داد ‌اس تتا تار اج تزا‬
‫سیستمی حالت برنامه و‪ ...‬توجه کند‬
‫فرا وا ‌یه تای‬
‫‪ ‬بجز توجته بته ریستا‌هایی کته هنتوز در سیستت بتاهی مانتدا استت تستت‬
‫امنیتی باید شامل موارد دیگری نیز باشد‬
‫› سوکت‌ها‬
‫› پایپ‌ها‬
‫› رجیستری‌ها‬
‫› فایل‌ها‬
‫› ‪ RPC‬ها‬
‫‪9‬‬
‫در د ‌و بعد ‪:‬‬
‫‪ ‬توجه به زمان ‌‬
‫اکثر پروتکل های‬
‫‪ .1‬بعد نخسست مرتبط با حالت برنامه است ( ‌‬
‫نرم‌افزاری‌ مدرن‌ بدون‌ حالت هستند)‪ .‬ها‌های مربوط به تغییر سادا‬
‫تغییر حالت برنامه‬
‫متغیرها برای ‌‬
‫غیر مستقی ‪ .‬هنگام به‬
‫نیز به حالت وابسته است اما ‌‬
‫‪ .2‬بعد دوم ‌‬
‫تار ‌و پرس‌وجوی‌ متغیرهای محیطی یا‬
‫اشتراک گذاری‌ یا دادا‌سا ‌‬
‫سری‌ حمالت معنا پیدا می‌کند‪ .‬حمالتی که چنین متغییرهایی ‌را بعد‬
‫تغییر می‌دهند ‪ .‬مثال ‪:‬حمله ‪TOCTOU‬‬
‫‌از زمان چا شد شان ‌‬
‫)‪(time to Check-Time to Use‬‬
‫‪ ‬چند ریسه ای موضوعی که بسیاری‌ برنامه نویسان ‌از اثرات ممکن‬
‫آن و حمالت زما ی مربوط بدان مطلع نیستند‬
‫‪10‬‬
‫‪11‬‬
‫‪‬‬
‫ی‬
‫سطح کار ‌‬
‫‪‬‬
‫زمان تست‬
‫‪ ‬تست نفوذ زمانی که نرم‌افزار کامل شده و در محیط عملیاتی نصب شد انجام می‌گیرد‪ .‬تستی‬
‫نسبتا مختصر به شمار می‌آید‬
‫‪ ‬تست امنیتی می‌تواند پیش از اتمام نرم‌افزار و در سطح مولفه‌ها انجام گیرد‪ .‬بنابراین محیط تست با‬
‫استفاده از موکل‌ها(‪ )stub‬و پیش از تجمیع است‪.‬‬
‫‪‬‬
‫رویکرد تست نفوذ کامال بیرون به درون ولی در اینجا هم بیرون به درون و هم درون به بیرون‬
‫‪.1‬‬
‫قبال گفتی که این رویکرد بر فرض توان تعریف مرز و محیط سیست‬
‫است <<<<فرض ی که همیشه درست نیست‬
‫‪.2‬‬
‫معماری سرویس‌مبنای امروزی ‪ <<< SOA‬هر ترافیکی روی‬
‫پورت ‪ 80‬عبور می کند <<< دیوار آتش ک ‌ک کارایی ود را از‬
‫دست واهد داد‪.‬‬
‫‪12‬‬
‫‪ ‬سازمان‌های تست استاندارد با رویکرد سنتی ؟؟‬
‫آنها فقط قادر به تست کارکردهای امنیتی هستند‬
‫‪ ‬دفاتر تضمین کیفیت سنتی ؟‬
‫آنها مشکالت بیشتری در این رابطه دارند‬
‫‪ ‬طراحی تست امنیتی دشوار است الزم است شبیه حمله‌کنندا فکر کرد‬
‫‪ ‬تست‌های امنیتی همیشه سبب اکسپلویت مستقیم نمی شوند‬
‫‪‬تست امنیتی ریسک مبنا بیشتر به تجربه امنیتی نیاز دارد (تا تجربه تست )‬
‫‪13‬‬
‫‪14‬‬
‫به منظور ارائه امکانات بیشتر تمایل تجاری به سمت کارت‌های ه ‌وشمند‬
‫پردازش‬
‫چندکاربری است که دارای نرم‌افزار مقیمی با ظرفیت نگه داری و ‌‬
‫رکوردهای بیشتری سبت به کارت‌های مغناطیس ی سنتی باشند ‌وجود دارد‬
‫‪‬‬
‫ی‬
‫کارت‌ها به طور‌ معمو ‌ل ‌از سیست رمزنگار ‌‬
‫پیییدا‌ای برای احر ‌از اصالت تراکنش‌ها ‌و‬
‫تایید هویت دارندا کارت استفادا می‌کنند‪.‬‬
‫ودکار کالس‌های کد‬
‫‌‬
‫تست سطح پایین ‌و‬
‫دستور‌های ممکنه ‌و کارکرد رمز‬
‫‪‬‬
‫موفقیت اغلب کارت‌ها‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫‪‬‬
‫اپلت‌های مخصوص جاواکارتی که برای‬
‫پیگیری‌ ابعاد با ریسا با ‌ال در ‪Global‬‬
‫‪ platform‬روی پیادا سازی‌ کارت‬
‫در وضعیت‌های‬
‫رفتن برنامه به حالت نامعلوم ‌‬
‫نیاز به ‪ roll back‬تراکنش و‬
‫مختلف که ‌‬
‫‪ ...‬دارد‬
‫در تست های‬
‫ناموفق بودن بسیاری‌ ‌از کارت‌ها ‌‬
‫غیر کارکردی‬
‫امنیتی ‌‬
‫‪15‬‬
‫‪ ‬سناریو های س ــوء کاربرد‬