هک کردن توکن های CSRF با استفاده از CSS History Hack

بروزرسانی: محققان امنیتی Sirdarckcat و Gareth به اندازه کافی مهربان بودند که کد یک کد یاب خالص مبتنی بر CSS بر اساس CSS را در اینجا به اشتراک بگذارند. این نسبت به PoC من در زیر مخفی است ، که از ترکیبی از JS و CSS استفاده می کرد. بنابراین ، حتی اگر جاوا اسکریپت را غیرفعال کنید و دیگر امنیت نداشته باشید ، همچنان کار خواهد کرد :(:( . برای اینکه این PoC برای مشتری بیشتر پاسخگو باشد ، باید از دستورالعمل import چند شیوه نامه CSS استفاده کنید. تنها مشکلی که من با این رویکرد مبتنی بر CSS مشاهده می کنم وجود تأخیر شبکه در فضاهای کلیدی بزرگ است زیرا نیاز به برگه بزرگ CSS شما توسط مرورگر شما بارگیری می شود..


من در حال فکر کردن به مشکل جعل تقاضای جعلی و استراتژی های کاهش فعلی استفاده شده در صنعت بودم. در بسیاری از برنامه های دنیای واقعی که تاکنون آزمایش کرده ام ، استفاده از نشانه های تصادفی را به عنوان بخشی از آدرس اینترنتی اضافه می کنم. اگر درخواست نتواند هیچ نشانه ای را ارائه دهد یا یک نشانه با ارزش نادرست ارائه دهد ، درخواست رد می شود. این مانع از CSRF یا اجرای هر یک از عملکردهای غیرمجاز دامنه متقابل می شود.

اکنون ، یک مهاجم غیرممکن است که بتواند با استفاده از Brute Force Attack بر روی سرور ، توکن CSRF شما را کشف کند..

دلایل:

  1. تولید می کند سر و صدای زیادی در شبکه وجود دارد و کند است. بنابراین احتمالاً یک فایروال IDS یا Web App رفتار مخربی را انتخاب کرده و IP شما را مسدود می کند. به عنوان مثال ، یک نشانه CSRF Base16 با طول 5 کاراکتر (با شروع کاراکتر) تقریباً 393،216 درخواست ایجاد می کند..
  2. بسیاری از برنامه ها به آنها برنامه ریزی شده اند جلسه خود را باطل کنید بعد از اینکه بیشتر از تعداد مشخصی از درخواستها را با مقادیر نامعتبر تشخیص داد. به عنوان مثال. 30.

من قصد دارم با نشان دادن یک تکنیک برای پیدا کردن سریع نشانه های csrf بدون ایجاد هشدار ، این باور را تغییر دهم. این تکنیک است حمله جانبی مشتری, بنابراین تقریباً هیچ ترافیکی در شبکه ایجاد نشده است ، از این رو ، سرور و فایروال های IDS / Web برنامه شما برنده شدند’اصلاً متوجه آن هستم این حمله بر اساس محبوب هک تاریخ CSS است که توسط ارمیا گراسمن 3 سال پیش پیدا شده است.

در این بهره برداری ، با مجبور کردن اجباری مجموعه های مختلف آدرس اینترنتی در تاریخ مرورگر ، نشانگر csrf را کشف می کنیم. ما سعی خواهیم کرد که مقادیر مختلف نشانه csrf را به عنوان بخشی از آدرس اینترنتی وارد کنیم و بررسی کنیم که کاربر از آن آدرس بازدید کرده است یا خیر. اگر بله ، این احتمال خوب وجود دارد که کاربر در همان جلسه فعال فعلی از همان نشانگر CSRF استفاده کند یا ممکن است در یک جلسه قبلی از آن نشانه استفاده کند. هنگامی که لیستی از همه چنین نشانه هایی را داریم ، می توانیم با استفاده از آن لیست کوچک ، حمله csrf خود را به سرور امتحان کنیم. در حال حاضر این حمله برای علائم با طول 5 کاراکتر یا کوتاهتر امکان پذیر است. من آن را در یک رشته base16 به طول 5 امتحان کردم و توانستم در کمتر از 2 دقیقه کل فضای کلیدی را زور بزنم.

برخی از پیش شرط های این حمله برای عملی شدن یا یکی است

  1. نشانه CSRF برای یک جلسه کاربر خاص یکسان است. به عنوان مثال، csrf token = هش (session_id) یا
  2. نشان CSRF ارسال شده در فرم های قدیمی تر برای همان جلسه پذیرفته می شود. بارها ، این مورد به دلیل افزایش تجربه کاربر و استفاده از دکمه های مرورگر جلو و عقب امکان پذیر است.

اثبات مفهوم در اینجا موجود است.
قبل از اجرای PoC ، باید مقادیر پارامتر url و csrftoken را تغییر دهید.

برای آزمایش با استفاده از پیش فرض ها ، ابتدا باید به یکی از آدرس های زیر مراجعه کنید ، به عنوان مثال.

  1. https://securethoughts.com/؟param1=val1&csrftoken = b59fe [تغییر b59fe به هر رشته 5 رقمی پایه 16 رشته ای که با یک کاراکتر شروع می شود ، به عنوان مثال ایجاد شده از a0000]
  2. http://tinyurl.com/l2lwgd [که 301 هدایت به آدرس قبلی است].

توجه داشته باشید: http://www.securethoughts.com و https://securethoughts.com در حالی که در تاریخچه مرورگر ذخیره می شود متفاوت رفتار می شود.

نمونه آزمایشی مانند این خواهد بود -

هک کردن نشانه های csrf با استفاده از هک تاریخچه cssهک کردن نشانه های csrf با استفاده از هک تاریخچه css

برای اینکه این حمله غیرممکن شود,

Solution-Side Solution (برای توسعه دهندگان):

  • نشانه های CSRF خود را به اندازه کافی طولانی (8 یا بیشتر کاراکتر) کنید تا برای یک حمله CLIENT SIDE غیرممکن باشد. قدرت پردازش روزافزون ، این حمله را برای توکن های طولانی تر نیز امکان پذیر می کند.
  • نشانه CSRF خود را به عنوان بخشی از قسمت فرم پنهان ، به جای قرار دادن آدرس ، ذخیره کنید.
  • برای هر فرم ارسال از یک علامت تصادفی متفاوت استفاده کنید و هیچ نشانه منسوخ را قبول نکنید ، حتی برای همان جلسه.

راه حل مشتری-جانبی (برای مشتریان / کاربران خود):

  • از افزونه مرورگر مانند SafeHistory استفاده کنید ، که از تکنیک های ردیابی مبتنی بر لینک بازدید می کند.
  • از حالت مرور خصوصی در مرورگر خود استفاده کنید.

و آخرین ، اما کمترین نکته ، XSS تمام حمایت های CSRF ممکن را از بین می برد. بنابراین ، ابتدا از شر XSS خلاص شوید.

من می خواهم از ارمیا تشکر کنم که بازخورد روشنگری خود را در مورد این پست ارائه داد.

Brayan Jackson Administrator
Sorry! The Author has not filled his profile.
follow me