Bugbountyhints – Telegram
The first bug is always special, but it's just the beginning of your journey.
bug bounty hunting is a journey, not a destination.
🎯 چرخه‌ی احساسی تغییر در مسیر شغلی باگ‌بانتی:
1. Uninformed Optimism – خوش‌بینی ناآگاهانه:

🔹 تازه با باگ‌بانتی آشنا شدی.
🔹 می‌گی: «فقط باید یه باگ پیدا کنم، ۵۰۰ دلار رو هواس!»
🔹 کلی انرژی داری و شروع می‌کنی به تست کردن سایت‌ها.
🔹 هنوز نمی‌دونی چقدر تلاش و دانش می‌خواد.

حس خیلی خفنی داری، با خودت می‌گی: «من می‌ترکونم!»

2. Informed Pessimism – بدبینی آگاهانه:

🔹 چند روز یا چند هفته گذشته، ده‌ها سایت رو چک کردی، هیچ باگی پیدا نکردی.
🔹 ریجکت شدی، نوت‌این‌اسکوپ دیدی، تکراری بوده.
🔹 داری با خودت می‌گی: «اصلاً انگار همه‌چی قبلاً پچ شده!»
🔹 کم‌کم شک می‌کنی که آیا این مسیر واقعاً جواب می‌ده یا نه.

انگیزه‌ت کم می‌شه، ولی هنوز کنار نکشیدی.

3. Valley of Despair – دره‌ی ناامیدی:

🔴 بدترین نقطه‌ست!
🔹 چند ماه گذشته، باگ درست‌حسابی پیدا نکردی.
🔹 حتی وقتی پیدا کردی، ردش کردن یا گفتن تکراریه.
🔹 حس می‌کنی این کار فقط وقت تلف کردنه.
🔹 خیلیا دقیقاً اینجا ول می‌کنن...

صدای ذهنی: «این همه وقت گذاشتم، تهش هیچی!»

4. Informed Optimism – خوش‌بینی آگاهانه:

🟢 حالا داری رشد می‌کنی!
🔹 داری متوجه می‌شی کجا باید تست کنی، چطوری باید ریپورت بنویسی.
🔹 اولین باگ واقعی‌تو قبول می‌کنن! یه جایزه می‌گیری یا یه هلکیشین خوشگل برات میاد 😍
🔹 انگیزه‌ت واقعی‌تر می‌شه، چون داری نتیجه‌ی تلاش واقعیت رو می‌بینی.

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

5. Success & Fulfillment – موفقیت و رضایت:

🌟 حالا چندتا ریپورت موفق داری، اسمت توی half of fame عه داری درآمد درمیاری.
🔹 حس فوق‌العاده‌ای داری چون از یه مسیر سخت رد شدی و نتیجه‌شو گرفتی.

دیگه کسی نمی‌تونه بهت بگه «نمیشه»... چون خودت کردی و دیدی میشه!
خود من هم توی valley of despair بودم و دوست داشتم اینو اینجا به اشتراک بزارم تا ببینید همه همچین تایمی رو دارن و یه چیز نرماله
از کتاب The 12 week year
‍‍‍‍```if you're trying to force yourself to do something you don't want to do, it's probably time to take a step back and at least try to frame it in a way which you can enjoy.```

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

https://snapdragon-copper-dd1.notion.site/Lets-learn-JS-1aca797be4c6801ebaa4caf932c3d0cd
یه سری روش که میتونید برای بایپس ratelimit یا 403 ها استفاده کنید :‌

1 - Change the request body (Form to JSON, XML or vice-versa).

2 - Change request methods (POST to PUT or GET).

3 - Change api version (Ex: api/v2/1729/confirm-email to api/v1/1729/confirm-email).

4 - Try changing the user-agent, the cookies... anything that could be able to identify you.

5 - check the response for a header and set that in request

6 - bypass ratelimiting with change the char of a captcha

7- Using Capital Letters or URL Case Changes --> Login --> login

8 - Protocol Downgrading (HTTP/1.1, HTTP/2)

9 - modifying the path --> /auth/..
اندپوینت ای که توش CORS Miss پیدا کردید رو به این سایت میدید و براتون poc رو میسازه :
https://vral-parmar.github.io/CORS-POC-Generator
عنوان آسیب‌پذیری: Improper Session Invalidation After Password Change

شرح آسیب پذیری:
این آسیب پذیری زمانی رخ میده که پس از تغییر Password توسط کاربر، Session های فعال قبلی او در دستگاه‌ها یا Browser های دیگه Expire یا Invalidate نمیشن.
مراحل تست (Proof of Concept):

با یک اکانت توی دو Browser مختلف (مثلاً Chrome و Firefox) به صورت همزمان لاگین کنید.
در یکی از Browser ها (مثلاً Chrome)، به بخش تنظیمات برید و Password اکانت رو تغییر بدید.
به Browser دوم (Firefox) که هنوز Session قدیمی اون فعاله، برگردید.
صفحه را Refresh کنید و سعی کنید یک کاری رو انجام بدید (مثلاً آپدیت کردن اطلاعات پروفایل).

نتیجه و Impact:

اگر Action در مرحله ۴ با موفقیت انجام بشه، آسیب‌پذیری تایید میشه.

این به این معناست که یک Attacker که به Session کاربر (مثلاً از طریق سرقت Cookie) دسترسی پیدا کرده، حتی پس از اینکه کاربر اصلی Password خود را تغییر می‌ده، همچنان دسترسی کامل به اکانت داره.

مشکل اصلی اینه که فرآیند تغییر Password، سایر Session Token های فعال کاربر رو در سمت سرور Invalidate نمیکنه.

Source : How-I-got-my-first-bug-bounty-50$
تو این نوشن تاپ ۱۰۰ هکروان با سوشال مدیا شون جمع شده که میتونید برید و دنبالشون کنید :‌
https://sordid-stranger-684.notion.site/NAME-1c8b600bd21c805a9659cdd33eed83d4
Refine your methodology, deepen your knowledge, learn to think like an attacker, and persist. Engage with the community, read write-ups, and never stop learning. By avoiding these common traps and adopting a structured, persistent approach, you'll soon shift the odds in your favour and start seeing those rewarding reports marked 'Triaged' and 'Bounty Awarded'. Happy hunting!
حتماً دیدی که یه هانتر با اضافه کردن .json به انتهای URL به یه چیز باحالی رسیده و یا بای پس کرده.
ولی چرا این کار جواب می‌ده؟

در Ruby on Rails، وقتی به /users/2.json درخواست میزنی، فریمورک از چیزی به اسم Content Negotiation استفاده می‌کنه تا جواب رو بر اساس پسوند بده. یعنی:

/users/2.json → خروجی JSON

/users/2.html → صفحه HTML

📌 بعضی وقتا /users/2 ارور میده یا محدودیت auth داره، ولی /users/2.json اطلاعات کامل میده! (حتی بدون لاگین)

این ترفند توی Ruby, Sinatra و حتی بعضی PHPها کاربرد داره و می‌تونه منجر به:

دور زدن محدودیت‌ها

دیدن خروجی API مخفی

کشف مسیرهای بیشتر

پس حتماً روی اکثر endpointها پسوندهایی مثل .json, .xml, .html, .js رو تست کن — شاید در جدیدی باز شد!
🧩 وقتی یه IDOR از طریق UUID پیدا کردیم چجوری UUID های کاربر های دیگه رو پیدا کنیم ؟‌

بعضی‌ها فکر می‌کنن UUID یعنی امنیت کامل! ولی نه همیشه...
1 - چک کن UUIDها واقعا رندوم باشن؛ گاهی Devها خودشون تولیدش می‌کنن و قابل حدس می‌شن!
2 - به جای UUID، مقادیر ساده مثل 0000-000... تست کن
3 - از آرشیو سایت (مثل Wayback Machine) و ابزار هایی که بهت URL میدن استفاده کن
4 - قسمت‌هایی مثل ریست‌پسورد، لاگین، کامنت‌ها و پروفایل‌ها رو بررسی کن
5 - گاهی توی فروم‌ها یا دیسکورد سایت، یوزرها خودشون UUID لو می‌دن!
6 - لاگ‌ها، سورس صفحه، ارورها رو بخون؛ گاهی لو می‌دن