رابط کاربری

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


Browser Engine

به عنوان رابط بین رابط کاربری و موتور rendering عمل می کند. به عنوان مثال، هنگامی که یک کاربر با رابط مرورگر تعامل می کند، مانند تایپ یک URL، کلیک کردن بر روی لینک، یا تعامل با فرم، موتور مرورگر مسئول پردازش دستور است.

Rendering Engine

موتور Rendering بخشی جدایی ناپذیر از مرورگرهای وب است، اساساً HTML، CSS و جاوا اسکریپت را به صفحات بصری و تعاملی تبدیل می کند. هر مرورگر از یک موتور خاص استفاده می کند: کروم و اپرا از Blink استفاده می کنند، فایرفاکس از Gecko استفاده می کند و Safari روی WebKit کار می کند. این موتورها نشانه‌گذاری و اسکریپت‌نویسی را پردازش می‌کنند تا Document Object Model (DOM) صفحه وب را ایجاد کنند، سبک‌ها را از CSS اعمال می‌کنند، جاوا اسکریپت را برای محتوای پویا اجرا می‌کنند، و سپس طرح‌بندی و نمایش بصری صفحه را روی صفحه نمایش می‌دهند.
با توجه به اینکه هر مرورگر وب از یک موتور Rendering خاص استفاده می‌کند، آسیب‌پذیری در موتوری مانند Blink، Gecko یا WebKit می‌تواند همه مرورگرهای متکی به آن موتور خاص را در معرض خطرات امنیتی بالقوه قرار دهد.

Networking

این کامپوننت مسئول برقراری تماس های شبکه اصلی مانند HTTP و DNS است.

UI Backend

این برای دسترسی به روش های سیستم عامل اساسی مانند جعبه های ترکیبی، جعبه های کاربر و غیره استفاده می شود.

JavaScript Interpreter

این جزء مسئول تجزیه و اجرای کد جاوا اسکریپت موجود در صفحات وب است.

Data Stroge

این مؤلفه مسئول ذخیره سازی داده ها در سمت سرویس گیرنده است. این شامل مکانیسم هایی مانند کوکی ها، ذخیره سازی وب، IndexedDB، WebSQL و FileSystem است.

سیاست ها و مکانیسم های امنیتی مرورگر اصلی

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

@TryHackBox

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

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

@TryHackBox

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

در اینجا لازم به ذکر است که SOP ماهیت ناسازگار و ناهمگن است و از این رو اجرای آن در مرورگرها ممکن است متفاوت باشد. یک مثال از گذشته اینترنت اکسپلورر شامل یک طرح و یک هاست است. با این حال، پورت ها در نظر گرفته نمی شوند.

@TryHackBox

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

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

Code :

<noscript>
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();
</noscript>

@TryHackBox

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

جدول زیر (جدول 1.5) قوانین تعامل بین مبداهای مختلف را تشریح می کند و شرایطی را مشخص می کند که تحت آن مبدا یکسان رفتار می شود.

@TryHackBox

شکل ۱.۵ SOP violation

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

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

Content Security Policy (CSP )

یک سیاست امنیتی است که به طور گسترده توسط همه مرورگرهای مدرن پشتیبانی می شود و برای کاهش حملات تزریق مانند XSS، clickjacking و سایر حملات تزریق کد ناشی از اجرای غیرمجاز اسکریپت طراحی شده است. این خط‌مشی اختیاری است و می‌تواند از طریق سرصفحه‌های «Content-Security-Policy» اجرا شود. بیایید نمونه‌ای را ببینیم که چگونه می‌توان CSP را طوری تنظیم کرد که به مرورگرها اجازه دهد جاوا اسکریپت را فقط از یک منبع مشخص، یعنی " http://code.jquery.com/jquery-1.11.0.min.js " اضافه کنند.

مثال:

Content-Security-Policy:noscript-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

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) وجود دارد. با این حال، یک کد آسیب‌پذیر در یک برنامه ممکن است به کاربران اجازه دهد تا کوکی‌ها را از طریق پارامترهای قابل کنترل توسط کاربر تنظیم کنند.