HTTP 2
جدیدترین ارتقاء به HTTP 1.1 HTTP 2 است. از نظر سرعت و عملکرد ارتقاهای قابل توجهی را ارائه می دهد. چندین پیشرفت کلیدی به HTTP 2 اجازه می دهد تا کارآمدتر کار کند، مانند Multiplexing، که اجازه می دهد چندین منبع به طور همزمان از طریق یک اتصال تحویل داده شوند. با توجه به این پیشرفت ها، وب سایت ها دیگر نیازی به تقسیم محتوا در چندین دامنه ندارند. یک اتصال واحد می‌تواند چندین درخواست را مدیریت کند، بنابراین تأخیر را به طور مؤثر کاهش می‌دهد.

به عنوان مثال، در HTTP 1.1، زمانی که کاربر می‌خواهد ویدیویی را در YouTube یا در پلتفرم پخش ویدیوی دیگری تماشا کند، این پروسس شامل بارگیری عناصر مختلف صفحه مانند فایل ویدیویی، اسکریپت‌ها، فایل‌های CSS و جاوا اسکریپت است. این بارگیری از طریق استفاده از چندین اتصال TCP مدیریت می شود. با این حال، مرورگرها معمولاً تعداد اتصالات همزمان را به یک دامنه محدود می کنند که می تواند bottlenecks ایجاد کند، به خصوص در صفحاتی که منابع زیادی دارند.

HTTP 2
با یک ویژگی دیگر به نام «Server Push» ارائه می‌شود که به سرور اجازه می‌دهد تا با پیش‌بینی نیاز کلاینت، محتوا را برای کلاینت ارسال کند. 
در مقابل، Server push می تواند توسط سرور با push منابع مخرب (malicious resources)به کلاینت یا spoofing existing objects مورد سوء استفاده قرار گیرد. به طور مشابه، در HTTP 2، مهاجمان می‌توانند فریم‌های هدر بزرگ با اندازه‌های فیلد هدر بیش از حد ارسال کنند. سرورها ممکن است حافظه را بر اساس اندازه هدر اختصاص دهند که منجر به انکار سرویس شود.

@TryHackBox

ابزاری برای ساخت پروکسی لیست‌های فعال: Link
@TryHackBox

نقشه راه تیم آبی

├── Foundations
│   ├── Basic Networking
│   │   ├── TCP/IP
│   │   ├── DNS
│   │   ├── DHCP
│   │   ├── Subnetting
│   │   └── Network Topologies
│   ├── Operating Systems
│   │   ├── Windows
│   │   │   ├── Active Directory
│   │   │   ├── Group Policy
│   │   │   └── Windows Event Logs
│   │   └── Linux
│   │       ├── File Permissions
│   │       ├── Syslog
│   │       └── Scripting (Bash, Python)
│   └── Cybersecurity Fundamentals
│       ├── CIA Triad
│       ├── Risk Management
│       ├── Threat Models
│       └── Attack Vectors
├── Threat Intelligence
│   ├── OSINT
│   │   ├── Tools (Maltego, Recon-ng)
│   │   └── Data Sources (Shodan, Censys)
│   ├── Threat Hunting
│   │   ├── Hypothesis-Driven Hunting
│   │   ├── TTPs
│   │   └── Use Cases Development
│   └── IOCs
│       ├── IP Addresses
│       ├── Hash Values
│       ├── Domains
│       └── File Names
├── Security Operations
│   ├── Monitoring and Logging
│   │   ├── SIEM
│   │   │   ├── Tools (Splunk, ELK Stack, QRadar)
│   │   │   └── Log Parsing and Correlation
│   │   └── Log Analysis
│   │       ├── Log Sources (Windows Event Logs, Syslog)
│   │       └── Log Aggregation and Storage
│   ├── Incident Response
│   │   ├── IR Plan Development
│   │   ├── Incident Handling Procedures
│   │   └── Digital Forensics
│   │       ├── Memory Analysis
│   │       └── Disk Forensics
│   ├── EDR
│   │   ├── Tools (CrowdStrike, Carbon Black)
│   │   └── Endpoint Visibility and Control
│   └── NSM
│       ├── Tools (Zeek, Suricata)
│       └── Traffic Analysis
├── Vulnerability Management
│   ├── Vulnerability Assessment
│   │   ├── Scanning Tools (Nessus, OpenVAS)
│   │   └── Assessment Methodologies
│   ├── Patch Management
│   │   ├── Patch Deployment Strategies
│   │   └── Patch Testing and Validation
│   └── Configuration Management
│       ├── Secure Configuration Guides
│       └── Configuration Monitoring
├── Identity and Access Management
│   ├── Authentication Methods
│   │   ├── MFA
│   │   └── SSO
│   ├── Authorization
│   │   ├── RBAC
│   │   └── ABAC
│   └── Identity Governance
│       ├── User Lifecycle Management
│       └── Access Reviews and Recertification
├── Secure Architecture
│   ├── Network Segmentation
│   │   ├── VLANs
│   │   └── Microsegmentation
│   ├── Zero Trust Architecture
│   │   ├── Principles and Implementation
│   │   └── Identity-Centric Security
│   └── Encryption
│       ├── Data at Rest
│       │   ├── Disk Encryption
│       │   └── Database Encryption
│       └── Data in Transit
│           ├── TLS/SSL
│           └── VPNs
├── Awareness and Training
│   ├── Security Awareness Programs
│   │   ├── Regular Training Sessions
│   │   └── Security Newsletters
│   ├── Phishing Simulations
│   │   ├── Phishing Campaigns
│   │   └── Analysis of Results
│   └── User Training
│       ├── Role-Based Training
│       └── Just-in-Time Training
├── Compliance and Governance
│   ├── Regulatory Requirements
│   │   ├── GDPR
│   │   ├── HIPAA
│   │   └── PCI-DSS
│   └── Policy Development
│       ├── Security Policies
│       ├── Incident Response Policies
│       └── Data Protection Policies
├── Advanced Defense Techniques
│   ├── Deception Technologies
│   │   ├── Honeypots
│   │   └── Honeytokens

@TryHackBoxOfficial

EVOLUTION OF MODERN WEB APPLICATIONS

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

Shift in Architecture

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

Evolution in Technology Stacks

تکامل در پشته‌های فناوری نشان‌دهنده تغییر در نحوه توسعه و استقرار برنامه‌های کاربردی وب است. فناوری‌ها و معماری‌های جدیدتر مانند میکروسرویس‌ها و محاسبات بدون سرور و پایگاه داده‌های جدیدتر فناوری‌هایی مانند NoSQL ظهور کرده‌اند که جایگزین‌هایی برای  LAMP Stack traditional ارائه می‌کنند. بیایید stack های مختلف را درک کنیم.

LAMP Stack

در زمان نگارش این کتاب، 76.6 درصد از کل وب سایت ها از PHP استفاده می کنند.
تعداد قابل توجهی از توسعه دهندگانی که از PHP به عنوان زبان برنامه نویسی سمت سرور خود استفاده می کنند، لینوکس را به عنوان سیستم عامل، آپاچی را به عنوان سرور HTTP و MySQL را به عنوان سرور پایگاه داده خود ترجیح می دهند. این فن‌آوری‌ها با هم چیزی را تشکیل می‌دهند که به  LAMP Stack معروف است، مخفف لینوکس، آپاچی، MySQL و PHP/Perl/Python. در طول سال ها، هر یک از این اجزای فردی تکامل یافته است.
لینوکس به طور مداوم به روز می شود و یک انتخاب ارجح برای محیط های سرور باقی می ماند. در حالی که آپاچی به طور گسترده استفاده می شود، با رقابت سرورهای وب مانند Nginx روبرو است. MySQL تا حد زیادی محبوب است، اما جایگزین سیستم های پایگاه داده مانند PostgreSQL ظهور کرده اند. PHP در طول زمان شاهد پیشرفت های قابل توجهی بوده است.
محبوبیت پایتون به ویژه در زمینه های نوظهور افزایش یافته است و پرل کمتر برجسته شده است.

MEAN/MERN Stack

در حالی که تمام اجزای منفرد تشکیل دهنده LAMP به طور مداوم در حال تشکیل هستند
به‌روزرسانی شده، توسعه‌دهندگان از این مؤلفه‌ها به جز لینوکس دور شده‌اند و به سمت پشته‌های پیشرفته‌تر مانند پشته‌های MEAN/MERN تغییر کرده‌اند.
MEAN (MongoDB، Express.js، Angular، Node.js) و MERN (MongoDB، Express.js، React، Node.js) پشته های محبوبی برای توسعه هستند. این پشته ها یک زبان یکپارچه، یعنی جاوا اسکریپت را در هر دو طرف کلاینت و سرور ارائه می دهند و توسعه را کارآمدتر و ساده تر می کنند. پذیرش پایگاه‌های داده NoSQL مانند MongoDB، Cassandra و Redis جایگزین‌هایی برای پایگاه‌های داده سنتی رابطه‌ای فراهم می‌کند. در حالی که MERN به انتخاب محبوب تبدیل شده است، مجموعه ای از مشکلات مربوط به امنیت را به همراه داشته است، به عنوان مثال، معرفی یک کلاس جدید از
آسیب پذیری ها مانند Node.

js injection، NoSQL injection، Dependency Injection ...و به زودی.

@TryHackBox

Single-Page Applications (SPAs)

اپلیکیشن های Single-Page اخیراً رایج شده اند و برای بهبود تجربه کاربر در نظر گرفته شده اند. برخلاف وب‌سایت‌های traditional، هر بار که یک فرم را پیمایش یا ارسال می‌کنید، یک صفحه جدید از سرور دریافت می‌شود. SPA در ابتدا کل صفحه وب و تمام اجزای آن را فقط یک بار بارگذاری می کند. پس از بارگذاری اولیه، SPA به صورت پویا محتوا را در همان صفحه به روز می کند و نیاز به بارگذاری مجدد صفحه وب را از بین می برد.
SPA
ها اغلب برای واکشی داده ها به API های RESTful یا Graph API تکیه می کنند و آنها را برای ادغام با معماری میکروسرویس مناسب می کند. آنها با فریم ورک های جاوا اسکریپت مانند AngularJS، React و بسیاری دیگر ساخته شده اند. به دلیل اتکای زیاد به جاوا اسکریپت برای ارائه و به روز رسانی پویا محتوا، SPA ها اغلب در برابر اسکریپت های متقابل مبتنی بر DOM آسیب پذیر هستند.

Use of Cloud Components

رایانش ابری به طور قابل توجهی توسعه میکروسرویس ها را با افزایش مقیاس پذیری تسهیل کرده است. فن آوری هایی مانند Docker و Kubernetes برای مدیریت ریزسرویس ها و ارائه کانتینر برای تفکیک و مقیاس بندی موثر بسیار مهم هستند.
به طور مشابه، در شیوه های توسعه وب، فرهنگ DevOps برجسته شده است و بر همکاری و اتوماسیون بین تیم های توسعه و عملیات تمرکز دارد. در تکمیل این، خطوط لوله CI/CD فرآیند تحویل نرم‌افزار را خودکار می‌کند و انتشار سریع‌تر و کارآمدتر را در یک محیط کانتینری امکان‌پذیر می‌کند.

Serverless Architecture

به طور فزاینده ای در زمینه محبوبیت پیدا کرده است 
SPA
ها و استقرار میکروسرویس ها. علیرغم نامش، معماری Serverless Architecture شامل سرورها می شود. در این مدل، ارائه دهنده ابر مسئولیت مدیریت سرورها را بر عهده دارد. توسعه دهندگان کد می نویسند و فقط برای زمان اجرای کد پرداخت می کنند. Serverless Architecture مجموعه ای از چالش های امنیتی خاص خود را دارد. در بخش سرویس های وب به آن خواهیم پرداخت.

UNDERSTANDING DATA ENCODING

رمزگذاری در برنامه های کاربردی وب برای اطمینان از اینکه ارتباطات از مجموعه ای مشخص از قوانین و استانداردها پیروی می کند استفاده می شود. URL ها فقط می توانند شامل مجموعه محدودی از کاراکترها باشند که عمدتاً حروف عددی (حروف و اعداد) و special characters هستند. وقتی یک ورودی خارج از این مجموعه مجاز درج می شود، این کاراکترها باید برای جلوگیری از ابهام کدگذاری شوند.
فرآیند رمزگذاری و رمزگشایی عموماً در پشت صحنه اتفاق می افتد: کاربران می توانند کاراکترهای مختلفی را وارد کنند و مرورگرها و برنامه ها از رمزگذاری و رمزگشایی مراقبت می کنند. هنگامی که کاربر یک کاراکتر غیرمجاز را در مرورگر ارائه می‌کند، قبل از پردازش درخواست، به طور خودکار کدگذاری می‌شود.

@TryHackBox

شکل 1.1 جدول نشان دهنده کاراکترهایی است که نیاز به رمزگذاری دارند
@TryHackBox

شکل 1.1 [ https://perishablepress.com/stop-using-unsafe-characters-in urls/ ] نموداری را نشان می دهد که کاراکترهایی را توضیح می دهد که می توان با آنها رفتار کرد.
"ایمن" و آنهایی که باید رمزگذاری شوند.
شایان ذکر است که کاراکترهای رزرو شده تنها زمانی نیاز به رمزگذاری دارند که فراتر از هدف تعریف شده خود استفاده شوند. بیایید انواع اصلی رمزگذاری داده مورد استفاده در برنامه های وب را مورد بحث قرار دهیم:
• URL encoding
• HTML encoding
• Base 64 encoding
• Unicode encoding

@TryHackBox

URL Encoding

رمزگذاری URL، همچنین به عنوان رمزگذاری درصد شناخته می شود، پروسسی است که برای رمزگذاری کاراکترهای رزرو شده در URL استفاده می شود. در رمزگذاری URL، کاراکترها بخشی از آن نیستند مجموعه مجاز برای URL ها با یک نماد درصد (%) و به دنبال آن مقدار هگزادسیمال آنها جایگزین می شود. به عنوان مثال، کاراکتر علامت ("&") معمولا به عنوان جداکننده در یک رشته کوئری استفاده می شود، باید برای جلوگیری از ابهامات کدگذاری شود. برای مثال URL زیر را در نظر بگیرید:

مثال

https://example.com/login.php?username=tmgm&password=t&mgm

در این مثال، کلمه عبور حاوی علامت "&" است، که اگر کدگذاری نشده باشد به عنوان یک پارامتر در نظر گرفته می شود و رمز عبور را روی "t" و "mgm" تنظیم می کند. برای جلوگیری از این امر، علامت "&" به عنوان "% 26" کدگذاری می شود، که منجر به URL نهایی می شود:

مثال

https://example.com/login.php?username=tmgm&password=t
%26mgm

در اینجا جدول 1.2 نشان دهنده کاراکترهای رایج رمزگذاری شده و نسخه های رمزگذاری شده آنها است:

Double Encoding

در کدگذاری مضاعف، کاراکترها دو بار رمزگذاری می‌شوند: سطح اول رمزگذاری، کاراکتر را به شکل درصد رمزگذاری شده تبدیل می‌کند. سطح دوم رمزگذاری برای کاراکترهای درصد رمزگذاری شده اعمال می شود. به عبارت دیگر، این

@TryHackBox

جدول 1.2 نویسه های رایج رمزگذاری شده و نسخه های رمزگذاری شده
@TryHackBox

به این معنی است که به خود علامت درصد (%) اعمال می شود، همراه با مقدار هگزادسیمال کاراکتر رمزگذاری شده بار دیگر کدگذاری می شود.

برای مثال، اگر می‌خواهید کاراکتر «>» را دوبار رمزگذاری کنید، ابتدا آن را به صورت %3C رمزگذاری می‌کنید. سپس، «%» را به صورت %25 رمزگذاری می‌کنید، که در نتیجه %253C به صورت double-encoded  شده است.

این یک تکنیک رایج است که می تواند برای بایپس کردن WAF ها و فیلترهای سطح برنامه که URL ها را یک بار رمزگشایی می کنند، استفاده شود. اگر یک WAF فقط یک بار رمزگشایی کند، %253C را بی‌ضرر می‌بیند، اما متوجه نمی‌شود که رمزگشایی دوم آن را به کاراکتر «>» تبدیل می‌کند. بعداً به این تکنیک ها خواهیم پرداخت.

@TryHackBox

HTML Encoding

در HTML، کاراکترهای خاص معانی خاصی دارند و در صورت عدم استفاده صحیح می توانند منجر به ابهاماتی شوند. برای مثال، کاراکترهای "<" و ">" می توانند باز و بسته شدن یک تگ HTML را نشان دهند. برای اطمینان از اینکه این کاراکترها در قالب متنی نمایش داده می شوند، به جای اینکه به عنوان نحو HTML تفسیر شوند، باید HTML کدگذاری شوند.

رمزگذاری HTML شامل جایگزینی این کاراکترهای خاص با موجودیت های کاراکتر است. به عنوان مثال، علامت کمتر از «<» در HTML را می توان با «&lt» جایگزین کرد، و برای علامت بزرگتر از «>»، از «&gt» استفاده می کنیم. علاوه بر این، رمزگذاری HTML فقط محدود به کاراکترهایی نیست که معنای خاصی در نحو HTML دارند. همچنین می تواند کاراکترهایی را نشان دهد که به راحتی در صفحه کلیدهای استاندارد در دسترس نیستند. به عنوان مثال، نماد حق چاپ "©" را می توان در HTML به عنوان "&copy" نشان داد.

طبق مشخصات HTML، همه ارجاعات کاراکتر باید با علامت "&" شروع شوند، این می تواند با تغییرات متعددی مانند رمزگذاری اعشاری و هگزادسیمال دنبال شود. در اینجا روش های مختلفی برای نشان دادن این کاراکتر ها وجود دارد.
@TryHackBox

جدول 1.3 روش های مختلف برای نشان دادن این شخصیت ها

نکته: از جدول می بینید که می توانیم از صفرهای ابتدایی در اشکال اعشاری و هگزادسیمال استفاده کنیم.
@TryHackBox

Base64 Encoding

از رمزگذاری Base64 می توان برای نمایش داده های باینری به صورت یک رشته ASCII استفاده کرد ‌.

یکی از رایج‌ترین کاربردهای base64 برای انتقال ایمن پیوست‌های ایمیل است، زیرا سرورهای ایمیل اغلب نویسه‌های خاصی مانند خطوط جدید را تغییر می‌دهند یا اشتباه تفسیر می‌کنند که منجر به ابهام یا خرابی داده‌ها می‌شود.

به عنوان مثال، رشته "Hello\nWorld" را در نظر بگیرید، جایی که "\n" نشان دهنده یک کاراکتر خط جدید است. رشته به صورت زیر treated می شود:


مثال

Hello
World

این رشته شامل یک خط جدید بعد از حرف "o" است. در ASCII، این رشته با مقادیر decimal نشان داده می شود.

مثال

72 101 108 108 111 10 119 111 114 108 100

در این مثال، دنباله بایت "10" نشان دهنده کاراکتر "newline" است. سیستم های ایمیل ممکن است این کاراکتر را به درستی تفسیر نکنند. از این رو، با رمزگذاری این کاراکترها با استفاده از کدگذاری base64، می‌توانیم آنها را به عنوان کاراکترهای ASCII نشان دهیم، بنابراین کاراکترهایی مانند newline که سیستم‌های ایمیل مشکل‌ ساز هستند حذف می‌شوند.

پشتیبانی از کدگذاری و رمزگشایی base64 به طور گسترده در تمام زبان های برنامه نویسی وب در دسترس است. جاوا اسکریپت توابع “btoa()” و “atob()” را برای مدیریت base64 فراهم می کند.

شایان ذکر است که base64 معمولا توسط توسعه دهندگان اشتباه گرفته می شود به عنوان یک طرح encryption به جای یک طرح encoding. حتی در تعامل‌های دنیای واقعی، ممکن است مواردی را بیابید که اطلاعات حساس با base64 کدگذاری می‌شوند و در نتیجه داده‌های حساس در معرض دید قرار می‌گیرند. شکل 1.2 کدگذاری/رمزگشایی base64 را با استفاده از توابع "btoa" و "atob" نشان می دهد:

شکل 1.2 کدگذاری/رمزگشایی Base64
@TryHackBox

Unicode Encoding

یونیکد شامل تعداد زیادی کاراکتر از زبان های متعدد در سراسر جهان است. به عنوان مثال، اگر بخواهید متن عربی یا فارسی را در صفحه وب قرار دهید، متوجه خواهید شد که این کاراکترها بخشی از ASCII نیستند، زیرا اساساً برای انگلیسی ساخته شده است و مجموعه کاراکترهای محدودی دارد. اینجاست که یونیکد وارد عمل می شود.

برای ترسیم موثر چنین مجموعه بزرگی از کاراکترها، یونیکد از چندین کاراکتر استفاده می کند کدگذاری هایی مانند UTF-8، UTF-16 و UTF-32. بیایید بررسی کنیم که چگونه یونیکد می تواند برای نشان دادن کاراکترهای رایج استفاده شود:

@TryHackBox

جدول 1.4 یونیکد برای نشان دادن کاراکترهای رایج
@TryHackBox

درک نحوه عملکرد کدگذاری ها می تواند کمک بزرگی در بایپس کردن 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

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