/dev/null

انواع مختلفی داره پردازش 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 رو پردازش کنه و بک اند هم یه نوع دیگه

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 میگیره.

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

این نامه ای که ترامپ فرستاده احتمالا Packet Loss شده @Linuxor

https://youtu.be/BmuqgZ9bj3c?si=2c-eWnEFvaG_8C7M کار سنگینه حوصله کن 🔥🔥

چند تا آسیب‌پذیری موقع Cache توی CDN می‌تونه رخ بده: اولیش Cache Deception هست که کاربر رو مجبور می‌کنیم اطلاعات حساس خودش رو توی Cache ذخیره کنه و یه مسیری که داینامیک هست رو بیایم به یه مسیر استاتیک تبدیل کنیم که کش بشه. مثلاً اگه با این URL اطلاعات کاربر نشون داده بشه: https://example.com/auth/profile چون یه path داینامیک هست کش نمیشه ولی میشه با https://example.com/auth/profile/mamad.css به یه path استاتیک تبدیل کرد و حالا CDN کش می‌کنه و اگه همین لینک رو به یه کاربر عادی بدیم چون هنوز اطلاعات توی کش نیست miss می‌خوره و بعدش می‌تونیم به عنوان attacker با باز کردن همین لینک از توی کش بدون احراز هویت اطلاعات ذخیره شده توی کش رو ببینیم. چرا این آسیب‌پذیری رخ می‌ده؟ چون برنامه‌نویس فقط /auth/profile رو چک می‌کنه:

app.get('/auth/profile', (req, res) => {
    res.send(`<h1>Welcome, ${req.user.name}</h1>`);
});

در صورتی که باید بگه اگه جز این مسیر بود:

app.get('/auth/profile/*', (req, res) => {
    res.status(404).send('Not Found');
});

یه آسیب‌پذیری دیگه در Cache Poisoning هست که در واقع میاد هدرهایی که توی کش شدن تاثیری ندارن (unkey input) رو شناسایی می‌کنیم. مثلا:

GET / HTTP/1.1  
Host: example.com

یه هدر X-Forwarded-Host توسط CDN کش نمیشه، حالا میشه با فرستادن این درخواست:

GET / HTTP/1.1  
Host: example.com  
X-Forwarded-Host: attacker.com

حالا هر کاربری که example.com رو باز کنه، redirect میشه به attacker.com و حالا دیگه میشه این رو با آسیب پذیری هایی مثل XSS ترکیب کرد.

چند تا آسیب‌پذیری موقع Cache توی CDN می‌تونه رخ بده: اولیش Cache Deception هست که کاربر رو مجبور می‌کنیم اطلاعات حساس خودش رو توی Cache ذخیره کنه و یه مسیری که داینامیک هست رو بیایم به یه مسیر استاتیک تبدیل کنیم که کش بشه. مثلاً اگه با این URL اطلاعات کاربر نشون داده بشه: https://example.com/auth/profile چون یه path داینامیک هست کش نمیشه ولی میشه با https://example.com/auth/profile/mamad.css به یه path استاتیک تبدیل کرد و حالا CDN کش می‌کنه و اگه همین لینک رو به یه کاربر عادی بدیم چون هنوز اطلاعات توی کش نیست miss می‌خوره و بعدش می‌تونیم به عنوان attacker با باز کردن همین لینک از توی کش بدون احراز هویت اطلاعات ذخیره شده توی کش رو ببینیم. چرا این آسیب‌پذیری رخ می‌ده؟ چون برنامه‌نویس فقط /auth/profile رو چک می‌کنه:

app.get('/auth/profile', (req, res) => {
    res.send(`<h1>Welcome, ${req.user.name}</h1>`);
});

در صورتی که باید بگه اگه جز این مسیر بود:

app.get('/auth/profile/*', (req, res) => {
    res.status(404).send('Not Found');
});

یه آسیب‌پذیری دیگه در Cache Poisoning هست که در واقع میاد هدرهایی که توی کش شدن تاثیری ندارن (unkey input) رو شناسایی می‌کنیم. مثلا:

GET / HTTP/1.1  
Host: example.com

یه هدر X-Forwarded-Host توسط CDN کش نمیشه، حالا میشه با فرستادن این درخواست:

GET / HTTP/1.1  
Host: example.com  
X-Forwarded-Host: attacker.com

حالا هر کاربری که example.com رو باز کنه، redirect میشه به attacker.com و حالا دیگه میشه این رو با آسیب پذیری هایی مثل XSS ترکیب کرد.

امروز مجبور شدم از Django استفاده کنم یه تفاوتی در مقابل node js که توجهم رو جلب کرد این بود که Django خودش یه orm داره واسه خودش (یه orm داخلی ) بهش میگن Django ORM ولی در صورتی که تویه node js باید از sequelize استفاده کنیم که خب تقریبا هیچ برتری نسبت به هم ندیدم و فقط Django یکم اومده بود کارو ساده تر کرده بود ولی تویه sequelize دستتون باز تره 😂🦦

🖤

کش در CDN کش یعنی یه کپی از داده‌ها ذخیره بشه یه جایی. حالا این ذخیره‌سازی می‌تونه توی مرورگر، DNS، CDN و ... باشه. اما وقتی داده‌ها کش می‌شن، ممکنه آسیب‌پذیری‌هایی هم به وجود بیاد که بعدا دربارش میگم. حالا چطور CDN یه محتوا رو کش می‌کنه؟ وقتی یه سری درخواست به سایت می‌زنیم، اگر محتوای سایت استاتیک باشه، در درخواست اول که هنوز محتوا توسط CDN کش نشده، با یک Miss مواجه می‌شیم. اما در درخواست‌های بعدی، Hit میخوره. سوالی که پیش میاد اینه که CDN چطور می‌فهمه که ما همون درخواست رو زدیم؟ این کار با تشخیص هدرها انجام میشه. به هدرهایی که برای این تشخیص استفاده می‌شه، "Cache Key" گفته میشه. مثلا : HTTP|GET|site.com|/new/test.php?id=1 همچنین، بعضی هدرها وجود دارن که CDN موقع بررسی کش به اون‌ها توجه نمی‌کنه و به این هدرها "unkey input" گفته میشه. اما میشه با هدر vary این هدر ها رو مجبور کرد که کش بشن. مثلا با استفاده از هدر vary: cookie. CDN (Content Delivery Network) CDN یه شبکه از سرورهای مختلف هست که محتوای استاتیک سایت‌ها رو ذخیره و نگهداری می‌کنه. این کار باعث میشه که سرعت بارگذاری داده‌ها بیشتر بشه یا load balancing و ... چطور بفهمیم یک سایت پشت CDN هست یا نه؟ 1. ping site.com 2. whois ip[site.com] یا اینکه ip شو تویه این سایت پیدا کنیم. با این کار می‌تونیم بفهمیم که IP متعلق به CDN هست یا نه. چون وقتی سایتی پشت CDN قرار داشته باشه، دیگه نمی‌تونیم IP اصلی سایت رو ببینیم و فقط IP CDN نمایش داده میشه.

کش در CDN کش یعنی یه کپی از داده‌ها ذخیره بشه یه جایی. حالا این ذخیره‌سازی می‌تونه توی مرورگر، DNS، CDN و ... باشه. اما وقتی داده‌ها کش می‌شن، ممکنه آسیب‌پذیری‌هایی هم به وجود بیاد که بعدا دربارش میگم. حالا چطور CDN یه محتوا رو کش می‌کنه؟ وقتی یه سری درخواست به سایت می‌زنیم، اگر محتوای سایت استاتیک باشه، در درخواست اول که هنوز محتوا توسط CDN کش نشده، با یک Miss مواجه می‌شیم. اما در درخواست‌های بعدی، Hit می‌زنیم. سوالی که پیش میاد اینه که CDN چطور می‌فهمه که ما همون درخواست رو زدیم؟ این کار با تشخیص هدرها انجام میشه. به هدرهایی که برای این تشخیص استفاده می‌شه، "Cache Key" گفته میشه. مثلا : HTTP|GET|site.com|/new/test.php?id=1 همچنین، بعضی هدرها وجود دارن که CDN موقع بررسی کش به اون‌ها توجه نمی‌کنه و به این هدرها "unkey input" گفته میشه. اما میشه با هدر vary این هدر ها رو مجبور کرد که کش بشن. مثلا با استفاده از هدر vary: cookie. CDN (Content Delivery Network) CDN یه شبکه از سرورهای مختلف هست که محتوای استاتیک سایت‌ها رو ذخیره و نگهداری می‌کنه. این کار باعث میشه که سرعت بارگذاری داده‌ها بیشتر بشه یا load balancing و ... چطور بفهمیم یک سایت پشت CDN هست یا نه؟ 1. ping site.com 2. whois ip[site.com] یا اینکه ip شو تویه این سایت پیدا کنیم. با این کار می‌تونیم بفهمیم که IP متعلق به CDN هست یا نه. چون وقتی سایتی پشت CDN قرار داشته باشه، دیگه نمی‌تونیم IP اصلی سایت رو ببینیم و فقط IP CDN نمایش داده میشه.

اگه دیتابیسی طراحی کردین و خواستین ایرادی داشت بفهمین این به کار میاد https://github.com/drawdb-io/drawdb

من وقتی کسی بلوفمو تویه پوکر میفهمید 🤣

اقتصاد مملکت رو کافه ، اسنپ و ایونت میچرخه