درک نحوه عملکرد کدگذاری ها می تواند کمک بزرگی در بایپس کردن WAF ها و فیلترهایی باشد که به لیست سیاه متکی هستند.

@TryHackBox

🖥 Reverse-Engineering
- ابزاری برای مهندسی معکوس

Reverse-Engineering
یک آموزش جامع مهندسی معکوس است که معماری های x86، x64، 32 بیتی ARM و 64 بیتی ARM را پوشش می دهد.

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

https://github.com/mytechnotalent/Reverse-Engineering?tab=readme-ov-file
#Tools #Reverse
@TryHackBox

مقدمه ای بر مرورگرها

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

به عنوان مثال، برای محافظت از حریم خصوصی کاربر، بسیاری از مرورگرها اقدامات داخلی مانند کنترل‌های کوکی‌های پیشرفته، حالت‌های مرور خصوصی، مسدود کردن ردیاب‌های شخص ثالث و بسیاری موارد دیگر را ارائه می‌کنند. از نظر امنیتی، مرورگرها سیاست‌های امنیتی داخلی خاصی مانند سیاست همان منبع (SOP) را پیاده‌سازی کرده‌اند، که نحوه تعامل محتوا از مبداهای مختلف در مرورگر را محدود می‌کند، در حالی که چندین مکانیسم امنیتی اختیاری در قالب هدر پیاده‌سازی می‌شوند. و می تواند توسط مدیران وب برای افزایش امنیت استفاده شود.
مرورگرها از افزونه‌ها و افزونه‌هایی پشتیبانی می‌کنند که قابلیت‌های بیشتری مانند مسدود کردن تبلیغات، مدیریت رمز عبور و غیره را ارائه می‌دهند. در حالی که این قابلیت‌های اضافی می‌توانند امنیت کاربر را بهبود بخشند، این قابلیت‌ها نیز می‌توانند توسط یک مهاجم مسلح شوند و به عنوان یک نقطه ضعف عمل کنند. بحث در مورد طول مرورگر یک موضوع پیچیده است و خارج از محدوده این بخش است. شکل 1.3 نمای کلی سطح بالایی از اجزای اصلی مرورگر را نشان می دهد:
@TryHackBox

شکل 1.3 نمای اجمالی سطح بالا از قسمت های داخلی مرورگر
@TryHackBox

اجازه دهید به طور خلاصه در مورد هر یک از اجزاء صحبت کنیم

رابط کاربری

این نشان دهنده 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