HTTP Cookies

همانطور که قبلاً ذکر شد، HTTP یک پروتکل stateless است و از این رو از تعاملات قبلی یک مشتری اطلاعی ندارد. برای غلبه بر این محدودیت، از کوکی های HTTP استفاده می شود. هنگامی که یک مشتری برای اولین بار درخواستی را به وب سرور ارسال می کند، سرور با یک هدر "Set-Cookie" حاوی مقدار کوکی پاسخ می دهد. سپس مقدار کوکی در مرورگر مشتری ذخیره می شود. با هر درخواست بعدی به وب سرور، مرورگر کوکی را ارسال می کند. این به سرور اجازه می دهد تا کلاینت را بشناسد و وضعیت جلسه را حفظ کند.

یک کوکی بر اساس ویژگی‌های Domain و Path در مقایسه با آن تعریف می‌شود
Same-Origin Policy (SOP)
که به طرح، هاست و پورت متکی است. به عنوان مثال، کوکی زیر را در نظر بگیرید.

مثال

Set-Cookie: key=anyvalue; domain=example.com; Path=/search/

در این مثال، یک کوکی برای دامنه example.com تنظیم شده است و به طور خاص در محدوده /search/path قرار دارد. این بدان معنی است که کوکی حاوی "key=value" تنها زمانی توسط مرورگر ارسال می شود که درخواست ها به آدرس های اینترنتی در دامنه " example.com " و در مسیر "/search/" هدایت شوند.

برخلاف SOP، کوکی‌ها به طور دقیق به یک مبدا محدود نمی‌شوند، مشروط بر اینکه ویژگی‌های Domain و Path کوکی به آن اجازه می‌دهد. این به یک وب‌سایت در یک مبدا اجازه می‌دهد تا کوکی‌ای را تنظیم کند که بتواند توسط منبع دیگری خوانده شود.
@TryHackBox

Domain-Level Cookie Scoping

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


مثال

Set-Cookie: key=anyvalue;domain=. example.com

در این مثال، کوکی با ویژگی دامنه به است. " example.com ” با استفاده از یک نقطه پیشرو، که نشان دهنده یک قرارداد قدیمی است که برای تنظیم کوکی ها استفاده می شود. هنگامی که یک کوکی با دامنه ای به صورت “. example.com "، برای همه زیر دامنه های آن مانند sub.example.com یا tmgm.sub.example.com قابل دسترسی می شود.


مرورگرهای مدرن این رفتار را استاندارد کرده اند و زمانی که domain= example.com (بدون leading dot) یا domain= را تنظیم می کنید. example.com (با نقطه اول)، کوکی ها در هر دو دامنه مشخص شده و همه زیر دامنه های آنها قابل دسترسی خواهند بود.

توجه: روش صحیح restrict و limit scope دامنه این است که به هیچ وجه ویژگی دامنه را شامل نشود.

@TryHackBox

Cookie Tossing Vulnerability

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

مرحله 1: مهاجمی که کنترل vulnerable.example.com را در اختیار دارد، کوکی با نام "sessionID" را روی یک مقدار مشخص تنظیم می کند.

مثال

Set-Cookie:sessionID=valueknowntoattacker;domain= example.com

مرحله 2: هنگامی که قربانی از یک زیر دامنه تحت کنترل مهاجم ( vulnerable.example.com ) بازدید می کند، مرورگر مقدار را ذخیره می کند.

مرحله 3: قربانی از example.com بازدید می کند و با استفاده از شناسه جلسه ثابت به برنامه وارد می شود.

مرحله 4: وقتی قربانی به برنامه وارد می شود، برنامه SessionID جدیدی ایجاد نمی کند.

مرحله 5: مهاجم از همان Session ID برای کنترل حساب قربانی استفاده می کند.

Cookie tossing
حتی زمانی که یک کوکی با نام خاصی از قبل تنظیم شده باشد امکان پذیر است. هنگامی که مرورگر دو کوکی با یک نام دریافت می کند، مرورگر درخواست را معتبر می داند و هر دو را ارسال می کند.

مثال

Set-Cookie:SessionID=setbytheserver;SessionID=attackerknown;domain=.example.com

اکثر برنامه ها در صورت تکرار، اولین پارامتر را پردازش می کنند. در این صورت، می‌توانیم با افزودن مسیرهای طولانی‌تر، کوکی خود را مجبور کنیم. این به این دلیل است که کوکی‌هایی با مسیرهای طولانی‌تر طبق جزئیات مستند شده تحت RFC 6265 [ https://datatracker.ietf.org/doc/html/rfc6265#section-5.4 ] اولویت دارند.

@TryHackBox

شکل 1.6 گزیده ای از RFC 6265 در مورد order کوکی

@TryHackBox

نمونه ای از مسیر کوتاهتر

Set-Cookie:SessionID=setbytheservr;domain=. example.com ;path=/

نمونه ای از مهاجم که مسیر طولانی تری را تنظیم می کند

Set-Cookie:SessionID=attackerknown; domain=.example.com ;path=/admin

وقتی مرورگر این هدرها را پردازش می کند، هر دو کوکی را ذخیره می کند. با این حال، هنگام دسترسی به مسیری که با هر دو کوکی مانند «/admin» مطابقت دارد، کوکی با مسیر طولانی‌تری که توسط مهاجم تنظیم شده است، اولویت دارد.

@TryHackBox

Cookie Bomb Vulnerability


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

بیایید نگاهی به کد جاوا اسکریپت زیر بیندازیم، که چندین کوکی را تنظیم می کند که از "testcookie1" شروع می شود و تا 99 افزایش می یابد، هر کدام با مقدار 4000 "A":

مثال

// تنظیم دامنه

let baseDomain = ' hackerone.com ';

// یک رشته 4000 A برای مقدار کوکی ایجاد کنید

let cookieValue = 'A'.repeat(4000);

// حلقه برای تنظیم چند کوکی

for (let cookieNum = 1; cookieNum < 99; cookieNum++) {

// تنظیم یک کوکی با نام های افزایشی و رشته طولانی به عنوان مقدار

document.cookie='testCookie${cookieNum}=${cookieValue};Domain=${baseDomain}';
}

پس از اجرای این کد جاوا اسکریپت در زمینه hackerone.com ، می توانیم ببینیم که مقدار کوکی تنظیم شده است.

در نتیجه، دسترسی به hackerone.com و زیر دامنه های آن منجر به خطا می شود.

@TryHackBox

شکل 1.7 مجموعه کوکی ها در hackerone.com
@TryHackBox

شکل 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