خطر پیکربندی Multi-SSO در AWS Cognito
خلاصهٔ کاملتر
AWS Cognito در پروژههای SaaS مدرن اغلب با یه User Pool مشترک برای همهی tenantها پیاده میشه، در حالی که هر tenant IdP (Identity Provider) خودش رو داره. این معماری انعطافپذیره، ولی لایههای پیچیدهای از منطق هویت ایجاد میکنه که اگه اشتباه پیادهشه، باگهای امنیتی جدی به بار میآره.
Lambda Triggerها توی Cognito نقش دروازهبان رو دارن: قبل از ساخت کاربر، بعد از تأیید، قبل از احراز هویت و... هر کدوم در یه مرحلهی مشخص اجرا میشن. نکتهی مهم اینه که PreSignUp تنها Trigger ایه که قبل از ذخیرهی رکورد کاربر در pool اجرا میشه. اگه چکهای امنیتی اینجا درست تعریف نشن، کاربر قبل از هر بررسی دیگهای توی سیستم ثبت میشه.
آسیبپذیری اول — تزریق هویت جعلی (Ghost Identity): یه مهاجم میتونه یه IdP مخرب ثبت کنه و با ایمیل attacker@company.com فدرال بشه. اگه PreSignUp_ExternalProvider چک دامنه رو اجرا نکنه، Cognito رکورد کاربر رو ذخیره میکنه. بعد از اون حتی اگه JIT provisioning جلوی session رو بگیره، اون رکورد در pool باقی میمونه و میشه باهاش تعامل داشت — مثلاً با reset اجباری پسورد یا impersonation.
آسیبپذیری دوم — Sub-Splitting Attack: کلید هویت داخلی Cognito برای کاربران فدرال فرمت ProviderName_sub داره. از اونجا که sub توسط IdP کنترل میشه و میتونه شامل _ باشه، اگه دو قسمت مختلف کد با ایندکسهای متفاوت این رشته رو split کنن، به نتایج متفاوتی میرسن:
# کاربر ارسال میکنه: sub = "EVIL_noise_internal@company.com"
# Trigger یکم (چک یکتایی):
sub.split("_")[1] # → "noise" ← پاس میشه
# Trigger دوم (JIT provisioning):
sub.split("_")[-1] # → "internal@company.com" ← ذخیره میشهاین Parser Differential میتونه به privilege escalation منجر بشه.
آسیبپذیری سوم — هایجک مسیریابی IdP: Cognito از IdpIdentifiers برای ریدایرکت کاربران به IdP مناسب استفاده میکنه — مثلاً با چک دامنهی ایمیل. چون AWS مالکیت دامنه رو تأیید نمیکنه، اگه پلتفرم اجازه بده هر tenant آزادانه identifier ثبت کنه، یه مهاجم میتونه gmail.com رو ادعا کنه و همهی کاربران گوگل رو به سمت IdP مخرب خودش بفرسته.
برای رفع این مشکلات، توسعهدهندهها باید چکهای امنیتی رو در PreSignUp و بر اساس مقدار triggerSource پیاده کنن، از split("_", 1) با maxsplit=1 یکسان در همه جا استفاده کنن، attributeهای حساس رو از AttributeMapping حذف کنن، و ثبت IdpIdentifier رو بدون تأیید مالکیت دامنه مجاز ندونن. تیم Doyensec همچنین ابزار maSSO رو منتشر کرده — یه IdP مخرب آماده برای تست OIDC و SAML 2.0 که کار پنتست این سناریوها رو خیلی راحتتر میکنه.
نکات کلیدی:
- PreSignUp_ExternalProvider تنها دروازهی قبل از ذخیرهی رکورد کاربره؛ هر چک امنیتی باید اینجا باشه
- Triggerهای مختلف در first login و subsequent login فرق دارن؛ چک گذاشتن فقط در یکی کافی نیست
- sub در federated login کاملاً توسط IdP کنترل میشه و نباید با split ایندکسمحور پارس بشه
- ثبت IdpIdentifiers بدون تأیید مالکیت دامنه میتونه به هایجک کامل مسیریابی منجر بشه
- ابزار maSSO برای شبیهسازی IdP مخرب در تستهای امنیتی منتشر شده
