شکل 1.8 Hackerone.com پس از تنظیم کوکی های بزرگ غیر قابل دسترسی است
@TryHackBox

شما نمی‌توانید این کوکی را به‌عنوان cross-origin تنظیم کنید، زیرا محدودیت‌های اعمال شده توسط سیاست همان منبع (SOP) وجود دارد. با این حال، یک کد آسیب‌پذیر در یک برنامه ممکن است به کاربران اجازه دهد تا کوکی‌ها را از طریق پارامترهای قابل کنترل توسط کاربر تنظیم کنند.

Session Expiry and Validation

کوکی HTTP دارای ویژگی هایی مانند ویژگی های "Max-age" و "Expires" است که به کاربران اجازه می دهد کوکی را تنظیم کنند. «Max-age» حداکثر زمانی را که کوکی برای آن معتبر خواهد بود، مشخص می‌کند. به عنوان مثال، اگر حداکثر سن روی "3600" تنظیم شود، به این معنی است که کوکی برای 3600 ثانیه، که معادل یک ساعت است، معتبر است. پس از انقضا، کوکی به طور خودکار از مرورگر حذف می شود.

مثال

Set-Cookie:key=value;Max-Age=3600; Path=/path;Domain=example.com

ویژگی "Expires" زمان خاصی را مشخص می کند که کوکی منقضی می شود.

مثال

Set-Cookie: key=value; Expires=Sun, 31 Dec 2024 23:59:59 GMT;Path=/path;domain=example.com

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

@TryHackBox

Cookie Protection

دو پرچم کوکی ضروری وجود دارد که از نظر کوکی‌های HTTP تأثیر شدیدی بر امنیت دارند. یکی از پرچم‌ها "امن" است که به مرورگر نشان می‌دهد که این کوکی فقط در اتصالات امن مانند اتصال TLS ارسال می‌شود. یکی دیگر از پرچم‌های مرتبط با امنیت «http only» است. این پرچم به مرورگر دستور می دهد که دسترسی از جاوا اسکریپت را ممنوع کند. در اینجا یک نمونه از پیاده سازی است:

مثال

Set-Cookie:key=value;Max-Age=3600;Path=/;domain=example.com;HttpOnly;Secure

کوکی‌های HTTP همچنین می‌توانند روی همان منبع سایت تنظیم شوند، که به مرورگر می‌گوید چه زمانی کوکی‌ها را ارسال کند. این به عنوان مکانیزم حفاظتی برای جعل درخواست متقابل (CSRF) استفاده می شود که در آینده مورد بحث قرار خواهد گرفت.

@TryHackBox

Iframe Sandbox

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

برای رفع این مشکل، مشخصات HTML5 ویژگی “sandbox” را برای Iframe معرفی کرد. این یک کنترل دقیق بر روی نوع محتوایی که باید بارگیری شود ارائه می دهد. در زیر نمونه ای از ویژگی sandbox است که برای بارگیری example.com استفاده می شود.

مثال

<iframe sandbox src=" http://example.com/ "></iframe>

تنظیمات پیش‌فرض ویژگی sandbox ماهیت بسیار محدودی دارند.
این موارد شامل مسدود کردن اجرای جاوا اسکریپت و غیرفعال کردن ارسال فرم در میان محدودیت‌های دیگر است. با این حال، همچنین به توسعه‌دهندگان این امکان را می‌دهد که محتوای مجاز را از طریق ویژگی‌های مختلف مانند allow forms, allow-popups, allow-same-origin, and allow-noscripts تنظیم دقیق کنند. علاوه بر این، CSP شامل یک دستورالعمل sandbox است که در صورت اجرا، محدودیت‌های مشابهی را در کل سند اعمال می‌کند.

@TryHackBox

Subresource Integrity Check

برنامه های کاربردی وب اغلب منابع خارجی مانند کتابخانه های جاوا اسکریپت و فایل های CSS را بارگذاری می کنند. این منابع گاهی اوقات بر روی سرورهای شخص ثالث مانند code.jquery.com برای jQuery میزبانی می شوند. با این حال، اگر چنین دامنه ای به خطر بیفتد و محتوای آن با نسخه مخرب جایگزین شود، هر وب سایتی که این منابع را تعبیه کرده باشد نیز ممکن است در معرض خطر قرار گیرد.

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

برای رفع این مشکل، مرورگرها یک ویژگی امنیتی به نام معرفی کرده اند
بررسی subresource integrity (SRI)، که تضمین می کند اسکریپت ها از زمان بارگذاری اولیه تغییر نکرده اند. این کار از طریق ویژگی یکپارچگی انجام می‌شود، که ورودی حاوی checksum یا مقدار هش (مانند SHA-256، SHA-384، یا SHA-512) فایل خارجی را می‌گیرد، که برای اطمینان از یکپارچگی فایل بارگذاری‌شده استفاده می‌شود.

مثال

<noscript/src=" https://code.jquery.com/jquery-3.6.0.min.js"integrity="sha256-tmgm3212 . . ."crossorigin="anonymous"></noscript>

در این مثال، ویژگی integrity حاوی مقدار هش محتوای مورد انتظار jquery-3.6.0.min.js است. اگر محتوای داخل این فایل تغییر کند، مقدار هش تغییر می‌کند و از بارگیری اسکریپت altered جلوگیری می‌کند.

@TryHackBox

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