حمله Mix-Up Attack یکی از حملاتی است که بسیاری از توسعه‌دهندگان و حتی مدیران امنیتی نسبت به آن آگاه نیستند، اما در معماری‌هایی با احراز هویت چندگانه (Multi-Provider OAuth/OIDC) می‌تواند تهدید جدی ایجاد کند.
📌حمله Mix-Up Attack به زبان ساده:
سناریو چیست؟
فرض کنید اپلیکیشن یا سایت شما به چند OAuth Provider وصل می‌شود (مثلاً هم Facebook، هم Google، هم Microsoft برای ورود کاربران). وقتی کاربر روی “ورود با گوگل” کلیک می‌کند، و همزمان Provider دیگری هم در سیستم هست، اگر validation سمت backend درست انجام نشود، امکان دارد یک توکن از Provider A (مثلاً گوگل) را به provider B (مثلاً فیس‌بوک) بدهند—یا عمداً به سرور بیاورند—و سرور شما فقط به وجود یک توکن اکتفا کند و نفهمد این توکن متعلق به Provider درست نیست.
مسیر حمله:
کاربر انتخاب می‌کند وارد سایت شود (مثلاً با Provider A).
مهاجم یا کاربر malicious، جریان OAuth را با Provider B (مورد نظر خودش) انجام می‌دهد اما در Callback پارامتر Redirect را طوری دستکاری می‌کند که توکن Provider B به جای Provider A به سرور شما ارائه شود.
اگر validate سمت سرور بر اساس Issuer (iss claim) و Audience (aud claim) به درستی انجام نشود، سرور Auth شما شاید این توکن را معتبر بپذیرد، در حالی که اصلاً از Provider مورد انتظار‌تر نیامده!
نتیجه چیست؟
ممکن است attacker بتواند با توکن خودش از Provider دیگر وارد اکانت کاربر در سیستم شود (user impersonation).

🔒 چطور جلویش را بگیریم؟
۱. اعتبارسنجی Issuer (iss claim)
در تمام JWTهایی که دریافت می‌کنید، باید مقدار iss (issuer) را چک کنید که دقیقا مال همانی است که کاربر انتخاب کرده (مثلاً https://accounts.google.com، نه چیز دیگر).
۲. بررسی Audience (aud claim)
حتماً مطمئن شوید aud همان Client IDای است که واقعاً مال سرویس شما است و متعلق به Provider صحیح است.
۳. انجامBind کردن state به provider
در پارامتر state (که هنگام ساخت request OAuth استفاده می‌شود) حتماً identifierی از Provider هم قرار بدهید و در callback بررسی کنید که state مربوطه با Provider که callback زده مطابقت دارد.



#آکادمی_روزبه
مرکز تخصصی CISSP