خود من هم توی 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

یه سری روش که میتونید برای بایپس 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

A Hacker's Notebook: Real Techniques from the World of Bug Bounty

https://snapdragon-copper-dd1.notion.site/A-Hacker-s-Notebook-Real-Techniques-from-the-World-of-Bug-Bounty-20ea797be4c680e6b542c20a943782d6?pvs=73

By: @bugbountyhints
http://GitBook_s.t.me

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!

JS for XSS :

1 - part1
2 - part2
3 - part3

پیدا کردن endpoint از طریق js اضافه شد

A notion about Idor Cheat Sheet :
https://jasper-join-7e5.notion.site/IDOR-Cheat-Sheet-9f7c9e3285bf4c7cae5ea38243cd0391
یه نوشن در رابطه با Idor

حتماً دیدی که یه هانتر با اضافه کردن .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 - لاگ‌ها، سورس صفحه، ارورها رو بخون؛ گاهی لو می‌دن

چجوری میتونیم Idor رو اتومیت کنیم ؟‌

https://www.youtube.com/watch?v=3K1-a7dnA60

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

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

https://zhero-web-sec.github.io/writeups/
https://samcurry.net/
https://shubs.io/
https://dhiyaneshgeek.github.io/
https://bhavukjain.com/
https://rhynorater.github.io/
https://m0chan.github.io/
https://spaceraccoon.dev/
https://ott3rly.com/
https://www.jhaddix.com/blog
https://hackerrishad.me/

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