حمله ای به سیستم های front-end-back-end که به ما اجازه می دهد تا در درخواست های شخص ثالث نفوذ کنیم

آشکار شد جزئیات یک حمله جدید به سایت‌هایی که از مدل جلویی-پشت‌اند استفاده می‌کنند، مانند مواردی که از طریق شبکه‌های تحویل محتوا، متعادل‌کننده‌های بار یا پراکسی‌ها اجرا می‌شوند. این حمله با ارسال درخواست‌های خاص، اجازه می‌دهد تا در محتوای درخواست‌های دیگر پردازش شده در همان رشته بین جلو و باطن فرو رود. روش پیشنهادی با موفقیت برای سازماندهی حمله ای مورد استفاده قرار گرفت که امکان رهگیری پارامترهای احراز هویت کاربران سرویس PayPal را فراهم کرد که به عنوان بخشی از برنامه ای برای اطلاع از وجود آسیب پذیری های اصلاح نشده به محققان حدود 40 هزار دلار پرداخت کرد. این حمله همچنین برای سایت‌هایی که از شبکه تحویل محتوای Akamai استفاده می‌کنند نیز قابل اجرا است.

مشکل اصلی این است که فرانت‌اندها و بک‌اندها اغلب سطوح مختلفی از پشتیبانی از پروتکل HTTP را ارائه می‌کنند، اما در عین حال درخواست‌های کاربران مختلف را در یک کانال مشترک کپسوله می‌کنند. برای اتصال درخواست های دریافت کننده frontend و درخواست های پردازش باطن، یک اتصال طولانی مدت TCP ایجاد می شود که از طریق آن درخواست های کاربر منتقل می شوند، در امتداد زنجیره یکی پس از دیگری منتقل می شوند و با استفاده از پروتکل HTTP از هم جدا می شوند. برای جداسازی درخواست‌ها، سرفصل‌های "Content-Length" (اندازه کل داده‌های موجود در درخواست را تعیین می‌کند) و "Transfer-Encoding: تکه تکه شده"(به شما امکان می دهد داده ها را به صورت قطعات منتقل کنید، بلوک هایی با اندازه های مختلف را در قالب "{size}\r\n{block}\r\n{size}\r\n{block}\r\n0" مشخص کنید).

مشکل زمانی پیش می‌آید که فرانت‌اند فقط از «طول محتوا» پشتیبانی می‌کند، اما «انتقال-رمزگذاری: تکه‌شده» را نادیده می‌گیرد (مثلاً، CDN آکامای این کار را انجام داد) یا برعکس. اگر Transfer-Encoding: chunked در هر دو طرف پشتیبانی می شود، ویژگی های پیاده سازی تجزیه کننده های هدر HTTP را می توان برای حمله استفاده کرد (به عنوان مثال، هنگامی که قسمت جلویی خطوطی مانند "Transfer-Encoding: xchunked"، "Transfer-Encoding: chunked" را نادیده می گیرد. "، "Transfer-Encoding" :[tab]chunked"، "X: X[\n]Transfer-Encoding: chunked"، "Transfer-Encoding[\n]: chunked" یا "Transfer-Encoding: chunked"، و Backend با موفقیت آنها را پردازش می کند).

در این حالت، مهاجم می‌تواند درخواستی ارسال کند که شامل سرصفحه‌های «طول محتوا» و «انتقال-رمزگذاری: تکه‌شده» باشد، اما اندازه در «طول محتوا» با اندازه زنجیره تکه‌شده مطابقت ندارد. کوچکتر از مقدار واقعی است. اگر فرانت‌اند درخواست را طبق «Content-Length» پردازش و فوروارد کند و backend منتظر بماند تا بلوک براساس «Transfer-Encoding: chunked» تکمیل شود، آنگاه پایان داده‌ها براساس «Transfer-Encoding: chunked» خواهد بود. زودتر تعیین شود و دم باقی مانده درخواست مهاجم در ابتدای درخواست بعدی خواهد بود، یعنی. مهاجم می‌تواند داده‌های دلخواه را به ابتدای درخواست شخص دیگری که در مرحله بعدی ارسال می‌شود، پیوست کند.

حمله ای به سیستم های front-end-back-end که به ما اجازه می دهد تا در درخواست های شخص ثالث نفوذ کنیم

برای تعیین مشکل در ترکیب frontend-backend استفاده شده، می توانید درخواستی مانند این را از طریق frontend ارسال کنید:

POST /درباره HTTP/1.1
میزبان: example.com
Transfer-Encoding: تکه تکه شده
طول محتوا: 4

1
Z
Q

این مشکل در صورتی وجود دارد که باطن فوراً درخواست را پردازش نکند و منتظر رسیدن بلوک مرزی صفر نهایی از داده های تکه تکه شود. برای بررسی کاملتر تهیه شده یک ابزار ویژه که روش‌های ممکن را برای پنهان کردن هدر «Transfer-Encoding: chunked» از قسمت جلویی نیز آزمایش می‌کند.

انجام یک حمله واقعی به قابلیت های سایت مورد حمله بستگی دارد، به عنوان مثال، هنگام حمله به برنامه وب Trello، می توانید شروع درخواست را جایگزین کنید (داده هایی مانند "PUT /1/members/1234... x=x&csrf را جایگزین کنید. =1234&username=testzzz&bio=cake") و پیامی شامل درخواست اصلی یک کاربر شخص ثالث و کوکی احراز هویت مشخص شده در آن ارسال کنید. برای حمله به saas-app.com، مشخص شد که می‌توان کد جاوا اسکریپت را در پاسخ با جایگزین کردن آن در یکی از پارامترهای درخواست جایگزین کرد. برای حمله به redhat.com، از یک کنترل کننده داخلی برای هدایت به وب سایت مهاجم استفاده شد (یک درخواست از فرم "POST /search?dest=../assets/idx?redir=//[ایمیل محافظت شده]/ HTTP/1.1").

استفاده از روش شبکه های تحویل محتوا، جایگزینی سایت درخواستی را با جایگزینی هدر "Host:" امکان پذیر کرد. این حمله همچنین می تواند برای مسموم کردن محتویات سیستم های کش محتوا و استخراج داده های محرمانه ذخیره شده مورد استفاده قرار گیرد. اوج روش، سازماندهی حمله به PayPal بود، که امکان رهگیری رمزهای عبور ارسال شده توسط کاربران را در حین احراز هویت فراهم کرد (درخواست iframe برای اجرای جاوا اسکریپت در زمینه صفحه paypal.com/us/gifts تغییر یافت. که CSP (خط مشی امنیت محتوا) اعمال نشد).

جالب اینجاست که در سال 2005 وجود داشت پیشنهاد شده یک تکنیک جعل درخواست اساساً مشابه که به شما امکان می‌دهد داده‌ها را در پراکسی‌های کش (Tomcat، squid، mod_proxy) جعل کنید یا با تعیین چندین درخواست «GET» یا «POST» در یک جلسه HTTP، مسدود کردن فایروال را دور بزنید.

منبع: opennet.ru

اضافه کردن نظر