CVE-2025-59681

چکیده

آسیب‌پذیری SQL Injection در فریم‌ورک Django کشف شده که متدهای annotate()، alias()، aggregate() و extra() را هنگام استفاده از dictionary unpacking (**kwargs) تحت تأثیر قرار می‌دهد. این ضعف به‌ویژه در پایگاه‌داده‌های MySQL و MariaDB قابل بهره‌برداری است و به مهاجم امکان تزریق کد SQL در نام مستعار ستون‌ها را می‌دهد، که می‌تواند منجر به افشای داده‌های حساس شود.

توضیحات

آسیب‌پذیری CVE-2025-59681 ناشی از خنثی‌سازی نادرست المنت‌های ویژه در دستورات SQL مطابق با CWE-89 است. این ضعف در نحوه‌ی پردازش نام‌های مستعار ستون‌ها (Column Aliases) در متدهای QuerySet.annotate()، QuerySet.alias()،QuerySet.aggregate() و QuerySet.extra() در فریم‌ورک Django وجود دارد و به‌طور خاص پایگاه‌داده‌های MySQL و MariaDB را تحت تأثیر قرار می‌دهد.

این متدها برای افزودن فیلدهای محاسباتی، تعریف Alias برای ستون‌ها، انجام عملیات تجمیعی و ساخت کوئری‌های پیشرفته روی نتایج QuerySet استفاده می‌شوند. در حالت ایمن، نام‌های مستعار ستون‌ها باید از مقادیر ثابت، کنترل‌شده و غیرقابل‌تأثیر از ورودی کاربر تشکیل شوند. با این حال، زمانی که توسعه‌دهنده از بازگشایی دیکشنری (Dictionary Unpacking یا **kwargs) همراه با داده‌های قابل کنترل توسط کاربر در این متدها استفاده کند، یک مسیر تزریق بالقوه ایجاد می‌شود.

در این شرایط، کلیدهای دیکشنری ارسال‌شده به‌عنوان **kwargsمستقیماً به‌عنوان نام مستعار ستون‌ها در ساختار SQL مورد استفاده قرار می‌گیرند. اگر مهاجم بتواند این کلیدها را کنترل کند، مقادیر آن‌ها بدون اعتبارسنجی یا خنثی‌سازی مناسب وارد کوئری SQL نهایی می‌شوند. این مسئله امکان تزریق SQL در بخش Column Alias را فراهم می‌کند؛ بخشی که معمولاً کمتر مورد بررسی امنیتی قرار می‌گیرد.

بهره‌برداری از این آسیب‌پذیری از طریق شبکه امکان‌پذیر است و به تعامل کاربر نیاز ندارد اما مستلزم سطح دسترسی محدود و شرایط خاص در نحوه‌ی پیاده‌سازی برنامه است؛ به‌عبارت دیگر، تنها در سناریوهایی قابل سوءاستفاده است که ورودی کاربر به‌طور مستقیم و بدون محدودیت به‌عنوان Alias ستون‌ها در این متدها استفاده شده باشد.

در صورت بهره‌برداری موفق، این ضعف می‌تواند منجر به افشای گسترده اطلاعات و تغییر محدود داده‌ها شود. این آسیب پذیری به‌طور خاص در MySQL و MariaDB قابل سوءاستفاده است، زیرا این موتورهای پایگاه‌داده در پردازش نام‌های مستعار ستون‌ها انعطاف‌پذیری بیشتری داشته و امکان تفسیر عبارات تزریق‌شده در این بخش از کوئری را فراهم می‌کنند. سایر پایگاه‌داده‌ها به دلیل محدودیت‌های سخت‌گیرانه‌تر در این زمینه، به‌طور معمول تحت تأثیر این ضعف قرار نمی‌گیرند. Django با انتشار به‌روزرسانی‌های امنیتی رسمی، این ضعف را از طریق اعمال اعتبارسنجی سخت‌گیرانه روی نام‌های مستعار ستون‌ها و جلوگیری از استفاده‌ی ناامن از **kwargs در این متدها به‌طور کامل پچ کرده است.

CVSS

لیست محصولات آسیب پذیر

لیست محصولات بروز شده

استفاده محصول در ایران

در این جدول، تعداد صفحات ایندکس‌شده در گوگل با دامنه .ir که Django را ذکر کرده اند، ثبت شده است. این داده صرفاً برای برآورد تقریبی حضور محصولات در وب ایران استفاده شده و نمایانگر میزان نصب دقیق و استفاده واقعی نیست.

نتیجه گیری

این آسیب‌پذیری با شدت بالا امکان SQL Injection از راه دور را در سناریوهای خاص پیاده‌سازی فراهم می‌کند. اگرچه بهره‌برداری از آن مستلزم سطح دسترسی محدود و استفاده‌ی ناامن از الگوهای خاص در کدنویسی است، اما در صورت موفقیت می‌تواند منجر به افشای اطلاعات حساس، تغییر منطق کوئری‌ها و در برخی شرایط دست‌کاری محدود داده‌ها شود. با توجه به انتشار پچ امنیتی رسمی، اجرای اقدامات زیر برای کاهش ریسک بهره‌برداری ضروری است:

• به‌روزرسانی فوری: تمامی پروژه‌های مبتنی بر Django باید در اسرع وقت به نسخه‌های امن 2.25، 5.1.13 ،5.2.7 یا بالاتر به‌روزرسانی شوند. این اقدام مؤثرترین و قطعی‌ترین راهکار برای رفع آسیب‌پذیری است و باید در اولویت قرار گیرد. سایر اقدامات نقش مکمل را دارند و می‌توانند به کاهش ریسک این آسیب پذیری و مقابله با حملات مشابه کمک کنند.
• بازبینی کد: تمامی بخش های کد که از الگوهای annotate(**kwargs)، alias(**kwargs)، aggregate(**kwargs) و extra(**kwargs) استفاده می‌کنند باید شناسایی و بازبینی شوند. همچنین باید به‌طور کامل از ارسال مستقیم ورودی کاربر به این متدها از طریق بازگشایی دیکشنری (Dictionary Unpacking) جلوگیری شود.
• استفاده از لیست سفید (Whitelist): تنها باید از نام ستون‌ها و Alias های از پیش تعریف‌شده و ایمن استفاده شود و به‌هیچ‌وجه نباید کلیدهای دیکشنری مستقیماً از ورودی کاربر دریافت یا بر اساس آن تولید شوند.
• استفاده امن از ORM: منطق تولید Aliasها باید به‌صورت صریح، ثابت و کنترل‌شده در کد پیاده‌سازی شود و از تولید پویا بر اساس داده‌های خام کاربر اجتناب گردد.
• مانیتورینگ و تشخیص تهدید: کوئری‌های غیرعادی، خطاهای SQL و الگوهای مشکوک باید به‌صورت مستمر در لاگ‌های پایگاه‌داده مانیتور شوند. همچنین در صورت امکان، استفاده از فایروال اپلیکیشن وب (WAF) با قوانین تشخیص تزریق SQL توصیه می‌شود.
• تست امنیتی: پس از اعمال به‌روزرسانی‌ها، تست نفوذ روی بخش‌های مرتبط با ثبت لاگ، فیلترگذاری و تجمیع داده‌ها انجام شود تا اطمینان حاصل گردد هیچ الگوی کدنویسی آسیب‌پذیری در سیستم باقی نمانده است.

اجرای سریع به‌روزرسانی‌ها و اصلاح الگوهای ناامن استفاده از **kwargs، ریسک بهره‌برداری از این آسیب‌پذیری را به‌طور قابل توجهی کاهش داده و امنیت برنامه‌های مبتنی بر Django را در برابر حملات تزریق SQL تضمین می‌کند.

امکان استفاده در تاکتیک های Mitre Attack (در زمان اجرای حمله)

Initial Access (TA0001)
در مرحله‌ نخست، مهاجم از طریق ارسال درخواست‌های معمولی به بخش‌هایی از برنامه که از متدهای QuerySet در Django مانند annotate یا aggregate استفاده می‌کنند، تلاش می‌کند تا داده‌های تزریقی خود را به‌عنوان کلیدهای دیکشنری ورودی قرار دهد. پیش‌شرط موفقیت در این گام، وجود پیاده‌سازی ناامن در سمت توسعه‌دهنده است که داده‌های دریافتی از کاربر را مستقیماً به‌صورت **kwargs در این متدها به کار برده باشد. این ضعف، کانال ورود اولیه برای حمله تزریق SQL محسوب می‌شود.

Execution (TA0002)
در این فاز، کدهای تزریق‌شده در پارامترهای ورودی با عبور از کنترل‌های ناکافی وارد بخش ساخت رشته SQL می‌شوند و به‌صورت مستقیم توسط ORM اجرا خواهند شد. شرط لازم جهت اجرای موفقیت‌آمیز این مرحله آن است که برنامه در پایگاه‌داده‌های MySQL یا MariaDB اجرا شود، زیرا این دو موتور نسبت به دیگر سیستم‌های مدیریت پایگاه‌داده در پردازش نام‌های مستعار یا عبارات ورودی آزادتر عمل می‌کنند. بدین ترتیب، کوئری نهایی با دستورات مخرب ترکیب و اجرا می‌شود.

Credential Access (TA0006)
در ادامه، مهاجم می‌تواند از نتایج SQL دستکاری‌شده برای دستیابی به داده‌های موجود در جداول حساس استفاده کند؛ مانند رکوردهای مرتبط با کاربران یا پارامترهای پیکربندی. این مرحله تنها در صورتی محقق می‌شود که جداول پایگاه داده شامل اطلاعات محرمانه باشند و سیستم فاقد لایه‌های تفکیک داده یا محدودیت سطح دسترسی برای اجرای Queryهای پیچیده باشد.

Discovery (TA0007)
پس از موفقیت در تزریق، مهاجم با تحلیل پاسخ‌های پایگاه‌داده و طرح کوئری‌های آزمایشی، ساختار schema و روابط میان جداول را شناسایی می‌کند. شرط خاص برای تحقق این گام، پاسخ‌دهی دقیق سرور به خطاهای پایگاه‌داده یا پیام‌های debug است که معمولاً در محیط‌های توسعه یا تنظیمات نادرست فعال باقی مانده‌اند. این شناخت، بستر توسعه حملات پایدارتر را فراهم می‌آورد.

Collection (TA0009)
در مرحله جمع‌آوری داده، مهاجم خروجی کوئری‌های تزریق‌شده را که شامل اطلاعات حساس هستند، استخراج و در قالب داده‌های ساختاریافته ذخیره می‌کند. این داده‌ها می‌توانند شامل جزئیات کاربران، تنظیمات برنامه یا داده‌های عملیاتی باشند. شرط لازم برای جمع‌آوری داده، استمرار ارتباط با پایگاه‌داده و نبود سامانه پایش فعالیت‌های مشکوک (مانند WAF یا IDS) است تا مهاجم بتواند حجم بالایی از داده‌ها را بدون قطع شدن جلسه دریافت کند.

Impact (TA0040)
پیامد بهره‌برداری از این آسیب‌پذیری، نشت گسترده اطلاعات از پایگاه‌داده، تضعیف محرمانگی و بی‌ثباتی عملکرد سامانه است. در نتیجه، مهاجم می‌تواند اطلاعات کاربران و داده‌های درونی سیستم را مشاهده یا تغییر دهد و از این طریق پایه‌های اطمینان و یکپارچگی سرویس را از بین ببرد. چنین رخدادی به‌ویژه در محیط‌های متصل به پایگاه‌داده‌های MySQL و MariaDB خطرناک‌تر است و در صورت عدم اعمال به‌روزرسانی امنیتی ارائه‌شده توسط Django، احتمال نفوذهای زنجیروار و سوءاستفاده از داده‌های افشاشده نیز وجود دارد.

منابع

1. https://www.cve.org/CVERecord?id=CVE-2025-59681
2. https://www.cvedetails.com/cve/CVE-2025-59681/
3. https://docs.djangoproject.com/en/dev/releases/security/
4. https://www.djangoproject.com/weblog/2025/oct/01/security-releases/
5. https://vulmon.com/vulnerabilitydetails?qid=CVE-2025-59681
6. https://vuldb.com/?id.326668
7. http://www.openwall.com/lists/oss-security/2025/10/01/3
8. https://nvd.nist.gov/vuln/detail/CVE-2025-59681
9. https://cwe.mitre.org/data/definitions/89.html