HTTP Strict Transport Layer Security (HSTS)

وب‌سایت‌ها می‌توانند از HTTP به HTTPS استفاده کنند، و تغییر مسیر اجباری همچنین می‌تواند اطمینان حاصل کند که وب‌سایت فقط از طریق HTTPS قابل دسترسی است. با این حال، این به تنهایی از حملات کاهش رتبه پروتکل جلوگیری نمی کند. این یک شکل از حمله رمزنگاری است که برای تنزل رتبه یک اتصال رمزگذاری شده به حالت عملکرد ضعیف استفاده می‌شود، از این رو رهگیری و رمزگشایی داده‌ها را برای مهاجم بی‌اهمیت می‌سازد.

برای رسیدگی به این مشکل، مرورگرها HTTP Strict Transport Security (HSTS) را معرفی کردند، که به مرورگرها دستور می دهد تمام درخواست های HTTP را به HTTPS تبدیل کنند و از این رو مهاجمان را از exploiting از اتصالات HTTP ناامن جلوگیری می کند. خط مشی HSTS را می توان با استفاده از هدر "Strict-Transport-Security" تنظیم کرد. در پاسخ HTTP در اینجا یک مثال است:

مثال

Strict-Transport-Security:max-age=31536000;includeSubDomains

هدر از دستورالعمل حداکثر سن استفاده می کند، که مدت زمان (در ثانیه) را مشخص می کند که مرورگر باید به خاطر داشته باشد که یک سایت فقط باید با استفاده از HTTPS قابل دسترسی باشد. HSTS همچنین شامل ویژگی "includeSubdomains" است، به این معنی که این خط مشی باید برای همه زیر دامنه ها اعمال شود، نه فقط دامنه اصلی.

HSTS
می‌تواند حاوی یک دستورالعمل «preload» باشد، که فهرستی است که در مرورگرها کدگذاری می‌شود تا همیشه از HTTPS استفاده کنند، حتی قبل از هر گونه تعامل با وب‌سایت. لیست  HSTS preload  یک تلاش مشترک توسط مرورگرهای وب بزرگ است. صاحبان وب سایت باید معیارهای خاصی را برای گنجاندن در لیست preload HSTS رعایت کنند.

مثال

Strict-Transport-Security:max-age=31536000;includeSubDomains;preload

@TryHackBox

POLICY EXCEPTIONS VERSUS POLICY BYPASSES

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


بایپس کردن خط مشی عموماً به عنوان یک آسیب پذیری در مرورگر در نظر گرفته می شود که شامل exploiting از یک حفره برای بایپس کردن یک خط مشی به طور موثر اجرا شده است، در حالی که، استثنائات خط مشی به عنوان سناریوهای قانونی تعریف می شوند که در آن مرورگرها امکان دور زدن کنترل شده سیاست ها را می دهند.

@TryHackBox

SOP Bypass Types

بایپس کردن SOP عمدتاً به دلیل پیچیدگی increasing document object model (DOM) و جاوا اسکریپت رایج شده است. سپس این با عملکردهای سمت سرور مانند تغییر مسیرها ترکیب می‌شود. اکثریت بای‌پس‌های SOP باگ‌های منطقی هستند، یعنی نتیجه یک سردرگمی منطقی یا عدم تطابق بین لایه‌ها و مؤلفه‌های مختلف در مرورگرها هستند. برای مثال، یک مؤلفه ممکن است یک Null-Byte را شناسایی کرده و اجرای یک کد را متوقف می کند، در حالی که دیگری انتخاب می کند که به طور کامل آن را نادیده بگیرد و کد را اجرا کند.

چندین بایپس SOP به مرورگرهای جداگانه محدود نمی شوند زیرا در اجزای مشترک وجود دارند و به طور بالقوه بر چندین مرورگر تأثیر می گذارند. به عنوان مثال، یک بایپس کردن در موتور رندر WebKit روی همه مرورگرهای ساخته شده در بالای یک موتور تأثیر می گذارد. به طور مشابه، بایپس کردن SOP موجود در افزونه هایی مانند جاوا می تواند به طور بالقوه بر همه مرورگرهایی که از این افزونه ها پشتیبانی می کنند تأثیر بگذارد.

چندین دسته از بای پس های SOP وجود دارد. با این حال، مشابه کار alو Schwenk(2017، ما آنها را به چهار نوع
مختلف تقسیم کرده ایم: partial read, full read, partial write, and full read and write. برای هر دسته، حملات بالقوه ای که در دسته های مربوطه قرار می گیرند نیز ذکر شده است.
@TryHackBox

SOP Bypass-CVE-2007-0981

بیایید یک مورد کلاسیک از یک بای پس SOP به دلیل عدم تطابق لایه را بررسی کنیم، که در نسخه های قدیمی فایرفاکس کشف شده و به عنوان CVE-2007-0981 ثبت شده است. بیایید نگاهی به POC بیندازیم:

POC

location.hostname="evil.com\x00www.bing.com "

@TryHackBox

جدول 1.6 دسته بندی های بای پس SOP

@TryHackBox

در این POC، ویژگی location.hostname روی evil.com تنظیم شده است، پس از آن یک null byte "\x00" و سپس bing.com تنظیم می شود. Null byte معمولاً به عنوان پایان دهنده های رشته ای در بسیاری از زبان های برنامه نویسی شناخته می شوند. با این حال، در این مورد، DOM، بخشی از موتور رندر، \x00 را به عنوان یک پایان دهنده رشته در نظر نمی گیرد. بنابراین، " evil.com \ x00www.bing.com " را به عنوان یک زیر دامنه از bing.com تفسیر می کند.


برعکس، حل‌کننده DNS که بخشی از لایه شبکه است، null byte را تشخیص می‌دهد، زیرا پایان‌دهنده رشته، اجرا را متوقف می‌کند و مبدا را به عنوان evil.com در نظر می‌گیرد، بدون توجه به بقیه رشته. در نتیجه، به مهاجم اجازه می‌دهد کوکی‌ها را برای bing.com و زیر دامنه‌های آن تنظیم، تغییر یا حذف کند.
@TryHackBox

شکل 1.9 عدم تطابق لایه ها بین DNS Resolver و DOM
@TryHackBox

شکل 1.10 عدم تطابق لایه ها بین resolver DNS و ذخیره کوکی.
@TryHackBox

SOP Bypass-CVE-2011-3246

نمونه مشابهی است و بر نسخه های قدیمی مرورگر سافاری تأثیر می گذارد. بای پس SOP یک مورد بسیار مشابه دیگر از سردرگمی منطقی و عدم تطابق لایه است. با این حال، این بار عدم تطابق بین بخش ذخیره کوکی لایه پایدار و حل‌کننده DNS از لایه شبکه است.

POC

<img src=" https://evil.com % 00.bing.com">

@TryHackBox

🖥 مخزن: Vuls – اسکنر آسیب پذیری

Vuls
یک اسکنر آسیب‌پذیری منبع باز برای Linux، FreeBSD، Container، WordPress، کتابخانه‌های زبان برنامه‌نویسی، دستگاه‌های شبکه است که در Go نوشته شده است.

- این ابزار تجزیه و تحلیل آسیب پذیری های نرم افزار نصب شده بر روی سیستم را خودکار می کند ، که انجام دستی در یک محیط تولید بسیار دشوار است.

https://github.com/future-architect/vuls?tab=readme-ov-file

#Web #Redteam #Recon
@TryHackBox

SITE ISOLATION

اکثر بای‌پس‌های SOP به دلیل منشأهای متفاوتی هستند که پروسس رندر یکسانی را به اشتراک می‌گذارند. این امر به ویژه در مورد قاب بندی بین سایتی و پاپ آپ رایج است. یک پروسس رندر مسئول مدیریت رندر است

شکل 1.11 isolation سایت.

منبع:
https://security.googleblog.com/2018/07/mitigating-spectre-with-site-isolation.html

@TryHackBox

از صفحات وب این شامل قابلیت هایی مانند تجزیه HTML و CSS و اجرای جاوا اسکریپت است.
پیش از این، مرورگرها مبداهای مختلف را در پروسس های رندر جداگانه جدا نمی کردند. از این رو، هنگامی که یک بای پس SOP پیدا شد، به اسکریپت‌هایی از یک مبدا اجازه می‌دهد تا به طور بالقوه به داده‌هایی از مبدا دیگر در همان پروسس دسترسی داشته باشند.

در ایزوله سازی سایت، هر پروسس در پروسس رندر جداگانه خود که در سطح سیستم عامل مجزا شده است اجرا می شود. با ایزوله سازی سایت، حتی اگر یک بای پس SOP در پروسس رندر رخ دهد، دسترسی به داده‌های منبع متقابل بسیار چالش برانگیزتر است. نمودار زیر (شکل 1.11) نشان می‌دهد که evil.com چگونه bank.com را از طریق Iframe بارگیری می‌کند و چگونه یک صفحه وب منفرد بین دو پروسس رندر تقسیم می‌شود.

@TryHackBox

ADDRESS BAR SPOOFING BUGS

طبق گوگل [ https://bughunters.google.com/about/rules/6625378258649088google-and-alphabet-vulnerability-reward-program-vrp-rules ]، نوار آدرس تنها نشانگر امنیتی در مرورگرهای مدرن است که می توان به آن اعتماد کرد. این منطقی به نظر می رسد زیرا نوار آدرس راه اصلی برای کاربران برای تأیید اینکه آیا در وب سایت صحیح هستند یا خیر است.

فروشندگان مرورگر از این موضوع آگاه هستند و بنابراین کنترل های داخلی را برای اطمینان از مطابقت محتوای نمایش داده شده در مرورگر با URL موجود در نوار آدرس پیاده سازی کرده اند.

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

@TryHackBox

Address Bar Spoofing
- مثال 1

در جاوا اسکریپت، چندین توابع به کاربران این امکان را می دهند که اجرای یک رویداد را به تاخیر بیاندازند یا یک رویداد را در فواصل زمانی منظم اجرا کنند. این روش ها قدرتمند هستند و می توان از آنها برای جستجوی آسیب پذیری های Address Bar Spoofing استفاده کرد. بیایید به نمونه ای از این تکنیک نگاه کنیم:

کد

<noscript>
w = window.open("www.facebook.com", "_blank");
setTimeout(function(){w.document.write("<html>This is
not Facebook</html>")},5000);
</noscript>

این اسکریپت وب سایت فیس بوک را در یک پنجره جدید با استفاده از عملکرد " window.open " باز می کند و سپس سعی می کند صفحه را با متن "This is not Facebook" با استفاده از document.write پس از پنج ثانیه تاخیر بازنویسی کند. اجرا با استفاده از آن به تاخیر می افتد. تابع "setTimeout". در طول این فرآیند، مرورگر ممکن است آدرس بار را به روز نکند، بنابراین در حالی که آدرس بار همچنان به facebook.com اشاره می کند، محتوای نمایش داده شده در واقع توسط مهاجم کنترل می شود. در اینجا نمونه ای از مرورگر Yandex (CVE(2020-7369)) است که آدرس بار را با استفاده از همان تکنیک حفظ می کند.
@TryHackBox

Address Bar Spoofing

مثال 2

یکی دیگر از تکنیک‌های راه‌اندازی address bar spoofing، استفاده از یک پورت ناموجود برای حفظ آدرس بار همراه با استفاده از توابع زمان‌بندی جاوا اسکریپت برای ایجاد تاخیرهای مناسب است. بیایید به نمونه ای از این تکنیک نگاه کنیم:

کد

function spoof(){
document.write("<h1>This is not Bing</h1>");

@TryHackBox

شکل 1.12 جعل نوار آدرس یا همون آدرس بار مرورگر Yandex.

@TryHackBox

document.location = "https://bing.com:1234";
setInterval(function(){document.location="https:// bing.com:1234";},9800);
};



این اسکریپت از تابع document.location برای هدایت کاربر به " https://bing.com " در یک پورت غیر استاندارد، "1234" استفاده می کند. بسته به مرورگر، زمانی طول می کشد تا در نهایت خطای توقف اتصال را بازگردانید، زیرا هیچ سرویسی در این پورت اجرا نمی شود. در طول این بازه زمانی، زمانی که مرورگر تلاش می‌کند تا « https://bing.com:1234 » را بارگیری کند، تابع setInterval به طور مکرر فراخوانی می‌شود، که باعث هدایت مجدد به URL می‌شود، بنابراین پروسس در فواصل زمانی مشخص بازیابی می‌شود.

این پروسس URL جعلی را در نوار آدرس حفظ می کند و در عین حال به مهاجمان اجازه می دهد محتوای صفحه وب را تغییر دهند. این پس از هر بازه زمانی مشخص اجرا می شود، بنابراین URL در پروسس حفظ می شود، در حالی که به مهاجمان اجازه می دهد محتوا را در سند بنویسند که منجر به جعل نوار آدرس می شود. در حالت ایده آل، رفتار صحیح برای مرورگر این است که وقتی تابع setInterval برای تغییر مسیر فراخوانی می شود، به "about: blank" تغییر مسیر دهد.

از همان POC برای ایجاد آسیب‌پذیری‌های جعل نوار آدرس در مرورگرهای سافاری چندین بار به همراه سایر مرورگرهای محبوب مانند Microsoft Edge و DuckDuckGo استفاده شده است. جالب اینجاست که مرورگر سافاری پورت را مخفی می‌کند و از این رو تنها URL قابل مشاهده برای کاربر، bing.com است.

@TryHackBox