احراز هویت نقض شده - Broken Authentication

A2 2017
احراز هویت نقض شده - Broken Authentication
بردار حمله
App.Specific
قابلیت بهره برداری : 3

مهاجمان به صدها میلیون نام کاربری و رمز عبور برای استفاده به عنوان لیست کاربران ادمین پیش فرض، حملات پسورد خودکار و ابزارهای حمله دسترسی دارند.

ضعف امنیتی
شیوع : 2
قابلیت تشخیص : 2

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

تاثیرات
فنی : 3
تجاری ؟

مهاجمان برای نفوذ به یک سیستم باید به تعدادی حساب کاربری و یا یک حساب کاربری ادمین دسترسی پیدا کنند. بر اساس ناحیه برنامه، این می تواند منجر به پولشویی، کلاهبرداری امنیتی اجتماعی و سرقت هویت و یا انتشار اطلاعات بسیار حساس محافظت شده شود.

شناسایی آسیب پذیری

تاييد هويت کاربر، احراز هويت و مديريت نشست براي حفاظت در برابر حملات مبتني بر احراز هويت ، بسيار حائز اهميت است.
ضعف هاي آسيب پذيري وجود خواهند داشت اگر برنامه کاربردی:
* اجازه حملات خودکار را به مهاجم بدهد. مانند حملات جاسازی احراز هویت ، که
در آن مهاجم لیستی از نامهای کاربری و رمزهای عبور مجاز را در اختیار دارد.
* اجازه حملات خودکار رمز عبور یا حمالت خودکار دیگر را بدهد.
* اجازه ثبت رمزهای عبور پیشفرض، ضعیف یا شناخته شده مانند "Password1 "
یا admin/admin "را بدهد.
* از فرآیندهای ضعیف یا ناکارآمد بازیابی یا فراموشی احراز هویت مانند -پرسش و
پاسخ های دانشی- استفاده کند که امن نیستند.
* از داده های کشف، رمز یا هش شده با الگوریتم های ضعیف استفاده کند. )A3 :2017 را
ببینید(
* از روش های احراز هویت چند مرحله ای ناکارآمد استفاده کند.
* شناسه نشست در URL قابل مشاهده باشد. )مثل Rewriting URL)
* شناسه نشست پس از ورود موفق، تغییر نکرده باشد.
* شناسه های نشست تداوم نداشته باشند. نشست های کاربر یا توکن های احرازهویت (به خصوص توکن های SSO on-sign Single )در هنگام خروج از سیستم .

راه های جلو گیری

* برای جلوگیری از حمات Cracking GPU کلمه عبور را با استفاده از یک تابع هش مدرن یکطرفه، مانند Argon2 یا PBKDF2 ذخیره کنید.
* رمزهای عبور ضعیف را بررسی کنید، مانند تست گذرواژه های جدید یا تغییر یافته در برابر لیست 10000 رمز عبور بد.
* تنظیم طول رمز عبور، پیچیدگی و سیاست های تغییر با دستورالعمل های NISTB 63-800 
* اطمینان از امنیت فرآیند ثبت نام، بازیابی مشخصات کاربری، و مسیرهای API در برابر حمله ی Enumeration account با استفاده از پیام های مشابه برای تمام نتایج
* در صورت امکان، احراز هویت چند مرحله ای را برای جلوگیری از انواع حملات خودکار و سرقت اطالعات کاربری اعمال کنید
* تأیید هویت های ناموفق را ثبت کنید و هنگام تشخیص حمات به مدیران هشدار دهید
 

مثال هایی از سناریوهای حمله

سـناریو شـماره 1 :یـک نـرم افـزار از داده هـای نامطمئـن در سـاختار دسـتور فراخوانـی SQL آسـیب پذیر زیــر اســتفاده میکند:
String query = "SELECT * FROM accounts WHERE custID='" + request.
 + )"getParameter("id
;"'"
سـناریو شـماره 2 :به طـور مشـابه، اعتمـاد کورکورانـه نـرم افـزار در چارچـوب هـا، ممکـن اسـت منجـر بــه نمایــش داده هایــی کــه هنــوز آســیب پذیرنــد، شــود( بــه عنــوان مثــال،
 Query Hibernate
 :()Language (HQL
Query HQLQuery = session.createQuery("FROM accounts WHERE custID='" + request.
;)"'" + )"getParameter("id
در هـر دو مـورد، مهاجـم مقـدار پارامتـر id را در مرورگـر خـود بـه › یـا 1›=›1 ›تغییـر میدهـد و ارسـال میکنـد. بـرای مثـال:
1›=›or=› id?accountView/app/com.example://1http ‹ این مفهوم هر دو پرسش را تغییر میدهد 

منابع

OWASP

OWASP Risk Rating Methodology
Article on Threat/Risk Modeling


External

ISO 31000: Risk Management Std
ISO 27001: ISMS
NIST Cyber Framework

جزییات بازدید : 26

تاریخ انتشار : 23 / مرداد / 1398

آشنایی با مفاهیم هویتی، مجوزی و بازرسی در سیستم‌های کامپیوتری
قبل از آشنایی با حملات نقض احراز هویت و مدیریت نشست نیاز است تا با چندین اصطلاح و مفهوم خاص آشنا شویم. زمانی که درباره‌ی ورود کاربر یا کامپیوتر به سیستم‌ها بحث می‌کنیم، باید با سه مفهوم حسابرسی یا Accounting، صدور مجوز یا Authorization و احراز هویت یا Authentication آشنایی داشته باشیم و تفاوت این سه اصطلاح را در مبانی و فرایند انجامشان، درک نماییم.

احراز هویت یا Authentication
کاربر، کامپیوتر یا هر دستگاه دیگر، برای آنکه بتواند نقش خود را در یک سیستم شبکه یا وب اجرا نماید، باید ابتدا فرایند احراز هویت را برای تشخیص هویت خود انجام دهد. ازآنجایی‌که احراز هویت یکی از مهم‌ترین بخش‌های هر وب‌سایت است، باید به این مسئله اهمیت فراوانی در طراحی وب داده شود. برای درک بهتر مسئله احراز هویت یک مثال ساده و کاربردی را در ادامه بیان می‌نماییم.

فرض کنید شما کارمند یک سازمان هستید، زمانی که شما می‌خواهید وارد ساختمان سازمان خود شوید، باید در ابتدا کارت شناسایی خود را به حراست و نگهبانی آن ساختمان نشان دهید تا مجوز ورود به ساختمان سازمان را داشته باشید. در علوم کامپیوتر این کارت شناسایی همان نام کاربری و پسورد شما محسوب می‌شود و نشانه‌ی احراز هویت و شخصیت شما است. این مرحله از شناسایی شما توسط تیم حراستی و نگهبانی را می‌توان به‌عنوان بخش احراز هویت بیان نمود و در این مرحله هویت و شخصیت شما تشخیص داده خواهد شد. در اصطلاحات کامپیوتری به مرحله‌ای از ورود که هویت شما توسط سیستم تائید و احراز می‌گردد، احراز هویت یا Authentication گفته می‌شود.

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

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

حسابرسی یا Accounting
در سیستم‌های کامپیوتری بعد از احراز هویت و صدور مجوز، کاربر می‌تواند در داخل سیستم کامپیوتری فعالیت‌های خود را انجام دهد. مادامی‌که فرآیندهای بالا انجام می‌گیرد و کاربر در سیستم کامپیوتری فعال است، فرآیند نگهداری و بررسی فعالیت‌های کاربر را، بخش Accounting انجام می‌دهد. بخش Accounting مسئولیت بازرسی، ثبت عملیات انجام‌شده کاربر و ثبت عملیات Log در سیستم را بر عهده دارد.

هرکدام از سه فرآیند بالا دارای سیستم‌ها، فرآیندها و مکانیسم‌های گوناگونی هستند که در مقالات بعدی درباره آن‌ها توضیحات بیشتری خواهیم داد.


آشنایی با حملات احراز هویت و مدیریت نشست
حملات نقض احراز هویت و مدیریت نشست، شامل تمام جوانب راه‌اندازی یا Handling و دست زدن به احراز هویت کاربر و مدیریت نشست‌های ایجادشده توسط کاربر است. بااینکه احراز هویت یکی از جنبه‌های بسیار حیاتی در فرآیند شناسایی کاربران مجاز است؛ حتی مکانیسم‌های جامع و کامل امنیتی می‌توانند با توابع ناقص مدیریتی اعتبارنامه، ازجمله تغییر پسورد (Change Password)، فراموشی پسورد (Forgot Password)، به یادآوری پسورد (Remember Password)، به‌روزرسانی حساب کاربری (Account Upadte) و سایر توابع دیگر، درخطر مسائل امنیتی احراز هویت قرار گیرند. ازآنجایی‌که بسیاری از برنامه کاربردی وب در معرض حملات نقض احراز هویت و مدیریت نشست قرار دارند، باید تمام توابع مدیریتی حساب، حتی اگر کاربر دارای یک شناسه معتبر نشست باشد، مجدداً احراز هویت گردند.

احراز هویت در صفحات وب غالباً شامل استفاده از نام کاربری و پسورد می‌شود؛ اما مکانیسم‌ها و روش‌های قدرتمندتری مانند توکن های رمزنگاری نرم‌افزاری و سخت‌افزاری یا بیومتریکی (همانند بررسی عنبیه چشم) وجود دارند که بیشتر به‌صورت تجاری کاربرد دارند و هزینه این‌گونه احراز هویت برای برنامه‌های کاربردی وب توجیه اقتصادی نداشته و بیشتر صفحات وب از مکانیسم نام کاربری و پسورد برای احراز هویت استفاده می‌کنند.

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

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

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

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


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

یک نشست وب دنباله‌ای از مذاکرات درخواست‌ها (Request) و پاسخ‌های (Response) پروتکل HTTP شبکه است که برای یک کاربر خاص در نظر گرفته می‌شود. امروزه برنامه‌های کاربردی مدرن و پیچیده وب، نیازمند حفظ و نگهداری، اطلاعات و وضعیت در مورد هر کاربر، برای مدت درخواست‌های متعدد آن کاربر هستند؛ بنابراین نشست‌ها یا Sessions توانایی ایجاد متغیرهایی همانند حقوق دسترسی و تنظیمات محلی را فراهم می‌کنند که این متغیرها برای هر یک از مذاکرات و تعاملاتی که کاربر با برنامه کاربردی وب در مدت‌زمان نشست دارد، اعمال می‌شود.

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

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

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


شناسه نشست یا Session ID یا همان توکن نشست، اعتبارنامه‌های احراز هویت کاربر (به‌صورت یک نشست کاربر) را به ترافیک HTTP کاربر و کنترل دسترسی‌های مناسب اعمال‌شده توسط برنامه کاربردی وب، مرتبط می‌سازد. پیچیدگی این سه جز (احراز هویت، مدیریت جلسه و کنترل دسترسی) در برنامه‌های کاربردی وب مدرن و پیشرفته، باعث شده است که اجرای یک ماژول مدیریت نشست امن، بسیار چالش‌برانگیز باشد؛ زیرا اتصال و پیاده‌سازی نشست در دستان توسعه‌دهندگان و طراحان وب بوده و چارچوب یا Framework وب، ارتباطات دشوار بین این ماژول‌ها را فراهم نمی‌آورد.

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

افشا، ضبط (Capture)، بروت فورث (Brute Force) و یا تثبیت شناسه نشست، منجر به سرقت نشست‌ها می‌گردد و هکر با به دست آوردن نشست کاربر می‌تواند هویت قربانی را جعل نماید؛ بنابراین مدیریت نشست‌ها ازلحاظ امنیتی دارای اهمیت فراوانی است که باید طراحان به آن توجه فراوانی داشته باشند؛ زیرا با دزدیده شدن یک توکن نشست، هکر می‌تواند خود را در قالب کاربر جا زده و مشکلات امنیتی را در سیستم ایجاد نماید.

انواع حملات نقض احراز هویت و مدیریت نشست
حملات نقض احراز هویت و مدیریت نشست را می توان در موارد زیر دسته‌بندی کرد. در زیر به اختصار درباره انواع حملات نقض احراز هویت و مدیریت نشست اشاره‌شده است.


۱-حملات CAPTCHA Bypassing
اصطلاح کپچا یا همان Captcha که مخفف عبارت Completely Automated Public Turing test to tell Computers and Humans Apart است، یک نوع تست چالشی بوده که توسط بسیاری از برنامه‌های کاربردی وب مورداستفاده قرار می‌گیرد تا اطمینان حاصل شود که پاسخ توسط یک کامپیوتر یا ربات تولید نمی‌شود. کپچا به‌صورت کلی مکانیسمی است که برای جلوگیری از حملات به اعتبارنامه‌ها از آن استفاده می‌گردد و باعث می‌شود تا ربات‌ها و ابزارهای Brute Force نتوانند اعتبارنامه‌ها را به خطر بی اندازند.

گاهی خود این کپچاها دارای مشکلات امنیتی و آسیب‌پذیری‌هایی هستند که می‌تواند منجر به خطرات امنیتی گردند. برای مثال ممکن است کتابخانه‌های یکپارچه‌سازی کپچا ها که توسط ارائه‌دهندگان کپچا ارائه‌شده‌اند، تمام API های تائید کپچا را بر روی پروتکل HTTP به‌صورت متن ساده یا Clear Text برای انجام اعتبار سنجی کپچا ارسال نمایند و از رمزنگاری کپچا در کانال ارتباطی استفاده ننمایند.

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

گاهی تابع فراموشی پسورد موردحمله هکرها قرارگرفته و اعتبارنامه‌های کاربران را به خطر انداخته و هکر بتواند به وب‌سایت نفوذ نمایند.

۳-حملات Insecure Login Forms
در برنامه‌های کاربردی وب، با توجه به طیف گسترده‌ی حملات از طریق پروتکل HTTP، ارائه فرم‌های ورود به سیستم، از طریق پروتکل HTTP بسیار خطرناک خواهد بود و ممکن است به استخراج رمز عبور بیانجامد؛ بنابراین پروتکل HTTPS برای محافظت از داده‌های کاربر در مقابل استراق سمع، اصلاح و ویرایش در شبکه‌ها طراحی‌شده است. وب‌سایت‌هایی که داده‌های کاربران را مدیریت می‌کنند باید حتماً از پروتکل HTTPS استفاده نمایند تا بتوانند از اطلاعات کاربران در مقابل هکرها جلوگیری نمایند.

این نوع حملات در فرم‌های ورود کاربران وجود دارد و علت به وجود آمدن آن‌ها، در ناامن بودن فرم‌هایی است که از پروتکل امن استفاده نمی‌نمایند. برای مثال، گاهی وقت‌ها در بعضی سایت‌ها هنگامی‌که می‌خواهید نام کاربری و پسورد را وارد نمایید با پیغام Logins entered here could be compromised از طرف مرورگر روبرو می‌شوید؛ که نشان از ناامن بودن فرم است.

۴-حملات Logout Management
در این مرحله باید بررسی نماییم که عملکرد خروج از سیستم به‌درستی اجراشده باشد و پس از خروج از نشست، امکان احیا و استفاده مجدد از نشست وجود نداشته باشد. پایان یک نشست وب توسط یکی از دو رویداد زیر خواهد بود.

۱-کاربر از سیستم خارج می‌شود.

۲- کاربر برای مدت‌زمان مشخصی بیکار می‌ماند و برنامه کاربردی وب به‌صورت خودکار او را از سیستم خارج می‌کند.

هر دو مورد بالا باید با دقت اجرا شود تا از نقض‌ها و ضعف‌هایی که ممکن است توسط هکر برای دسترسی غیرمجاز مورد سوءاستفاده قرار گیرد، جلوگیری شود. در عملکرد خروج باید اطمینان حاصل شود که تمام توکن های نشست (مثلاً کوکی‌ها) به‌درستی نابود می‌شوند و یا دیگر غیرقابل استفاده نیستند و کنترل‌های مناسب در سمت سرور برای جلوگیری از استفاده مجدد توکن های نشست انجام شود.

اگر چنین اقداماتی به‌درستی اجرا نگردد، هکر می‌تواند نشست‌های جلسه را به‌منظور احیا و بازگردانی جلسه‌ی یک کاربر قانونی، بکار گیرد و هویت کاربر را جعل نماید. این نوع حمله معمولاً به‌عنوان بازنگری کوکی نیز شناخته می‌شود.


۵-حملات Password Attacks
در این نوع از حملات نقض احراز هویت و مدیریت نشست، هکر با استفاده از حملات آنلاین، شروع به حدس زدن پسورد به کمک ابزارهای خاص نموده و به دلیل ضعف در مکانیسم‌های درست امنیتی، هکر پسورد صحیح را حدس زده و در سیستم نفوذ نمایید. در جهت جلوگیری از حملات حدس پسورد یا همان Brute Force، باید مکانیسم‌هایی همچون کپچاهای امنیتی، برای صفحات اعتبارنامه در نظر گرفته شود تا هکر نتواند حملات حدس پسورد را با استفاده از ابزارهای Brute Force انجام دهد.

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

برنامه‌های کاربردی وب هرچند ازلحاظ امنیتی قدرتمند باشند؛ اما یک پسورد ضعیف می‌تواند کل امنیت برنامه کاربردی را زیر سؤال برده و هکر با حدس پسورد ضعیف به سیستم نفوذ نمایید.

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

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

۷-حملات Administrative Portals
در غالب صفحات وب، برنامه نویسان و طراحان سعی بر این دارند که با توجه به مکانیسم‌های خاص، صفحه مدیریتی سایت را از دسترس هکران و نفوذ گران دورنگه دارند. در یک مثال ساده، مدیران سیستم محتوای وردپرس سعی دارند دایرکتوری WP-Admin را از دسترس عموم خارج نگه‌دارند تا هکر نتواند به این صفحه دسترسی پیدا نماید. در این نوع حملات نقض احراز هویت ، هکر با استفاده از مکانیسم‌های خاص ازجمله مشاهده URL ها شروع به دور زدن این محدودیت‌ها کرده و در تلاش برای دستیابی پنل مدیریتی وب‌سایت خواهد بود.

۸-حملات Cookies (HTTPOnly)
HttpOnly یک پرچم یا Flag اضافی است که در کوکی تنظیم‌شده‌ی هدر پاسخ HTTP وجود دارد. استفاده از پرچم HttpOnly در هنگام تولید کوکی، کمک می‌کند تا ریسک حملات اسکریپت نویسی فراوبگاهی یا همان حملات XSS در دسترسی به کوکی محافظت‌شده کاهش یابد؛ و این در صورتی است که مرورگر بتواند پرچم HttpOnly را پشتیبانی نماید.

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

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

پرچم HttpOnly برای پیشگیری و جلوگیری از حملات Injection و سرقت نشست‌ها استفاده می‌شود. درمجموع می‌توان این پرچم را به‌عنوان لایه‌ای برای ایمن‌سازی کوکی‌ها و نشست‌ها در نظر گرفت.

۹-حملات Cookies (Secure)
یکی دیگر از پرچم‌های استفاده‌شده در کوکی‌ها، پرچم Secure است که برنامه نویسان باید در طراحی‌های خود بااهمیت خاص این پرچم آشنا بوده و از آن به‌درستی استفاده نمایند. پرچم Secure برای جلوگیری و مقابله با شنود و ضبط کوکی‌ها و انتقال امن آن‌ها استفاده می‌شود. این پرچم باعث می‌گردد تا از ارسال کوکی بر روی ارتباطات ناامن جلوگیری گردد. زمانی که یک درخواست به صفحه امن HTTPS ارسال می‌شود، مرورگرهایی که از پرچم Secure پشتیبانی می‌نمایند، کوکی‌ها را تنها با پرچم Secure ارسال می‌کنند و در حالت دیگر، مرورگر، کوکی را با پرچم Secure که بر روی یک درخواست HTTP رمزنگاری نشده است، ارسال نمی‌نماید. با استفاده از پرچم Secure، مرورگر از انتقال کوکی به یک کانال رمزنگاری نشد، ه جلوگیری خواهد نمود.

۱۰-حملات Session ID in URL
گاهی برنامه نویسان و طراحان، برنامه کاربردی وب را طوری طراحی می‌نمایند که شناسه نشست یا همان Session ID از طریق URL برای کاربر ارسال شود. این‌گونه طراحی در صفحات وب بسیار اشتباه بوده و باعث حملات سرقت نشست خواهد شد و هکر می‌تواند از طریق URL سایت، شناسه نشست‌ها را به سرقت برده و خود را به‌عنوان کاربر احراز هویت شده جا زده و اطلاعات حساس کاربر را در معرض خطر قرار دهد.

۱۱-حملات Strong Sessions
درحالی‌که مدیریت نشست مبتنی بر وب، برای ردیابی و ناوبری کاربران در برنامه کاربردی وب بسیار حائز اهمیت است، استفاده از نشست، باید همراه با الزامات خاص خود نیز همراه باشد. بسیاری از برنامه‌های کاربردی وب که دارای اطلاعات حساس و حیاتی هستند، باید مکانیسم‌های قدرتمندی را برای جلوگیری از حملات نقض احراز هویت و مدیریت نشست پیاده‌سازی نمایند. بر اساس تحقیقات، برخی از رایج‌ترین موارد نقص در مدیریت نشست در چهار مورد زیر بیان‌شده‌اند.

۱-شناسه نشست قابل پیش‌بینی بوده است.

۲-انتقال ناامن نشست‌ها باعث این حملات نقض احراز هویت و مدیریت نشست بوده است.

۳-مدت‌زمان یا طول مدت اعتبار نشست به‌صورت دقیقی تنظیم‌نشده است.

۴-تائید یا verify نشست صورت نپذیرفته است.

بنابراین، در جهت جلوگیری از حملات نقض احراز هویت Strong Session ، باید حتماً چهار مورد بالا در طراحی‌ها و برنامه‌نویسی‌ها در نظر گرفته شود تا بتوانیم از قدرتمند بودن یک نشست در جهت جلوگیری از سرقت آن توسط هکر، اطمینان حاصل نماییم.