API2:2023 احرازهویت نادرست کاربر
| ضعف امنیتی | عوامل تهدید / مسیر حمله | پیامد |
|---|---|---|
| خاص API / قابلیت بهره‌برداری: آسان | میزان شیوع: متداول/ قابلیت تشخیص: متوسط | پیامد فنی: شدید / خاص کسب و کار |
| دسترسی همه به سیستم احراز هویت موجب می‌شود تا این مکانیزم هدفی آسان و در دسترس برای مهاجمین باشد. با اینکه برای بهره‌برداری از برخی از مشکلات احراز هویت ممکن است مهارت‌های فنی پیشرفته‌تری لازم باشد، ابزارهای بهره‌برداری مرتبط در دسترس هستند. | درک نادرست توسعه‌دهندگان نرم‌افزار و مهندسان امنیتی از مفاهیم مرتبط با احراز هویت و پیچیدگی پیاده‌سازی داخلی، منجر به اشتباهاتی در فهم چگونگی کارکرد و اهمیت مسائل احراز هویت می‌شود. این اشتباهات باعث می‌شود که مشکلات مرتبط با احراز هویت به طور گسترده‌تر و رایج‌تری در نرم‌افزارها و سیستم‌های مختلف پدیدار شود. روش‌ها و رویکردهایی برای شناسایی و تشخیص این نوع اشکالات در احراز هویت وجود دارد و تولید آنها نیز به طور کلی آسان است. به عبارت دیگر، می‌توان به راحتی ابزارها و روش‌هایی برای کشف و پیگیری مشکلات احراز هویت در نرم‌افزارها ایجاد کرد. | مهاجمین می‌توانند به حساب‌های کاربری سایر کاربران دسترسی یافته، اطلاعات شخصی آنها را خوانده و عملیات حساس (نظیر نقل و انتقالات مالی و ارسال پیام‌های شخصی) را از طرف آنها انجام دهد. |
آیا API از نظر احرازهویت نادرست کاربر آسیب‌پذیر است؟
نقاط، توابع و جریان‌های احرازهویت API دارایی‌هایی هستند که بایستی محافظت شوند. همچنین توابع «فراموشی گذرواژه یا بازیابی گذرواژه» نیز بایستی در زمره مکانیزم‌های احرازهویت در نظر گرفته شوند.
یک API از منظر احرازهویت نادرست کاربر، آسیب‌پذیر است اگر:
- اجازه حمله درج هویت را بدهد که در آن مهاجم از لیستی از نام‌های کاربری و گذرواژه‌های معتبر استفاده می‌نماید.
- بدون استفاده از مکانیزم‌های CAPTCHA یا قفل کردن حساب کاربری اجازه حمله Brute Force روی یک حساب کاربری را بدهد.
- اجازه استفاده از گذرواژه‌های ضعیف را بدهد.
- جزئیات و داده‌های حساس مرتبط با احرازهویت از قبیل توکن‌های اصالت سنجی و گذرواژه‌ها را از طریق URL ارسال نماید.
- اصالت توکن‌ها را به بوته آزمون نگذارد.
- توکن JWT ضعیف یا بدون امضا ({"alg":"none"}) را بپذیرد یا تاریخ انقضای آنها را اعتبارسنجی ننماید.
- از گذرواژه‌های آشکار ، رمزگذاری نشده یا درهم سازی شده بصورت ضعیف استفاده نماید.
- از کلیدهای رمزگذاری ضعیف بهره ببرد.
علاوه بر این، یک میکروسرویس آسیب‌پذیر است اگر: - میکروسرویس‌های دیگر بدون احراز هویت به آن دسترسی پیدا کنند. - از توکن‌های ضعیف یا قابل پیش‌بینی برای اعمال احراز هویت استفاده کند.
مثال‌هایی از سناریوهای حمله
سناریو #1
درج هویت (استفاده از لیستی از نام‌های کاربری یا گذرواژه‌های شناخته شده) حمله‌ای رایج است. اگر اپلیکیشن از مکانیزم‌های حفاظتی خودکار در مقابل تهدیداتی نظیر درج هویت بهره نبرده باشد، آنگاه اپلیکیشن می‌تواند بعنوان یک پیشگوی گذرواژه یا آزمونگر جهت بررسی صحت اطلاعات هویتی جهت عبور از مکانیزم احرازهویت بکار رود.
برای انجام احراز هویت کاربر، مشتری باید یک درخواست API مشابه مورد زیر را با اطلاعات ورود کاربر، صادر کند:
POST /graphql
{
"query":"mutation {
login (username:"<username>"password:"<password>") {
token
}
}"
}
سناریو #2
برای به‌روزرسانی آدرس ایمیل مرتبط با حساب کاربران، مشتریان باید یک درخواست API مانند درخواست زیر را ارسال کنند:
PUT /account
Authorization: Bearer <token>
{ "email": "<new_email_address>" }
چگونه از آسیب‌پذیری احرازهویت نادرست کاربر پیشگیری کنیم؟
- حصول اطمینان از آنکه تمامی جریان‌های ممکن برای احراز هویت API (موبایل یا وب، سایر لینک‌هایی که از مکانیزم احرازهویت با یک کلیک و غیره) شناسایی شده است. در این زمینه می‌توانید با توسعه دهندگان و مهندسین مشورت کنید.
- مطالعه و فهم کامل مکانیزم‌های احرازهویت استفاده شده در اپلیکیشن؛ بایستی درنظر داشت که OAuth و کلیدهای API نمی‌توانند بعنوان مکانیزمی برای احرازهویت به شمار آیند.
- در مساله احرازهویت، تولید توکن و ذخیره‌سازی گذرواژه، نباید چرخ را از ابتدا اختراع کرد بلکه بایستی از استانداردها استفاده نمود.
- توابع بازیابی یا فراموشی گذرواژه بایستی از منظر محافظت در مقابل Brute Force، محدودسازی نرخ و قفل شدن حساب کاربری هم ارز با توابع و نقاط ورود در نظر گرفته شود.
- برای عملیات حساس (مانند تغییر آدرس ایمیل مالک حساب/شماره تلفن مربوط به احراز هویت دو عاملی)، نیاز به احراز هویت مجدد می‌باشد.
- از راهنمای احرازهویت OWASP استفاده شود.
- بکارگیری احرازهویت چندعاملی ، در هر جا که امکان داشت.
- برای کاهش حملات درج هویت، Dictionary و Brute force، مکانیزم‌های ضد حمله Brute force را پیاده‌سازی کنید. این مکانیزم‌ها باید سخت‌گیرانه‌تر از مکانیزم‌های معمول محدودیت نرخ در APIها باشند.
- برای جلوگیری از حملات brute force بر روی کاربران خاص، مکانیزم‌های قفل کردن حساب کاربری و استفاده از CAPTCHA و برای افزایش امنیت، روش‌های شناسایی رمزهای عبور ضعیف نیز باید پیاده‌سازی شوند.
- کلیدهای API نباید برای احراز هویت کاربران استفاده شوند و تنها می‌بایست برای احراز هویت مشتریان API مورد استفاده قرار گیرند.