💡Hash-Buster:
هش ها را در چند ثانیه بشکنید
https://github.com/s0md3v/Hash-Buster

ویژگی ها :
شناسایی خودکار نوع هش
پشتیبانی از MD5، SHA1، SHA256، SHA384، SHA512
می تواند هش ها را از یک فایل استخراج و کرک کند
می تواند هش ها را از یک دایرکتوری به صورت بازگشتی پیدا کند
چند رشته ای

نصب و استفاده

توجه: Hash Buster با python2 سازگار نیست، در عوض آن را با python3 اجرا کنید. همچنین، Hash-Buster از برخی APIها برای جستجوی هش استفاده می کند، اگر پارانوئید هستید، کد منبع را بررسی کنید.
Hash-Buster
را می توان مستقیماً از اسکریپت پایتون اجرا کرد، اما من به شما پیشنهاد می کنم آن را با make install نصب کنید.

پس از نصب، می‌توانید با دستور buster به آن دسترسی داشته باشید.

شکستن یک هش

نیازی نیست نوع هش را مشخص کنید. Hash Buster آن را در کمتر از 3 ثانیه شناسایی و شکسته می‌کند.

استفاده:
buster -s <hash>

یافتن هش از یک دایرکتوری

بله، فقط یک دایرکتوری را مشخص کنید و Hash Buster تمام فایل ها و دایرکتوری های موجود در آن را بررسی می کند و به دنبال هش می گردد.
استفاده:
buster -d /root/Documents

کرک کردن هش از یک فایل
Hash Buster
می تواند هش های شما را پیدا کند حتی اگر در فایلی مانند این ذخیره شده باشند
simple@gmail.com:21232f297a57a5a743894a0e4a801fc3
{"json@gmail.com":"d033e22ae348aeb5660fc2140aec35850c4da997"}
surrondedbytext8c6976e5b5410415bde908bd4dee15dfb167a9c873fc4bb8a81f6f2ab448a918surrondedbytext
استفاده:
 buster -f /root/hashes.txt

تعیین تعداد رشته ها
هنگامی که تعداد زیادی هش برای کرک کردن با درخواست‌های موازی دارید، چند رشته می‌تواند به طرز باورنکردنی سرعت کلی را به حداقل برساند.
buster -f /root/hashes.txt -t 10

@TryHackBox

مقدمه ای بر وب و مرورگر - بخش اول

مقدمه

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

مقدمه ای بر HTTP - بخش اول

پروتکل انتقال ابرمتن (HTTP) پروتکلی است که شبکه جهانی وب را اجرا می کند. در یک سطح اساسی، مبتنی بر معماری سرویس گیرنده-سرور است که به موجب آن کلاینت محتوا را درخواست می کند (معمولاً از طریق مرورگرها) و سرور/برنامه پاسخ را ارائه می دهد. درخواست مشتری به سرورها را می توان از طریق دستگاه های واسطه مانند پراکسی معکوس، load balancers و فایروال برنامه های وب (WAF) هدایت کرد. پورت پیش‌فرض برای انتقال HTTP پورت 80 TCP (پروتکل کنترل انتقال) است، اما می‌تواند روی پورت‌های مختلف نیز کار کند و می‌تواند در پروتکل‌های دیگر کپسوله شود.

ویژگی های HTTP

در زیر برخی از ویژگی های اصلی HTTP آورده شده است:
Statelessness:
HTTP
یک پروتکل stateless است، به این معنی که دو درخواست هیچ ارتباطی با یکدیگر ندارند. با این حال، برای مدیریت حالت هایی مانند ورود به سیستم، مکانیسم هایی مانند کوکی ها استفاده می شود.

عدم وجود رمزگذاری ذاتی: HTTP یک پروتکل رمزگذاری نشده است که به این معنی است که هر وسیله واسطه ای در شبکه، مانند روتر یا  پروکسی ها، قادر به خواندن و تغییر ترافیک خواهند بود. برای حل این مشکل، HTTPS HTTP را در یک لایه رمزگذاری TLS/SSL (لایه انتقال امنیت / سوکت های امن) کپسوله می کند.

توسعه پذیری: HTTP به گونه ای طراحی شده است که قابل توسعه باشد، به این معنی که از آن استفاده می کند هدر ها در درخواست ها و پاسخ ها برای انتقال داده های متا و سایر اطلاعات مرتبط. این امکان اجرای ویژگی های جدید را بدون ایجاد تغییرات در هسته فراهم می کند.

قابلیت اطمینان: HTTP از طریق TCP منتقل می شود، به این معنی که قابلیت reliabil تضمین شده است. TCP یک پروتکل اتصال گرا است که تضمین می کند بسته های داده به ترتیب و بدون هیچ خطایی تحویل داده می شوند.
#webhacking 0x01
@TryHackBox

ارتباطات HTTP

ارتباطات HTTP بر اساس درخواست HTTP و پاسخ HTTP است.
کلاینت درخواست HTTP را با درخواست منبع خاصی به سرور ارسال می کند و سرور با پاسخ HTTP پاسخ می دهد. بیایید نمونه درخواست HTTP را تجزیه و تحلیل کنیم.

درخواست HTTP زیر برای دسترسی به فایل "index.html" تلاش می کند

میزبانی شده در redseclabs.com/index.html .


HTTP Request
GET /index.html HTTP/1.1
Host: www.redseclabs.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64)
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.4430.
212 Safari/537.36
Referer: https://google.com

GET /index.html HTTP/1.1
گت(GET) به روش HTTP که برای این درخواست استفاده می شود و سپس به آن اشاره می کند منبع درخواست شده در این مورد، "index.html" است. این با نسخه پروتکل HTTP، یعنی HTTP/1.0 دنبال می شود.

HOST: www.redseclabs.com

فیلد host به میزبانی اشاره دارد که درخواست به آن ارسال می شود. فیلد host الزامی است زیرا یک IP می تواند چندین وب سایت یا host مجازی را میزبانی کند.

User-Agent : Mozilla/5.0

قسمت user-agent مرورگر و سیستم عامل مورد استفاده برای دسترسی به وب سایت را نشان می دهد. معمولاً برای ارائه صفحات سفارشی استفاده می شود، به ویژه برای اطمینان از سازگاری متقابل با مرورگرهای مختلف. عبارت Mozilla/5.0 در رشته user-agent یک مصنوع تاریخی است. اکثر مرورگرها به دلایل سازگاری، رشته عامل کاربر خود را با Mozilla/5.0 شروع می کنند.
در انتهای رشته، وجود Chrome/90.0.4430.212 نشان دهنده نسخه مرورگر است.
Referer: www.google.com

هدر "referer" برای نشان دادن URL صفحه وب که کاربر از آنجا آمده است به سرور استفاده می شود. به عنوان مثال، اگر هدر Referer www.google.com را نشان دهد، به این معنی است که کاربر با کلیک کردن روی یک لینک در جستجوی Google به وب سایت فعلی رسیده است.
@TryHackBox

Server: Apache/2.4.41 (Unix)

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

Content-Length : 450
این فیلد اندازه محتوای پاسخ را بر حسب بایت مشخص می کند. در این حالت 450 بایت است.

Content-Type: text/html; charset=UTF-8

این فیلد نوع محتوای ارسال شده (HTML) و رمزگذاری کاراکتر مورد استفاده، یعنی "UTF-8" را نشان می دهد.

Connection: Close
این فیلد نشان می‌دهد که پس از ارسال پاسخ، سوکت TCP/IP بسته می‌شود و کاربران باید قبل از برقراری ارتباط بیشتر، سوکت جدیدی را باز کنند. از طرف دیگر، می توان آن را روی "Keep-Alive" تنظیم کرد که اتصال را برای درخواست های بعدی باز نگه می دارد.

@TryHackBox

کدهای پاسخ HTTP

کدهای پاسخ HTTP با سه رقم نشان داده می شوند که وضعیت پاسخ را نشان می دهد. هر کد وضعیت نشان دهنده دسته های مختلف پاسخ است:

جدول 1.1 کدهای پاسخ HTTP رایج
@TryHackBox

روش های درخواست HTTP

اچ تی تی پی شامل روش های مختلفی است، اما ضروری ترین آنها GET و POST هستند. در حالی که این روش ها معمولاً در تعاملات وب استفاده می شوند، روش های دیگر اختیاری هستند و ممکن است اهداف خاصی را دنبال کنند. GET به طور traditionally برای بازیابی محتوا و POST برای ارسال محتوا به سرور استفاده می شود. با این حال، GET همچنین می تواند برای ارسال محتوا به سرور استفاده شود. بیایید نمونه ای از فرم ورود با استفاده از درخواست GET برای پردازش نام کاربری و رمز عبور برای احراز هویت کاربر را در نظر بگیریم.

Request
GET /login.php?username=myusername&password=mypassword
HTTP/1.1
Host: www.redseclabs.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.
4430.212 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Content-Length: 34
Connection: close

مشکلات کمی با این رویکرد از نقطه نظر امنیتی وجود دارد:

• درخواست‌های GET در گزارش‌های سرور ثبت می‌شوند، بنابراین هر کسی که به این گزارش‌ها دسترسی داشته باشد، مانند کاربران غیرمجاز که از آسیب‌پذیری‌های امنیتی سوء استفاده می‌کنند، می‌توانند URL کامل را ببینند. این موضوع زمانی که نقاط پایانی به‌طور ناخواسته گزارش‌ها را درز می‌کنند یا زمانی که دسترسی غیرمجاز به گزارش‌ها فراتر از در نظر گرفته شده وجود دارد، نگران‌کننده می‌شود.

• مرورگرها و پروکسی های واسطه ممکن است درخواست های GET را ذخیره کنند.

• کاربران ممکن است چنین URL هایی حاوی اطلاعات حساس را نشانک کنند هنگامی که به اشتراک گذاری آنها به طور ناخواسته می تواند به طور بالقوه داده های حساس را افشا کند.

حال، بیایید ببینیم که همان درخواست با پارامترهای یکسان هنگام پردازش از طریق درخواست POST چگونه به نظر می رسد:

Request

POST /login.php HTTP/1.1
Host: www.redseclabs.com
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) 
AppleWebKit/537.36 (KHTML, like Gecko) Chrome/90.0.
4430.212 Safari/537.36
Content-Type: application/x-www-form-urlencoded
Content-Length: 34
Connection: close

username=myusername&password=mypassword

نام کاربری و رمز عبور بخشی از URL نیستند و بخشی از بدنه درخواست HTTP هستند و از این رو در برابر مسائل امنیتی فوق الذکر آسیب پذیر نیستند.
@TryHackBox

آسیب پذیری های رایج در هدرهای HTTP

بیایید در مورد برخی از آسیب پذیری های رایج که ممکن است از پیکربندی نادرست به وجود بیایند صحبت کنیم. ما در بخش‌های مربوط به آن‌ها در این کتاب به تفصیل به بررسی این آسیب‌پذیری‌ها خواهیم پرداخت.

جعل مبتنی بر عامل کاربر یا User-Agent-Based Spoofing
مقدار عامل کاربر را می توان دستکاری کرد و از این رو سرورها نمی توانند به آن اعتماد کنند. 
با این حال، بسیاری از مدیران تمایل دارند محدودیت نرخ و سایر مکانیسم‌های امنیتی را بر اساس عامل کاربر پیاده‌سازی کنند.

Host Header Injection
در صورتی که سرور هدر میزبان را تأیید نکند، ممکن است مهاجم یک مقدار میزبان مخرب را تزریق کند. این می تواند منجر به حملاتی مانند web cache poisoning، بازنشانی رمز عبور و هدایت کاربران به وب سایت های مخرب شود.

Cross-Domain Referer Leakage 

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

وب‌سایت‌ها می‌توانند «Referer-Policy» را یا به‌عنوان متا تگ یا به‌عنوان یک هدر HTTP برای نشان دادن زمان اضافه کردن هدر ارجاع‌دهنده هنگام پیمایش به وب‌سایت دیگری در نظر بگیرند. در اینجا برخی از تنظیمات وجود دارد:

no-referrer:
هرگز هدر Referer را ارسال نکنید.

same-origin:
هدر Referer را فقط برای درخواست‌های یکسان ارسال کنید.

strict-origin-when-cross-origin:
فقط مبدا را برای درخواست های متقاطع ارسال کنید.

@TryHackBox

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