دو روش پرکاربرد اعتبارسنجی در صفحه‌ی ورود و ثبت‌نام
کم‌تر وب‌سایت و سامانه‌ای دیده می‌شود که صفحه‌ی ورودی برای کاربران خود نداشته باشند. این صفحه دروازه‌ی ورودی کاربران به حساب کاربری خود و یا حتی ورود مدیران به صفحه مدیریت سامانه است. دو روش رایج که برای ثبت‌نام و ورود کاربران در سامانه‌ها مورداستفاده قرار می‌گیرند، عبارتند از:
• بر پایه‌ی گذرواژه
• سرویس OAuth
بر پایه‌ی گذرواژه
یکی از خطراتی که می‌تواند سبب نفوذ هکر از طریق ورود به سامانه بر پایه‌ي گذرواژه شود، استفاده از روش Brute-force، روشی مبتنی بر سعی و خطا، ست. در این نوع حمله، مهاجم تک‌تک کلیدهای دسته‌کلیدی که در اختیار دارد را، که همان نام‌های کاربری و گذرواژه‌های متفاوت هستند، بر روی دروازه لاگین امتحان می‌کند تا بالاخره یکی از آن کلیدها دروازه را باز کند.
برای مقابله با این روش نفوذ، لازم است:
• تعداد مجاز محدودی برای سعی مجدد، تکرار فرآیند ورود اطلاعات و لاگین، در یک بازه‌ی زمانی کوتاه تعیین شود.
• پروتکل‌ها و قوانین امنیتی بهتری برای انتخاب گذرواژه در نظر گرفته شود.
• وضعیت حساب کاربری‌ای که مورد حمله قرار گرفته است و هکر به دنبال نفوذ به آن است به حالت تعلیق در بیاید.
• آدرس IP مهاجمی که به طور مکرر در حال آزمایش نام کاربری و گذرواژه است، مسدود شود.
• برای جلوگیری از آزمایش‌های پی‌درپی نام کاربری و گذرواژه از کپچا استفاده شود.
همیشه از HTTPS استفاده کنید.
همان‌طور که می‌دانید ارتباطات در دنیای اینترنت بر پایه‌ی پروتکل‌هایی صورت می‌گیرند که مبدا و مقصد پیام ردوبدل‌شده‌ی بین خودشان را بهتر درک کنند. در ابتدا تنها پروتکل HTTP در محیط وب، مورداستفاده قرار می‌گرفت که نقص جدی‌ای به همراه داشت و سبب حملات مبتنی بر مرد میانی می‌شد. در حملات مرد میانی، هکر با استفاده از ابزارهایی مانند Wireshark مانند یک واسطه در بین ارتباطات رمزنشده‌ی بین کاربر و سرور مقصد قرار می‌گیرد و علاوه بر شنود هر بسته‌ی ارسالی، می‌تواند تغییرات دلخواه خود را روی آن اعمال و سپس به مقصد ارسال کند. بنابراین در این پروتکل، هکر قادر است که اطلاعات ردوبدل‌شده از جمله اطلاعات حساس کاربری هر کاربر را ببیند و با استفاده از همان اطلاعات به راحتی به حساب کاربری کاربر نفوذ کند.
اما اکنون و در سال‌های اخیر با معرفی پروتکل HTTPS حالا دیگر ارتباطات به طور رمزشده برقرار می‌شوند و دیگر اطلاعات به طور آشکار قابل‌خواندن نیستند. این همان دلیلی است که بسیاری را به استفاده از HTTPS ترغیب کرده است. در مطلب «کنترل ورودی کاربر، چرا و چگونه؟» می‌توانید درباره‌ی این پروتکل و نحوه‌ی راه‌اندازی آن بیشتر بخوانید.
روش OAuth چیست؟
اگر به صفحه‌ی لاگین بعضی از سایت‌ها دقت کرده باشید، علاوه بر فرم مربوط به ورود گزینه‌های دیگری نظیر ورود با گوگل، ورود با فیس‌بوک و ...را نیز می‌بینید که با کلیک بر روی آن‌ها ورود به سایت موردنظر از طریق حساب کاربری شما در گوگل و فیس‌بوک و ... صورت می‌گیرد. این روش یکی از امن‌ترین روش‌های ورود در سایت‌هاست اما در مواقعی که پیکربندی درستی صورت نگرفته باشد، می‌تواند تبدیل به راهی برای نفوذ هکرها به سامانه شود.
در احراز هویت به روش OAuth چه اتفاقی می‌افتد؟
به عنوان نمونه، کاربر از بین گزینه‌های موجود، ورود با گوگل را انتخاب می‌کند. سایت، سرویس OAuth خود را فرا می‌خواند و از کاربر برای دسترسی به داده‌های لازمی مانند آدرس ایمیلش درخواست مجوز می‌کند.
سایت موردنظر پس از اعطای مجوز کاربر به دسترسی به داده‌های لازم، رشته‌ای متنی و بلند با عنوان توکن دسترسی از یک نقطه دسترسی یا Endpoint مشخص از سایت دریافت می‌کند.
سپس، سایت ایمیل دریافتی را به عنوان نام کاربری ثبت می‌کند و توکن دریافتی را به عنوان گذرواژه ذخیره می‌کند.
همراه با پیاده‌سازی سرویس OAuth لازم است اطلاعات جامعی از نحوه‌ی کار این سرویس نیز داشته باشید. چراکه بسیاری از مشکلاتی که از این سرویس رخ می‌دهد، ناشی از عدم آگاهی کافی برنامه‌نویس از نحوه‌ی کار این سرویس هستند.
آسیب‌پذیری‌هایی که در این روش وجود دارند را می‌توان به دو بخش تقسیم کرد:
آسیب‌پذیری‌هایی که در سمت کاربر رخ می‌دهند:
• پیاده‌سازی اشتباه نحوه‌ی اعتبارسنجی کاربر
• CSRF ناقص
آسیب‌پذیری‌هایی که در سرویس OAuth رخ می‌دهند:
• نشت کدها و توکن‌های احراز هویت
• اعتبارسنجی ناقص scope
• ثبت‌نام کاربر تاییدنشده
پیاده‌سازی اشتباه نحوه‌ی اعتبارسنجی کاربر
در این آسیب‌پذیری که بر اثر پیاده‌سازی ناقص اعتبارسنجی کاربر رخ می‌دهد، توکن دسترسی از سرویس OAuth به سمت کاربر ارسال می‌شود. ارسال این توکن از طریق url انجام می‌شود و بدیهی است که قابل‌دیدن و در دسترس است. سمت کاربر با استفاده از روش‌های مختلفی از جمله استفاده از اسکریپت به زبان جاوا اسکریپت توکن را از url برمی‌دارد. حال اگر لازم باشد که کاربر حتی با بستن مرورگر نیز هم‌چنان لاگین باقی بماند، لازم است اطلاعات در جایی ذخیره شوند که معمولا آن اطلاعات، شناسه‌ی کاربر و توکن دسترسی هستند و در این شرایط ممکن است توکن دسترسی مورد سوءاستفاده قرار بگیرد.
برای حل این مشکل، معمولا درخواست‌های ارسالی به سرور سامانه از سمت کاربر با POST ارسال می‌شوند و چون سمت سرور توکن دسترسی را در اختیار ندارد نمی‌تواند توکن ارسال‌شده را با توکن صحیح تطبیق دهد. در این حالت، درخواست‌ها مانند روش مبتنی بر گذرواژه ارسال می‌شوند و عملا وجود سرویس OAuth زیر سوال می‌رود و مهاجم می‌تواند با تغییر اندکی در پارامترها به سادگی به سامانه لاگین کند و حتی دسترسی بالاتری هم نصیبش شود.
CSRF ناقص
بعضی بخش‌های سرویس OAuth اختیاری هستند اما بعضی پارامترها ضروری‌اند. مگر اینکه دلیل منطقی و مهمی برای استفاده‌نشدنشان وجود داشته باشد. یکی از این پارامترهای مهم، پارامتر state است.
مقدار این پارامتر باید غیرقابل‌حدس باشد. به همین خاطر مقدار آن را معمولا مقدار هش از عبارتی را قرار می‌دهند. این هش به طور مکرر بین سمت کاربر و سمت سرور به عنوان توکن CSRF تبادل می‌شود. اگر پارامتر state نباشد، آسیب‌پذیری مبتنی بر CSRF صورت می‌گیرد و مهاجم می‌تواند با استفاده از توکن CSRF کاربر که مقداری قابل‌دسترسی و قابل‌حدس خواهد بود به حساب کاربری کاربر نفوذ کند.
نشت کدهای احراز هویت و توکن‌های دسترسی
در این حالت مرورگر باید کد یا توکن دسترسی‌ای که از سمت شبکه‌ی اجتماعی به مرورگر برگردانده شده است را به آدرسی که در پارامتر redirect_uri مشخص شده ارسال کند تا سپس سامانه بتواند کاربر را لاگین کند. اگر سرویس OAuth نتواند به طور صحیح URI مشخص‌شده را اعتبارسنجی کند یا بشناسد، مهاجم می‌تواند با یک حمله از نوع CSRF، مقدار پارامتر redirect_uri را به آدرسی که خودش میزبانی می‌کند، تغییر دهد. مهاجم به این روش به توکن دسترسی پیدا می‌کند و می‌تواند با ارسال توکن به آدرس مشخص‌شده در redirect_uri اولیه که صحیح هم بود، به سامانه لاگین کند.
در این حالت، استفاده از پارامترهایی مانند state می‌تواند از این حمله جلوگیری کند؟ خیر، لزوما نمی‌تواند از این حمله جلوگیری کند. چون مهاجم می‌تواند مقادیر جدیدی را از سمت مرورگر خود تولید و جایگزین کند.
برای جلوگیری از این اتفاق، لازم است مرورگر زمانی که کد و یا توکن را دریافت می‌کند، پارامتر redirect_uri را نیز ارسال کند. هم‌چنین این پارامتر در تمام این درخواست‌ها و پاسخ‌ها ارسال شود. به این ترتیب این پارامتر در هر دو محل بررسی و انطباق داده شود تا در صورت تغییر آن، فرآیند تا انتها پیش نرود. حتی برای دقت بیشتر در یکتا بودن مقدار پارامتر redirect_uri می‌توان از بررسی بایت به بایت مقدار این پارامتر استفاده کرد.
به عنوان نکته‌ای دیگر برای جلوگیری از نشت کدها و توکن‌های دسترسی لازم است همیشه این نکته را مورد بررسی قرار دهید که آیا توکن دسترسی دریافت شده متعلق به client_idای است که درخواست را ارسال کرده است یا خیر.
اعتبارسنجی ناقص scope
گاهی اعتبارسنجی به وسیله‌ی سرویس OAuth فقط برای بخشی از سامانه است و توکن دریافت‌شده فقط برای دسترسی کاربر به بخش‌های محدودی از سامانه کاربرد دارد. در حالت عادی این موضوع یک چالش نیست اما در بعضی مواقع به دلیل نقص در پیاده‌سازی OAuth امکان ارتقای سطح دسترسی توکن وجود دارد و این بدین معنی است که مهاجم می‌تواند با ارتقای سطح دسترسی توکن به نقاط دیگر سامانه دسترسی پیدا کند.
ثبت‌نام کاربر تاییدنشده
هنگام اعتبارسنجی ورود کاربران پس از ثبت‌نام به وسیله‌ی OAuth، برنامه‌ی سمت کاربر فرض را بر این می‌گذارد که اطلاعات ذخیره‌شده توسط OAuth صحیح است و دیگر سایر اطلاعات مانند آدرس ایمیل را بررسی نمی‌کند. در این صورت مهاجم می‌تواند از طریق ثبت‌نام یک کاربر با اطلاعات کاربری مشابه با کاربر ثبت‌نام‌شده در سامانه با اطلاعات همان کاربر ثبت‌نام‌شده دیگر که از قبل ثبت‌نام شده بود، وارد سامانه شود.
سخن آخر
ما در این مطلب سعی کرده‌ایم خطرات پیاده‌سازی ناقص روش‌های مختلف اعتبارسنجی ثبت‌نام و ورود کاربران در یک سامانه را تا حد امکان ذکر کنیم. برخی از نقایص و آسیب‌پذیری‌های OAuth را که اغلب آن را بسیار امن می‌دانند، نیز برشمردیم. اهمیت ثبت‌نام و ورود در سامانه‌ها بسیار بالاست و قطعا امنیت مدام این دروازه‌ی بزرگ ورود به سامانه لازم است.
شما برای امنیت بیشتر دروازه‌ی ورود سامانه‌ی خود چه کرده‌اید؟