Try Hack Box

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

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

شکل 1.7 مجموعه کوکی ها در hackerone.com @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

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

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

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

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

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

شکل 1.6 گزیده ای از RFC 6265 در مورد order کوکی @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

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

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

Content Security Policy (CSP ) یک سیاست امنیتی است که به طور گسترده توسط همه مرورگرهای مدرن پشتیبانی می شود و برای کاهش حملات تزریق مانند XSS، clickjacking و سایر حملات تزریق کد ناشی از اجرای غیرمجاز اسکریپت طراحی شده است. این خط‌مشی اختیاری است و می‌تواند از طریق سرصفحه‌های «Content-Security-Policy» اجرا شود. بیایید نمونه‌ای را ببینیم که چگونه می‌توان CSP را طوری تنظیم کرد که به مرورگرها اجازه دهد جاوا اسکریپت را فقط از یک منبع مشخص، یعنی " http://code.jquery.com/jquery-1.11.0.min.js " اضافه کنند. مثال: Content-Security-Policy:script-src http://code.jquery.com/jquery-1.11.0.min.js ; این سیاست تضمین می‌کند که فقط جاوا اسکریپت از کتابخانه جی کوئری مشخص شده اجرا می‌شود و هر اسکریپت دیگری را که از این منبع نیست مسدود می‌کند. CSP به عنوان یک سیاست بسیار سختگیرانه معرفی شد، و از این رو، شکستن چندین وب سایت از دیدگاه دنیای واقعی عملی نبود. با این حال، با معرفی لول های بیشتر، این سیاست کمتر سختگیرانه و عملی شد. لول های CSP از لول 1 با دستورالعمل های اساسی به لول 3 پیشرفت کردند و کنترل های پیشرفته ای داشتند که امکان مدیریت دقیق منابع را فراهم می کرد. CSP دستورالعمل‌هایی را برای کنترل منابعی که یک صفحه می‌تواند بارگذاری کند، تعریف می‌کند، که به توسعه‌دهندگان اجازه می‌دهد منابعی را که در لیست سفید قرار می‌گیرند مشخص کنند. این شامل اسکریپت ها، سبک ها، تصاویر و موارد دیگر می شود. CSP Level 1 : این سطح دستورالعمل‌های اساسی را معرفی می‌کند که به توسعه‌دهندگان اجازه می‌دهد منابعی را که باید در لیست سفید قرار می‌گیرند را مشخص کنند. این شامل اسکریپت ها، سبک ها، تصاویر و موارد دیگر می شود. CSP Level 2 : این سطح به توسعه دهندگان کنترل بیشتری بر روی اینکه کدام مبدا می تواند سایت شما را در فریم ها جاسازی کند، ارائه می دهد. CSP Level 3 : این سطح در حال حاضر در حال توسعه است و تنها بخش‌هایی از آن تحت مرورگرهای مدرن پیاده‌سازی شده‌اند و کنترل دقیق‌تری بر تعاملات منابع ارائه می‌دهند. در آینده بیشتر درباره CSP و بایپس کردن  بالقوه آن به دلیل پیکربندی نادرست (misconfiguration)بررسی خواهیم کرد. @TryHackBox

توجه: در جدول، store.example.com و about:blank در یک مبدا نشان داده شده اند. این ممکن است برای برخی از خوانندگان گیج کننده باشد. "About:blank" منشأ ندارد و منشأ سندی را که آن را ایجاد کرده است به ارث می برد. به عنوان مثال، اگر صفحه ای در https://store.example.com پنجره جدیدی به about:blank باز کند، صفحه about:blank مبدا https://store.example.com را به ارث می برد. @TryHackBox

جدول 1.5 قوانین تعامل بین مبداهای مختلف

شکل ۱.۵ SOP violation

تصویر صفحه در شکل 1.5 نشان می دهد که دسترسی به " www.gmail.com " از " https://output.jsbin.com " به دلیل عدم تطابق نام میزبان مسدود شده است. جدول زیر (جدول 1.5) قوانین تعامل بین مبداهای مختلف را تشریح می کند و شرایطی را مشخص می کند که تحت آن مبدا یکسان رفتار می شود. @TryHackBox

Code : <script> xhr = new XMLHttpRequest(); xhr.open('GET', 'www.gmail.com', true); xhr.onreadystatechange = function () { if (xhr.readyState === XMLHttpRequest.DONE && xhr. status === 200) {document.write(xhr.responseText); } }; xhr.send(); </script> @TryHackBox

برای درک بهتر SOP، مثالی از کد زیر را که در output.jsbin.com میزبانی شده است، می‌آوریم که از درخواست Ajax برای دریافت پاسخ gmail.com و نوشتن آن در صفحه وب با استفاده از یک سند استفاده می‌کند. function نوشتن. @TryHackBox

شکل 1.4 مبدا در same-origin policy @TryHackBox

Same-Origin Policy (SOP) یکی از اساسی ترین و اصلی ترین سیاست ها در مرورگرها است. این خط‌مشی در اصل از دسترسی صفحات وب در یک مبدا جلوگیری می‌کند. Origin معمولاً به عنوان ترکیبی از طرح، دامنه و پورت گفته می شود. به عبارت ساده، اگر طرح، دامنه و شماره پورت آنها مطابقت داشته باشد، دو صفحه وب از یک مبدا در نظر گرفته می شوند. در اینجا لازم به ذکر است که SOP ماهیت ناسازگار و ناهمگن است و از این رو اجرای آن در مرورگرها ممکن است متفاوت باشد. یک مثال از گذشته اینترنت اکسپلورر شامل یک طرح و یک هاست است. با این حال، پورت ها در نظر گرفته نمی شوند. @TryHackBox

خوندن چت‌های ناشناس تلگرام @TryHackBox

معلوم شد ربات‌های چت ناشناس، در حال ذخیره سازی اطلاعات شما هستند! لینک کامل خبر