پنج خطر و نکته در هنگام تأمین علائم تأیید اعتبار کاربر

جرایم سایبری در حال تشدید است - و این یک مسئله بزرگ برای شرکت هایی است که داده های حساس کاربر را اداره می کنند.

این یک خطر و واقعیت برای شرکت های بین المللی ثروت (به عنوان مثال Quora. com و Marriot) با دسترسی به میلیون ها سوابق کاربر است - تجربه نقض داده های حساس و حساس. حتی اگر این دهه گذشته را به عنوان "عصر طلایی" فناوری در نظر بگیریم ، حقیقت این است که هیچ یک از فنی جدید ، مسئله خطای انسانی را برطرف نمی کند. در حالی که استفاده از جدیدترین فناوری ممکن است به شدت توصیه شود ، درک نکردن نحوه عملکرد این فناوری ، مسائل امنیتی احتمالی و اصول اولیه شیوه های توسعه ایمن نیز یک مشکل بزرگ است. احراز هویت و مدیریت جلسه کاربر به ویژه مناطق آسیب پذیر هستند. اگرچه آنها بسیاری از راه حل ها و پیاده سازی های پیش ساخته دارند ، اما چنین آسیب پذیری ها هنوز لیست "OWASP 10 خطرات امنیتی برنامه وب" را در مورد مهمترین انواع آسیب پذیری های برنامه های وب امروز ایجاد می کنند. اخیراً تأیید اعتبار کاربر و نقاط ضعف مدیریت جلسه حتی با یک مدال نقره به دلیل بزرگترین تهدید برای امنیت برنامه ، "مورد تقدیر" قرار گرفت. نشانه های احراز هویت یکی از مهمترین عوامل هنگام کار با کاربران ثبت شده برنامه است. این خطوط خاص به طور تصادفی تولید شده برای تأیید اعتبار کاربران پس از ورود به اعتبار ورود به سیستم خود استفاده می شود. بدون نشانه ها ، کاربران باید در هر عمل معتبر که بسیار ناراحت کننده است ، اعتبار خود را وارد کنند. از آنجا که نشانه ها یکی از ویژگی های اصلی در مکانیسم احراز هویت هستند ، شکی نیست که آنها یکی از بردارهای برتر حمله و تحقیقات برای جرایم سایبری هستند که سعی در سازش مکانیسم احراز هویت پورتال دارند.

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

1شما از نشانه های قوی استفاده نمی کنید.

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

برخی از قوانین کلی برای تولید نشانه های قوی:

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

طرفداران

• ارسال اسرار مختلف تولید شده به طور خودکار (بی رحمانه) برای حدس زدن نشانه های تأیید اعتبار ، مدت زمان بسیار طولانی طول می کشد.
• آخرین چارچوب های محبوب معمولاً در حال حاضر دارای ماژول های از پیش ساخته شده و تولید نشانه های قوی هستند ، بنابراین نیازی به اختراع چرخ نیست.

منفی

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

2شما با یک اتصال باز حمل می کنید

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

فرض کنید تمام صفحات وب شما تحت پروتکل HTTPS قرار دارند ، اما به دلایلی فکر کردید که بارگیری آن تصویر خاص (یا پرونده سبک) در کانال باز بسیار بهتر خواهد بود. در پایان ، اگر انبارهای توکن به درستی ایمن نباشند ، یک مهاجم می تواند اسرار تأیید هویت شما را فقط با نگاه کردن به آن درخواست های پرونده اضافی بدون نیاز به شکستن قفل کلمه کاربری ، سرقت کند.

3ذخیره توکن شما ضد گلوله نیست.

هنگامی که امنیت برنامه در صدر لیست است ، باید نشانه ها را در فضای ذخیره سازی کوکی ذخیره کنید. دو ویژگی ویژه کوکی در ذهن عبارتند از:

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

قوانین مسیر را برای کوکی ها تعیین کنید. اضافه کردن سیاست سختگیرانه تر مسیر (همان سایت) نیز می تواند کمک کند. اگر وب سایت اصلی شما (به عنوان مثال به عنوان مثال. com) ممیزی قبل از تولید را پشت سر گذاشت و کسی فراموش کرد که ویژگی دامنه صحیح را برای کوکی ها قرار دهد ، هکرها می توانند در صورت داشتن وب سایت زیر دامنه نه چندان مطمئن ، این نشانه را دزدی کنند (به عنوان مثال Help. exame. example.. com) در کنار هم میزبان است.

طرفداران

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

منفی

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

4شما زمان انقضا را مدیریت نمی کنید.

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

تکنیک های انقضا خودکار توکن از جمله:

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

مطلق - این را به عنوان زمان ضمانت برای نشانه تأیید اعتبار کاربر فکر کنید. مهم نیست که به دلایل امنیتی ، پس از هر دوره طولانی (به عنوان مثال ، 24 ساعت) ، هر نشانه ای باید خاتمه یابد و کاربر باید مجبور شود دوباره وارد سیستم شود.

تجدید-اگر کاربر فعال باشد ، نشانه تأیید اعتبار باید به طور خودکار هر 10-15 دقیقه تجدید شود. در صورت حمله به سرقت واحد ، زمان اقدام به آسیب رساندن به حداقل می رسد.

انقضا توکن دستی از جمله:

دکمه Logout - همیشه وقتی کاربر روی دکمه Logout کلیک می کند ، جلسه کاربر را نابود کنید. به این ترتیب دوباره از همان نشانه استفاده نمی شود (یا حتی بدتر ، به موازات موارد جدیدتر).

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

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

در نظر بگیرید که کاربران را ملزم به تأیید مجدد مجدد کنید.

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

5به کاربر اجازه می دهید همزمان چندین ورود به سیستم داشته باشد.

هنگام فکر کردن در مورد مدیریت هویت ایمن ، این می تواند به معنای داشتن تجربه کاربری کمتری در بعضی مواقع باشد.

برای سیستم های قوی ، تأیید اعتبار موازی را برای همان کاربر در نظر بگیرید. از دیدگاه اجرای ، ما گزینه های مختلفی برای اصلاح این موضوع داریم. یک روش ساده برای پرداختن به مشکلات تأیید اعتبار موازی ، ذخیره ویژگی های موقت در جایی در داخل ردیف کاربر در یک پایگاه داده یا حافظه نهان است. چند نمونه شامل "logged = true" و "عامل کاربر = یعنی 11. 1. 1" (یا حتی ممکن است نشانه فعال) باشد. ذخیره ویژگی های کلیدی می تواند به اطمینان حاصل شود که هرگز به طور همزمان توسط دو نفر مختلف از حساب استفاده نمی شود. بدیهی است ، اگر این اتفاق بیفتد ، باید کسی بیرون بیاید.

نکات کلیدی که باید در هنگام تأیید اعتبار موازی برای کاربران در نظر بگیرید:

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

به طور کلی ، قبل از اجرای محدودیت های احراز هویت ، در مورد آنچه برای مشتریان برنامه شما مهمتر است - راحتی یا امنیت. و اگر این دومی است ، دریغ نکنید که اقدامات شدید در مورد اجرای تأیید هویت موازی انجام دهید.

در مورد احراز هویت بدون تابعیت مدرن چیست؟

در این بخش ، من روی Tokens Web JSON (JWT) تمرکز خواهم کرد زیرا آنها در حال حاضر بیشترین استاندارد Token Token برای دستیابی به احراز هویت بدون تابعیت هستند. از دیدگاه امنیتی ، یکی از مهمترین قطعات JWT اسرار هشدار دهنده است.

برخی از ملاحظات برای استفاده از اسرار هشویی قوی عبارتند از:

• حدس زدن آنها تقریباً غیرممکن است - به طرز وحشتناکی طولانی و تصادفی.
• توسعه دهندگان باید استفاده از اسرار متعدد را برای محیط های مختلف در نظر بگیرند.
• آنها فقط باید از طرف سرور قابل مشاهده و عملی باشند تا ربودن و استفاده از داده ها برای تولید توکن سفارشی غیرممکن باشد.

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

یکی دیگر از جنبه های چالش برانگیز JWT ، رسیدگی به انقضا است. چگونه می توانید این نشانه را باطل کنید ، هنگامی که زمان انقضا ثابت در خود است و بدون شکستن قوام نشانه ها قابل تغییر نیست؟برای پرداختن به چالش های انقضا JWT ، این دو راه حل را در نظر بگیرید:

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

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

اگرچه ممکن است نشانه های JWT یک مکانیزم مناسب در هنگام بی تاب بودن در نظر گرفته شود ، اما ممکن است آنها را ردیابی کنید (داشتن "نوعی حالت") روی سرور ممکن است ارجح باشد.

اقدام کنید و داده ها را ردیابی کنید.

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

منابع