حملات زیادی در وب وجود دارد که در این مقاله قرار است به 10 تا از پرطرفدارترین و جدید ترین آن ها که در سال 2019 گزارش شده اند بپردازیم.

حمله ی اول: Broken Authentication and Session Management

این زمینه شامل کلیه جنبه های رسیدگی به احراز هویت کاربر و مدیریت نشست های فعال می باشد. احراز هویت جنبه اساسی این فرایند است ، اما حتی مکانیسم های تأیید اعتبار قوی می توانند توسط عملکردهای معتبر مدیریت اعتبار ، از جمله تغییر گذرواژه ، رمز عبورم را فراموش کرده ام ، رمز عبور من ، به روزرسانی حساب و سایر عملکردهای مرتبط را تضعیف کنند. از آنجا که حملات “walk by” برای بسیاری از برنامه های وب احتمالاً وجود دارد ، باید تمام عملکردهای مدیریت حساب نیاز به تأیید اعتبار مجدد داشته باشند حتی اگر کاربر شناسه نشست معتبری داشته باشد.

تأیید هویت کاربر در وب به طور معمول شامل استفاده از یک userid و رمز عبور است. روش های قوی تر تأیید اعتبار بصورت تجاری از جمله نرم افزارها و نشانه های رمزنگاری مبتنی بر سخت افزار یا بیومتریک موجود است ، اما چنین مکانیزم هایی برای اکثر برنامه های وب هزینه برانگیز است. طیف گسترده ای از نقص های مدیریت حساب و نشست می تواند منجر به اختلال حسابهای کاربری یا سیستم مدیریت شود. تیم های توسعه غالباً پیچیدگی های طراحی یک برنامه تأیید اعتبار و نشست مدیریت را که به اندازه کافی از اعتبار در تمام ابعاد سایت محافظت می کند ، دست کم می گیرند. برنامه های وب برای پیگیری جریان درخواست های هر کاربر باید نشست هایی ایجاد کنند. HTTP این قابلیت را ارائه نمی دهد ، بنابراین برنامه های وب باید خود آن را ایجاد کنند. بیشتر اوقات ، محیط برنامه وب امکان ساخت token های نشست را فراهم می کند ، اما بسیاری از توسعه دهندگان ترجیح می دهند آن را خود ایجاد کنند. در هر صورت ، اگر token های نشست به درستی محافظت نشوند ، یک مهاجم می تواند یک نشست فعال را ربوده و هویت کاربر را در دست بگیرد. ایجاد یک طرح برای ایجاد token های قوی نشست و محافظت از آنها در طول چرخه عمر خود ، برای بسیاری از توسعه دهندگان گریزان بوده است. مگر اینکه اعتبارنامه تأیید اعتبار و شناسه نشست ها در هر زمان با SSL محافظت شود.

راه های جلوگیری از این حمله:

محدودیت رمز عبور-کلمه عبور باید محدودیت هایی داشته باشد که حداقل به اندازه و پیچیدگی لازم برای رمز عبور نیاز داشته باشد. پیچیدگی به طور معمول نیاز به استفاده از حداقل ترکیبات حروف الفبا ، عددی و یا غیر الفبایی در رمزعبور کاربر (برای مثال حداقل یکی از آنها) دارد. کاربران باید ملزم به تغییر رمز عبور خود باشند. از استفاده مجدد از رمزهای عبور قبلی باید جلوگیری شود.

استفاده از رمز عبور – کاربران باید به تعداد مشخصی از تلاشهای ورود به سیستم در هر واحد محدود شوند و تلاشهای مكرر ورود به سیستم باید بررسی شوند. گذرواژه‌های ارائه شده در حین تلاش برای ورود به سیستم ناموفق نباید ثبت شوند ، زیرا این امر ممکن است رمز عبور کاربر را برای هر کسی که بتواند به این ورود دسترسی پیدا کند ، قرار دهد. در صورت عدم موفقیت یک ورود به سیستم ، سیستم نباید نشان دهد که آیا نام کاربری یا رمز عبور اشتباه بوده است. کاربران باید از تاریخ / زمان آخرین ورود موفق خود و تعداد تلاشهای دسترسی ناموفق به حساب خود از آن زمان مطلع شوند.

کنترل تغییر رمز عبور – یک مکانیزم تغییر رمز عبور باید در هر جایی که کاربران مجاز به تغییر رمزعبور باشند ، صرف نظر از شرایط ، مورد استفاده قرار گیرد. کاربران همیشه باید هنگام تغییر رمز عبور خود (مانند همه اطلاعات حساب) رمزعبور قدیمی و جدید خود را ارائه دهند. اگر گذرواژه‌های فراموش شده به کاربران ایمیل شود ، سیستم باید از کاربر درخواست کند که هر زمان کاربر آدرس ایمیل خود را تغییر داد ، مجدداً تأیید اعتبار کند ، در غیر این صورت مهاجمی که به طور موقت به جلسه خود دسترسی دارد به سادگی می توانید آدرس پست الکترونیکی خود را تغییر داده و درخواست کنید یک رمز عبور “فراموش شده” برای آنها ارسال شود.

ذخیره سازی گذرواژه – تمام رمزهای عبور باید به صورت هش شده یا رمزگذاری شده ذخیره شوند تا از قرار گرفتن در معرض حمله کننده ها ، بدون در نظر گرفتن محل نگهداری آنها ، محافظت شوند. فرم Hash شده ترجیح داده می شود زیرا برگشت پذیر نیست. گذرواژه‌ها را هرگز نباید در هیچ source code کدگذاری کنید. key های رمزگشایی باید به شدت محافظت شوند تا اطمینان حاصل شود که نمی توان آنها را گرفت و از رمزگشایی رمز عبور استفاده کرد.

محافظت از اعتبار در انتقال – تنها تکنیک مؤثر رمزگذاری کل تراکنش ورود به سیستم با استفاده از چیزی مانند SSL است. روش هایی مانند هشدار دادن به client قبل از انتقال ، امنیت کمی دارند زیرا نسخه hash شده به سادگی قابل رهگیری و ارسال مجدد است حتی اگر رمز عبور واقعی متن مشخص نباشد.

لیست حساب ها- سیستم ها باید طوری طراحی شوند که از دسترسی کاربران به لیستی از نام های حساب در سایت جلوگیری کند. اگر لیست های کاربران ارائه می شود ، توصیه می شود به جای آن ، نوعی نام مستعار (نام صفحه) که به حساب واقعی اشاره می کند، وارد شود. به این ترتیب ، نمی توان از نام مستعار در طی تلاش برای ورود به سیستم یا هک دیگری استفاده کرد.

حمله ی دوم: حملات Broken Access Control

کنترل دسترسی ، که گاهی اوقات به عنوان مجوز خوانده می شود ، به این صورت است که یک برنامه وب دسترسی به محتوا و کارکردهای برخی کاربران و نه همه را اعطا می کند. این بررسی ها پس از تأیید اعتبار انجام می شود و آنچه را که کاربران مجاز به انجام آن هستند انجام می دهد. کنترل دسترسی به نظر می رسد مانند یک مشکل ساده است ، اما اجرای صحیح آن بسیار دشوار است.
توسعه دهندگان غالباً دشوار بودن اجرای مکانیسم کنترل قابل اعتماد دسترسی را دست کم می گیرند. بسیاری از این طرح ها عمداً طراحی نشده اند ، اما به سادگی در کنار وب سایت تکامل یافته اند. در این موارد ، قوانین کنترل دسترسی در نقاط مختلف در سراسر کد درج شده است. با نزدیک شدن سایت به تاسیس ، مجموعه قوانین آن آنقدر بی پروا می شود که درک آن تقریبا غیرممکن است.
کشف بسیاری از این طرح های کنترل دسترسی دشوار نیست. غالباً ، همه آنچه لازم است این است که لیست توابعی را که عملکرها و یا محتواهایی که مفروض نیستند را شامل می شود، تهیه کنید. پس از کشف نقص ، عواقب یک طرح کنترل دسترسی ناقص می تواند ویران کننده باشد. علاوه بر مشاهده محتوای غیرمجاز ، یک مهاجم می تواند محتوا را تغییر داده یا حذف کند ، عملکردهای غیرمجاز را انجام دهد یا حتی مدیریت سایت را نیز به عهده بگیرد.
یک نوع خاص از مشکل کنترل دسترسی رابط های اداری است که به مدیران سایت اجازه می دهد یک سایت را از طریق اینترنت مدیریت کنند. چنین ویژگی هایی اغلب استفاده می شود تا به مدیران سایت اجازه دهند تا کاربران ، داده ها و محتوا را در سایت خود مدیریت کنند. در بسیاری از موارد ، سایتها از نقشهای مختلف مدیریتی پشتیبانی می كنند تا کارهای مدیریت سایت را دقیق تر انجام دهند. با توجه به قدرت آنها ، این واسط ها اغلب اهداف اصلی حمله توسط افراد خارجی و خودی هستند.

مهمترین مرحله این است که به طریق الزامات کنترل دسترسی یک برنامه فکر کنید و آن را در یک خط مشی امنیتی برنامه وب در نظر بگیرید. به شدت استفاده از ماتریس کنترل دسترسی برای تعریف قوانین کنترل دسترسی توصیه می شود. بدون مستند کردن خط مشی امنیتی ، تعریفی از امنیت آن سایت برای شما مشخص نشده است. این خط مشی باید مشخص کند که چه نوع از کاربران می توانند به سیستم دسترسی پیدا کنند ، و دسترسی به چه نوع کاربری و محتوایی به هر یک از این نوع کاربران امکان پذیر است. مکانیسم کنترل دسترسی باید به طور گسترده آزمایش شود تا اطمینان حاصل شود که هیچ راهی برای دور زدن آن وجود ندارد. این آزمایش نیاز به چندین حساب متفاوت و تلاش گسترده برای دسترسی به مطالب یا کارکردهای غیرمجاز دارد.

برخی از موارد کنترل دسترسی شامل موارد زیر است:

شناسه های ناامن – بیشتر وب سایت ها از نوعی شناسه ، کلید یا فهرست به عنوان روشی برای استفاده کاربران ، نقش ها ، محتوا ، اشیاء یا عملکردها استفاده می کنند. اگر یک مهاجم بتواند این شناسه ها را حدس بزند ، و اگر کاربر مقادیر را وارد نماید و اطمینان از مجاز بودن کاربر فعلی ، تأیید نشود ، مهاجم می تواند طرح کنترل دسترسی را آزادانه اعمال کند تا ببیند به چه چیزی می تواند دسترسی پیدا کند. برنامه های وب نباید به محرمانه بودن هر شناسه برای محافظت اعتماد کنند.

بررسی های اجباری کنترل دسترسی گذشته – بسیاری از سایت ها قبل از دسترسی به URL های خاص که معمولاً در عمق سایت قرار دارند ، به برخی کاربران نیاز دارند تا چک های خاصی را انجام دهند. این بررسی ها نباید توسط کاربرانی انجام شود كه با بررسی امنیتی به سادگی از صفحه عبور كرده اند.

Path Traversal – این حمله شامل ارائه اطلاعات مربوط به مسیر (به عنوان مثال ، “../../target_dir/target_file”) به عنوان بخشی از درخواست اطلاعات است. چنین حملاتی سعی می کند به پرونده هایی دسترسی پیدا کند که به طور عادی توسط کسی قابل دسترسی نیست ، یا در صورت درخواست مستقیم رد می شود. چنین حملاتی را می توان به آدرس های اینترنتی و همچنین هر ورودی دیگری که در نهایت به یک فایل دسترسی پیدا کنید (به عنوان مثال ، تماس های سیستم و دستورات پوسته) ارسال کرد.

مجوزهای فایل- بسیاری از سرورهای وب و برنامه ها به لیست های کنترل دسترسی ارائه شده توسط سیستم فایل سیستم عامل اصلی تکیه می کنند. حتی اگر تقریباً تمام داده ها روی سرورهای باطن ذخیره شده باشد ، همیشه فایلهایی که بصورت محلی در وب سرور و برنامه ها ذخیره می شوند وجود ندارد که نباید در دسترس عموم باشند ، به خصوص فایل های پیکربندی ، پرونده های پیش فرض و اسکریپت هایی که در اکثر وب سرورها و برنامه ها نصب شده اند. فقط فایل هایی که به طور خاص برای کاربران وب ارائه شده اند باید با استفاده از مکانیسم مجوز سیستم عامل قابل خواندن باشند.

این برنامه در یک تماس SQL که به اطلاعات حساب دسترسی دارد از داده های تایید نشده استفاده می کند:

12pstmt.setString(1, request.getParameter("acct"));
ResultSet results = pstmt.executeQuery( );

یک مهاجم پارامتر “acct” را در مرورگر اصلاح می کند تا شماره حساب مورد نظر خود را ارسال کند. اگر به درستی تأیید نشود ، مهاجم می تواند به هر حساب کاربری دسترسی پیدا کند.

1http://example.com/app/accountInfo?acct=notmyacct

یک مهاجم به سادگی مرورگر را مجبور می کند تا URL ها را هدف قرار دهد. برای دسترسی به صفحه مدیریت، راستی آزمایی مدیر لازم است.

12http://example.com/app/getappInfo
http://example.com/app/admin_getappInfo

اگر یک کاربر غیرمجاز بتواند به هر صفحه دسترسی داشته باشد ، این یک نقص است. همچنین اگر یک مدیر غیرمستقیم بتواند به صفحه مدیر دسترسی پیدا کند ، این یک عیب است.

حمله ی سوم: Security Misconfiguration

یکی از مسایل بسیار رایج در سامانه‎های آنلاین استفاده از تنظیمات ناامن و به‌ویژه تنظیمات پیش‌فرض است. در برخی موقعیت‌ها این تنظیمات بسیار خطرناک است و می‌توانند منجر به دسترسی مهاجم به سیستم شوند. تنظیمات ناامن محدود به بخش خاصی از سامانه نیست و می‎توانند در تمامی قسمت‎های برنامه اتفاق بیفتد.
این نوع از حملات سایت زمانی رخ می‌دهد که پیکربندی نادرست و ناصحیحی برای برنامه‌های کاربردی وب، قالب سایت، وب سرورها، بانک‌های اطلاعاتی و یا سیستم‌عامل‌ها تعریف‌شده باشد. ازآنجایی‌که تنظیمات پیش‌فرض ممکن است در امنیت سایت شما اختلال ایجاد نماید، باید به این مهم توجه داشته باشید که همیشه پیاده‌سازی و نگهداری تنظیمات به‌صورت سفارشی باعث کیفیت امنیت سایت خواهد بود؛ بنابراین همیشه سعی بر سفارشی‌سازی تنظیمات و همچنین به‌روزرسانی آن‌ها داشته باشید. همچنین اسکنرهای خودکار راهکار خوبی برای کشف این نوع آسیب‎پذیری هستند. مدیر سامانه باید از نصب هرگونه سرویس زاید اجتناب و به‎طور مرتب سرویس‎های لازم را به‎روزرسانی کند، هم‌چنین با تنظیمات امنیتی آن‌ها آشنا باشد.

حمله ی چهارم: (Cross-Frame Scriptting (XFS

این حملات هنگام انجام می شود که قربانی فریب داده شود و از طریق مرورگر خود به یک صفحه وب مخرب دسترسی پیدا کند. مهاجم مخرب که کنترل این صفحه را در دست دارد ، یک صفحه ثالثی را در قاب HTML بارگذاری می کند. یک keylogger مخرب JavaScript که ورودی های صفحه کلید قربانی را ضبط می کند و آنها را به سرور مهاجم ارسال می کند
این حملات، که با نام iFrame Injections نیز شناخته می شود ، خطرناک تر از تکنیک های سنتی فیشینگ است زیرا iFrame مورد استفاده کاملاً مشابه وب سایت هدف مورد استفاده برای فریب قربانی است. در حالی که این حملات به مهاجم مخرب و با تجربه نیاز دارد تا از باگ های بسیار خاص مرورگر سوء استفاده کند ، اما اثربخشی آنها بسیار زیاد است.
CxSAST در مورد تمام صفحاتی که می توانند در یک iFrame نمایش داده شوند ، شناسایی و هشدار می دهند ولی حاوی راه حل های محافظت XFS در محل نیستند.

حملات XFS با جلوگیری از frame شدن صفحه وب شخص ثالث ممکن است انکار شوند. تکنیک های استفاده شده برای انجام این کار همان روش هایی است که برای Clickjacking Protection برای Java EE استفاده می شود.

حمله ی پنجم: (Cross-site Scripting (XSS

حملات اسکریپت کراس سایت (XSS) نوعی تزریق است که در آن اسکریپت های مخرب به وب سایت های قابل اعتماد تزریق می شوند. حملات XSS هنگامی رخ می دهد که یک مهاجم از یک برنامه وب برای ارسال کد مخرب ، به طور کلی به شکل اسکریپت سمت مرورگر ، برای کاربر نهایی استفاده کند. نقص هایی که باعث موفقیت این حملات می شوند کاملاً گسترده هستند و در هر جایی که یک برنامه وب از ورودی توسط کاربر در خروجی تولید شده خود استفاده کند ، بدون تأیید یا اعتبار سنجی آن ، رخ می دهد.
یک مهاجم می تواند از XSS برای ارسال اسکریپت مخرب به یک کاربر استفاده کند. مرورگر کاربر نهایی راهی ندارد که بفهمد اسکریپت قابل اعتماد نیست و اسکریپت را اجرا می کند. اسکریپت مخرب می تواند به همه کوکی ها ، نشانه های نشست یا سایر اطلاعات حساس که توسط مرورگر حفظ شده و از آن سایت استفاده می کند ، دسترسی پیدا کند. این اسکریپت ها حتی می توانند محتوای صفحه HTML را بازنویسی کنند.

این آسیب‎پذیری قدیمی، حاصل تفسیر قسمتی از کدهای ورودی کاربر توسط مرورگر، بدون اعتبارسنجی مناسب است. در این حمله، مهاجم اسکریپت مخرب خود را با روش‌های مختلفی مانند ارسال یک URL با استفاده از ایمیل، بارگذاری در بخش‌های آسیب‌پذیر وب‌سایت و… برای کاربری دیگر  ارسال می‌کند و به ‌این ‌ترتیب می‌تواند کنترل مرورگر کاربر قربانی را در اختیار گیرد.

حملات اسکریپت کراس سایت (XSS) زمانی اتفاق می افتد که:

داده ها از طریق یک منبع غیرقابل اعتماد ، اغلب یک درخواست وب وارد یک برنامه وب می شوند.

داده ها در محتوای پویا وجود دارد که بدون تأیید برای محتوای مخرب به کاربر وب ارسال می شود.

محتوای مخرب ارسال شده به مرورگر وب اغلب به صورت بخشی از JavaScript می باشد اما ممکن است شامل HTML ، Flash یا هر نوع کد دیگری باشد که مرورگر ممکن است آن را اجرا کند. انواع حملات مبتنی بر XSS تقریبا بی حد است ، اما آنها معمولاً شامل انتقال داده های شخصی مانند کوکی ها یا سایر اطلاعات نشست به مهاجم ، هدایت قربانی به محتوای وب کنترل شده توسط مهاجم یا انجام سایر اقدامات مخرب در دستگاه کاربر می شوند(تحت پوشش سایت آسیب پذیر)

• ابزارهای تست خودکار و بررسی کد منبع از بهترین روش‎های کشف این آسیب‎پذیری هستند. این نوع آسیب‎پذیری برای از بین بردن مراقبت‎های آسیب‎پذیری‎های CSRF نیز استفاده می‎شود. پیاده‎سازی امن و حساس، نمایش داده‎های پویا در  چارچوب‎ها (Framework) و ساخت نرم‎افزارهای تحت وب از بهترین راه‎های جلوگیری از این نوع آسیب‎پذیری است. فعال‎سازی خط‎مشی امن محتوا Content Security Policy (یا همان CSP) نیز از دیگر روش‎های جلوگیری از این نوع آسیب‎پذیری است.

حمله ی ششم:Insecure Direct Object References

هنگامی که یک برنامه دسترسی مستقیمی به اشیاء مبتنی بر ورودی کاربر فراهم می کند ، رخ می دهد. به عنوان یک نتیجه از این آسیب پذیری ، مهاجمان می توانند مجوزها و دسترسی به منابع را در سیستم بطور مستقیم ، مثلاً سوابق یا پرونده های پایگاه داده ، دور بزنند.
این حمله به مهاجمان اجازه می دهد تا با تغییر مقدار پارامتر مورد استفاده برای اشاره مستقیم به یک شی ، مجوزها و دسترسی به منابع را مستقیماً دور بزنند. این منابع می توانند ورودی بانک اطلاعاتی متعلق به سایر کاربران ، پرونده های موجود در سیستم و موارد دیگر باشند. این اتفاق ناشی از این واقعیت است که برنامه ورودی کاربر را تأمین می کند و از آن برای بازیابی یک شی بدون انجام بررسی های مجوز کافی استفاده می کند.
برای جلوگیری از این روش باید یک تست را انجام داد:
تست کننده برنامه ابتدا باید نقشه جایگاه های موجود در برنامه را که در آن از ورودی کاربر برای ارجاع مستقیم اشیاء استفاده می شود ، مشخص کند. به عنوان مثال ، مکانهایی که از ورودی کاربر برای دسترسی به ردیف بانک اطلاعاتی ، پرونده ، صفحات برنامه و موارد دیگر استفاده می شود. در مرحله بعد تستر باید مقدار پارامتر مورد استفاده در ارجاع اشیاء را تغییر دهد و ارزیابی کند که آیا امکان بازیابی اشیاء متعلق به سایر کاربران وجود دارد یا خیر که در غیر این صورت مجوز را دور می زند.
بهترین روش برای ارجاع به منابع مستقیم با استفاده از حداقل دو کاربر (اغلب بیشتر) برای پوشاندن اشیاء و توابع مختلف است. به عنوان مثال ، دو کاربر هر کدام به اشیاء مختلف (مانند اطلاعات خرید ، پیامهای خصوصی و غیره) دسترسی دارند و (در صورت لزوم) کاربران با امتیازهای مختلف (به عنوان مثال کاربران admin) برای دیدن اینکه آیا منابع مستقیمی به عملکرد برنامه وجود دارد یا خیر به کار برده می شوند. تستر با در اختیار داشتن چندین کاربر ، در زمان آزمایش برای حدس زدن اسامی اشیاء مختلف صرفه جویی می کند زیرا می تواند برای دسترسی به اشیاء متعلق به کاربر دیگر تلاش کند و سیستم را به صورت کامل تست نماید.

حمله ی هفتم: HTTP Verb Tampering

حمله ای است که از آسیب پذیری های HTTP verb یا همان HTTP method و مکانیسم های کنترل دسترسی استفاده می کند. بسیاری از مکانیسم های تأیید اعتبار فقط دسترسی به متدهای متداول HTTP را محدود می کنند ، بنابراین دسترسی غیرمجاز به منابع محدود شده توسط سایر روشهای HTTP امکان پذیر است.
چنین مکانیسم های امنیتی شامل قوانین کنترل دسترسی برای درخواست هایی با روش های خاص HTTP است. به عنوان مثال ، یک مدیر می تواند یک سرور وب را پیکربندی کند تا با استفاده از درخواست های HTTP GET دسترسی نامحدود به یک صفحه وب امکان پذیر باشد ، اما POST ها را فقط برای administrator ها محدود می کند. با این حال ، بسیاری از پیاده سازی های مکانیسم های امنیتی مبتنی بر verb، قوانین امنیتی را به شیوه ای ناامن اجرا می کنند ، و با استفاده از روش های جایگزین HTTP (مانند HEAD) یا حتی رشته های کاراکتر های دلخواه ، دسترسی به منابع محدود را امکان پذیر می سازند.

به عنوان مثال ، Java Platform Enterprise Edition تأیید هویت مبتنی بر verb و کنترل دسترسی را از طریق فایل web.xmlconfiguration پشتیبانی می کند.

راه های جلوگیری از این نوع حمله:

حملات دستکاری لفظی از نقص تنظیمات در مکانیسم کنترل دسترسی یا آسیب پذیری در کد گیرندگان درخواست سوء استفاده می کنند. همانطور که در مثال بالا آورده شده است ، مسدود کردن درخواست هایی که از روشهای HTTP غیر استاندارد استفاده می کنند کافی نیست زیرا در بسیاری موارد مهاجم می تواند از روش HTTP قانونی مانند HEAD استفاده کند.

در ابتدا Imperva SecureSphere برای شناسایی و متوقف کردن حملات دستکاری verb، دو روش کاهش دهنده را ترکیب می کند. در وهله اول ، SecureSphere می آموزد که کدام روش برای هر URL مجاز است. هر تلاشی برای استفاده از روشهای HTTP که جزئی از استفاده عادی برنامه نیستند ، شناسایی و مسدود می شود.
روش دوم روشهای غیر استاندارد HTTP را تشخیص داده و با استفاده از چنین روشهایی درخواستها را مسدود می کند. در مواردی که برنامه به طور عادی از روشهای غیر استاندارد استفاده می کند ، این مکانیسم با روشهای مجاز به راحتی قابل استفاده است.

حمله ی هشتم: Using Components with Known Vulnerabilities

استفاده از اجزای (Component) ناامن در سامانه‎های آنلاین امری شایع است. اگر یکی از اجزای مورد استفاده دارای آسیب‎پذیری گزارش شده باشد، مهاجم به‌سادگی می‎تواند با استفاده از آن آسیب‎پذیری به سامانه حمله کند. بررسی و به‎روزرسانی اجزای استفاده شده در برنامه و تعریف این بررسی به‌عنوان یک فرآیند تکرارشونده، یکی از راه‎حل‎های جلوگیری از این آسیب‎پذیری است. استفاده از اسکنرهای خودکار به‎روز شده نیز روش مناسبی برای کشف این آسیب‎پذیری به‌شمار می‌آید.

حمله ی نهم: Information Leakage and Improper Error Handling

برنامه‎های تحت وب می‎توانند در حالت‌های مختلف اطلاعاتی از برنامه را نشت دهند که ممکن است برای حمله‎کننده مفید باشد. برنامه می‎بایست حداقل اطلاعات لازم را در اختیار کاربر قرار دهد. در برخی اوقات نیز
با استفاده از ترکیبی از این نوع آسیب‎پذیری، آسیب‎پذیری‎های جدی‎تری هم‌چون تزریق پرس‎وجوی ساختارمند برمبنای اشکال، ایجاد می‌شوند. برای جلوگیری از این آسیب‎پذیری تنظیمات سیستم باید به‌گونه‌ای انجام شوند که اشکالات به‌شکل کلی در اختیار کاربر قرار گیرد و از ارایه‎ی جزییات صرف نظر شود.

حمله ی دهم: (Cross Site Request Forgery (CSRF

نوعی حمله است که وقتی یک وب سایت مخرب ایمیل ، وبلاگ ، پیام فوری یا برنامه مخرب ایجاد می کند باعث می شود مرورگر وب کاربر هنگام احراز هویت کاربر اقدام به انجام یک عمل ناخواسته در سایت مورد نظر کند. حمله CSRF به این دلیل اتفاق میفتد که درخواست های مرورگر بطور خودکار هرگونه اعتبار مرتبط با سایت را شامل می شود ، از جمله کوکی نشست کاربر ، آدرس IP و غیره ، بنابراین ، در صورت احراز هویت کاربر به سایت ، سایت نمی تواند تفاوت بین درخواست جعلی یا قانونی را تشخیص دهد. به یک شناسه نیاز داریم که در دسترس مهاجمان نباشد و با درخواست های جعلی که مهاجم از آنها استفاده می کند ، ارسال نشود (مانند کوکی ها).

این آسیب‎پذیری سبب می‎شود تا حمله‎کننده بتواند فعالیتی ناخواسته را -به‎ویژه انجام فعالیتی که منجر به تغییر حالت سیستم شود- توسط قربانی (کاربر مجاز سیستم) انجام دهد. از بهترین روش‎های جلوگیری از این دسته ازآسیب‎پذیری‌ها، ایجاد توکن‎های موقت که نمی‌توان حدس زد و ذخیره‌ی آن‌ها در نشست (session) برای درخواست‎های کاربر مجاز و گذاشتن شرط انجام درخواست کاربر به صحت توکن است. برای یافتن این آسیب‎پذیری باید تمامی فعالیت‎های کاربرِ مجاز به این توکن‎ها مجهز باشند وگرنه، سامانه در برابر این تهدید آسیب‎ پذیر خواهد بود.

منبع:https://virgool.io