بیاید راجب وبش هم بگیم 🫠

توی وب خیلی خیلی خیلی جالب تره یعنی ممکنه شما ده بار همین آسیب رو پیدا کرده باشی ولی با تایتل اشتباه گزارش بدی😭😂

مثلا
دسته اول http header poisoning:
بیشتر تو هدر های
X-Forwarded-For
X-Forwarded-Host
Host
Useragent
هست حالا وقتی ما پارامتر های هدر رو دستکاری کنیم و مقدار خودمون رو بهش بدیم باعث بهم خوردن خروجی مطلوب بشیم.
مثلا آدرس ریست پسورد از host برداشته میشه و با تغییر مقدار این هدر به جای bad request مارو هدایت میکنه به لینک دلخواه خودمون و اینجا میشه open redirect و اگر بتونی ریست پسورد درست انجام بدی تبدیل میشه به ato خیلیییی تمیز☺️
این دسته از آسیب هارو خیلی جاها تریاژر محترم نوع لاجیکال میدونه :) پس حتما روشن کنید براشون که چه آسیبی زدید ...
حتی میتونید با WCD سیستم کش رو دور بزنید که اگر از پروفایل حالت استاتیک و پرایوت میسازه بتونید اونو پابلیک کنید👀

دسته دوم cookie poisoning:
که با دستکاری کوکی باعث دور زدن اعتبار سنجی ها میشیم که خیلییییییییییی ایمپکت بالایی میتونه داشته باشه توصیه میکنم بیشتر روش وقت بزارید 🥸

دسته سوم jwt poisoning:
اینم جالبه چون تقریبا همه موارد poisoning توی وب زیر مجموعه client-side trust به حساب میان :) اعتماد زیادی به ورودی کاربر
این آسیب زمانی که اعتبار سنجی درست روی توکن jwt انجام نشه مثلا alg قابل تغییر باشه و بدون امضا توکن قبول بشه! دیگه خودتون فکر کنید چه ایمپکت افتضاحی داره🙂‍↔️
یا حتی key confusion که مقدار rs256 توقع داره اما کلید پابلیک با توکن hmac می‌سازیم و بوم ... ato!

دسته چهارم local storage poisoning:
اگر وضعیت کاربر و یا نقش کاربر یا ... از لوکال بخونه فاجعه اس 🫠
میشه پرداخت بای پس کرد و آسیب های لاجیک اکثرا اینجا میخوره 👀
این زمان ها یه xss پیدا کنید و chain کنید و منو دعا کنید☺️

دسته پنجم cors poisoning:
ما میتونیم origin رو تو دامنه مورد نطر خودمون قرار بدیم وقتی تنظیماتش
Dynamic
Based on Origin
_white list

بجز موارد بالا حیلی دسته هست مثلا میشه js ها یا سایت ها یا script های وابسته به سایت رو با ورودی یا دیتای نا امن آلوده کرد و یا حتی سئو یه سایت
پس بجز کش و dns خیلی جاهای دیگه هم میتونیم poisoning داشته باشیم
اما ما اسمش رو نمیدونستیم 🤭

@Hackhive_channel 🐝

Hacksplaining.com/lessons/host-header-poisoning/

Memoryleaks.ir/host-header-poisoning-lead-to-account-takeover/

https://owasp.org/www-project-web-security-testing-guide/latest/4-Web_Application_Security_Testing/07-Input_Validation_Testing/17-Testing_for_Host_Header_Injection


یکی از بچه ها پرسید راجب host header poisoning اگر می‌خواستید بیشتر بدونید زیر مجموعه host header injection میتونید بیشتر راجبش پیدا کنید تو منابع☺️

شب یلداتون مبارک باشه 🫧
امیدوارم همیشه حال دلتون خوب باشه بچه ها❤️

🤖 Offensive-AI-Agent-Prompts :

یه ریپو که یاد میده چطور از هوش مصنوعی به‌ عنوان Agent امنیتی استفاده میشه ، نه فقط یه چت‌بات معمولی.
پرامپت‌ ها طوری طراحی شدن که با AI تست نفوذ، تحلیل آسیب‌پذیری و بررسی امنیتی چجور انجام میشه .

#Ai :
ChatGPT، Gemini-CLI، DeepSeek، Cursor AI، Claude Code و Copilot
-> Pentester، Bug Hunter , Blue Team , red team



https://github.com/CyberSecurityUP/Offensive-AI-Agent-Prompts

برای دریافت به‌روزرسانی‌های امنیتی روزانه، و اخبار امنیت سایبری مارو به عنوان منبع مورد نظر خود دنبال کنید ->❤️💻
GROUP ™️
@mandegar_sec | channel

سلام
چند وقت قبل تو گروه یه بحث شد که api testing یه نقطه پر اهمیت توی پنتست و باگ بانتی هست که اکثرا همه نادیده میگیرن یا چون زیاد روش کار نکردن رد میشن میرن!

اما اصلا چرا باید تست api و امنیت اون مهم باشه؟

اول از همه ببینیم api یا application programming interface چی هست؟

وقتی دو تا سیستم مختلف میخوان با هم ارتباط بگیرن (منظور از سیستم پلتفرم ها یا دیتابیس های مختلف هستش) میتونیم به جای اینکه دستور مستقیم برای برداشت اطلاعات از دیتابیس دیگه بزنیم از api ها برای ارتباط با پلتفرم دیگه استفاده کنیم☺️

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

کلا دو تا دسته api داریم یه سری پابلیک که دردسترس همه برای توسعه هست یه سری پرایوت یا خصوصی که برای داخل سازمان ها استفاده میشه.

اگر بخوایم انواع مدل هاشو برسی کنیم میتونیم بگیم api ها:

1.معمول ترینشون(REST):
مبتنی بر http کار میکنه و stateless هستش و فرمت داده ای json داره و طبیعتا برای عملیات هایی که real time هستن اصلا مناسب نیست! چون بعد از کانکشن ارتباط رو قطع میکنه و دیگه نگه نمیداره...

2.پیر ترین(SOAP):
اگر رو سامانه های فسیل کار کنید می‌بینیدش اسمش هم روشه simple object access protocol ! استاندارد پروتکلش w3c فرمتش هم فقط xml ولی میتونه توی http, smtp, tcp انتقال داده رو انجام بده. یه جورایی خیلی از نظر امنیتی قوی اما پیاده سازی غولی داره و اینکه نسبت به باقی فناوری ها یکم کمتر user friendly هستش... تقریبا هیچی!
بیشتر برای سیستم های enterprise خوبه و تراکنش های acid یا اتمی داره... دیگه بیشترش به ما مربوط نیست👀

3.پر استفاده ترین(GraphQL):
یعنی هرجا بچرخی مخصوصا تارگت ایرانی امکان نداره دو بار این بزرگوار رو ندیده باشی! مادرشون فیس بوک هستن و رو پروتکل http کار میکنه فقط هم دوتا متد داره get و post! مشکل هم داری میتونی بری سراغ باقی api ها ☺️
ولی یه مزیت که داره عین یه agent میمونه میتونی باهاش حرف بزنی!
همه کار هاشو با یه اندپوینت انجام میده و جاهای پیچیده خیلی خوب خروجی میده ولی پردازشش کمر سیستم رو میشکنه!

4.سریع ترین(gRPC):
از اسمش مشخصه مادرش گوگله دیگه؟ پروتکل هم که فقط http ورژن هم 2 اما این فرق داره دیگه باینری دیتا رو جا به جا میکنه و 4 تا مدل ارتباط برای خودش داره
Unary=simple request
Server streaming=1req/N response
Client streaming=N req/1 response
Bidirectional streaming=N req/N response

دیباگران سختی داره کامپایلر هم میخواد و از همه پیچیده تره اما خب ... سریعه!

5.پایدار ترین(websocket):
این بنده خدا هرچی بخوای بهت میده! پروتکل ws یا wss و ارتباط دو طرفه و پایدار داره و بدون درنگ ارتباط رو برقرار میکنه...
آره آره دقیقا توی مسینجر ها باید باشه😉
پس می‌فهمیم real time connection هدف اصلی این api اما مدل کارش با همه فرق داره 👀

بیاید تا کامل بگم چطوری ارتباط برقرار میکنه👾

@Hackhive_channel 🐝

قدیم قدیما ما یه چیزی داشتیم اسمش بود http polling که حالا میگم قدیم الان هم هستا!
ولی کارش چطوری بود؟
می‌پرسید داده ای که میفرستی جدیده؟ اگر هست اوکی میگیرم اگر نه دیگه لازم نیست یه داده تکراری رو دریافت کنم!

پس مجبور بودیم همش درخواست بفرستیم یه جورایی! اما اصلا چرا Websocket به دنیا اومدش؟
برای اینکه ارتباط اولیه با http و تحت پروتکل tcp بتونیم در لحظه و بدون درخواست های پشت هم ارتباط داشته باشم!

حالا چطوری ارتباط میگیره؟
یه مرحله داریم با عنوان handshake که یه هدر خاص داره یه کلید و ورژن وب سوکت رو با خودش حمل میکنه
سرور اگر موافق باشه یه جواب مثبت میفرسته اما اینو به این ترتیب میگیره که اول کلید کاربر رو میگیره و با یه کلید خودش که تصادفی ترکیب میکنه
مقدار هش رو محاسبه میکنه
کد گزاری میکنه
و به عنوان اکسپت وب سوکت ارسالش میکنه :)

داده ها هم به صورت باینری میفرسته
فریم هاش یه بخش های کلیدی داره
1.FIN= آخرین فریم یک پیام
2.Opcode= چهار بیت و نوع فریم هستش
0x1=text
0x2=binary
0x8=end connection
0x9=ping
0xA=pong
3.mask=یک بیت و همیشه از سمت کلاینت هست
4.payload length
5.masking key
6.payload data

اون ماسک کردن با xor برای محافظت در برابر cache poisoning که قبلا مفصل راجبش گفتیم

خب حالا اصلا همه اینا رو فهمیدی رمزنگاری رو فهمیدی همه چیز هم درست حق باشما!
هنوز نفهمیدیم امنیتش چرا مهمه؟

خب بیاید برسی کنیم چرا api به خطر میفته؟

@Hackhive_channel 🐝

خب بزار منطقی باشیم!
حدود 83 درصد از حجم ترافیک اینترنت از api میاد🫠
اما چرا هدف نیستن!؟
نه لاگ درست و درمون دارن
دسترسی خوبی هم به دیتاها دارن
سرعتشون عالیه
پس اینکه تست کنی ضرری نداره!
حالا چطوری باگ میخورن؟
مثلا احراز هویت درست انجام نمیشه
یا مثلا ورودی ها هیچ اعتبار سنجی نمیشه
بیشتر خطاهای لاجیکال میتونی اینجا پیدا کنی و همینطور بیشترین میس کانفیگ های ممکن!
حتی ممکنه توکن ها هم ایراد داشته باشن
اما یه موضوعی که ممکنه تو وب اپلیکیشن به این اندازه مهم نباشه rate limit هستش !
یه موضوع دیگه که به شدت دیده میشه داده های قدیمی روی api که از بین نمیره و میشه ازش استفاده کرد👀

اولین مرحله باید اندپوینت رو پیدا کنی
و پارامتر های مختلفش چک کنی
با منطقش آشنا بشی تا بتونی درست باهاش ارتباط بگیری...


منبع خوب اگر خواستید تا بیشتر یاد بگیرید:
https://youtube.com/playlist?list=PLdNiemjnPo8KeTZNlcZBFyeGu_BFuE2W4&si=OW8Kuk1fQTuWk_Pe
و چک لیست های مختلف مثلا
چک لیست برای گراف
چک لیست دیگه برای گراف
برای پنتست گراف
پنتست وب سوکت
چک لیست تست وب سوکت
پنتست رست
تست کیس های رست
برای پنتست رست
ابزار هایی که نیاز دارید

امیدوارم با این پست شما رو با api دوست کرده باشم🫧

@Hackhive_channel 🐝

https://blog.kulkan.com/a-hands-on-introduction-to-polyglot-files-699885a3e59f

یکی از مباحث مورد علاقه من که خیلی کمتر گفته میشه ولی میشه گفت این بلاگ خیلی قشنگ توضیح داده :)

https://github.com/wioui/n8n-CVE-2025-68613-exploit

https://github.com/Ashwesker/Blackash-CVE-2025-68613


تمام cve های این چند وقت کمر شکن بودن نمونه اش این یکی 👀
چرا اینطوری شده!

https://jira.mongodb.org/plugins/servlet/mobile#issue/SERVER-115508

MongoDB cve

یکی از تست کیس های باحال رو تارگت هایی که هر حرکتی میزنن یه آیدی ست میکنن اینه که علاوه بر idor یا ... بیاید race هم چک کنید!
ببینید یه ریکوئست رو چند بار قبول می‌کنه
اینم دقت کنید که ممکنه تارگت شما جواب ریکوئست رو 200 بده اما تو body یه مقدار ارور و یا ... یا جواب متفاوت از ریکوئست اول در نظر بگیره.

حالا ایمپکت این چیه اصلا!؟
شما فکر کن توی یه پنل مدیریت حساب یا کارت بانکی موقع ساخت این سکشن های مربوط به اطلاعات کارت بتونی از یک کارت چندین مورد ایجاد کنی
یا چندین بار یک فایل که قبلا حذف کردی رو دوباره حذف کنی بدون هیچ خطایی!
این مورد هزینه سنگین تر از مالی داره اونم پردازش های بیهوده ای که سیستم رو مشغول می‌کنه یا اختلال هایی که حتی باعث عدم انجام عملیات میشه و کل یه سامانه رو به مشکل میزنه حتی rate limit هم نداره که کنترل کنه!

حالا از اونجایی که راجب وب سوکت هم گفتیم فکر کنید بیایم اینا رو تو این مرحله ترکیب کنیم! چه مضحرفی میشه نه؟😂

این درصورتی که این عملیات که ما انجام میدیم باعث بشه یه event روی وب سوکت ارسال بشه و میتونیم تست کنیم
مثلا همزمان با حذف اون کارت یا object یه پیام برای ws بفرستیم مثلا state اونو رفرش کنیم حالا اگر ws state با دیتابیس ما سینک نباشه میشه
Cross channel race condition!

جالب بود :)
خلاصه پس ذهنتون باشه فقط idor و ... تست نکنید یکم خارج از چارچوب فکر کنید🫧

@Hackhive_channel 🐝

بازم سلام👀
چند وقت وقت مفصل راجب وب سوکت بهتون گفتم اما هیچی راجب آسیب پذیری هاش نگفتیم صرفا نحوه کارش بود تا اینکه با یه وب سوکت خیلی نچسب رو به رو شدم 🫠

حالا بیاید با هم بررسی کنیم بیشتر آسیب هایی که روی وب سوکت میخوره چیا هست؟ از کجا بفهمیم یه سامانه وب سوکت استفاده میکنه؟ چطوری باهاش برخورد کنیم؟

وب سوکت یا websocket برای ارتباط در لحظه اس مثلا مسینجر ها اما فقط توی ارتباط های در‌لحظه استفاده نمیشه!
میتونه حتی برای احراز هویت افراد یا انتقال دیتای اونا استفاده بشه👾
اما چطور بفهمیم سامانه داره از وب سوکت استفاده میکنه؟
وقتی داریم درخواست های از proxy خودمون رد میکنیم و یکی یکی ریکوئست هارو چک میکنیم یهو میبینی برای یه درخواست ساعت باید ۱۰ تا ریکوئست رد کنی! اون هیچی خب میگی یه وقتایی پیاده سازی ها به این شکل هستش اما میبینی توی هدر نوشته ws/ یا wss/ و اینجا جالب میشه:)

اینجا همون end point هست که ما میخوایم با وب سوکت ارتباط بگیریم و صداش کنیم تو این لحظه خودش چک لیست زیادی داره! مثلا حمله dos یا race condition خیلی رایجه تو وب سوکت و خیلی باحاله که ارسال درخواست بدون authentication توی وب سوکت خیلی مهمه چون اینجا با داده های حساسی سر و کار داری!

*اینو قبل از شروع برسی یکی از آسیب پذیری هاش بگم که کلی گشتم به نظرم بهتر از این مقاله برای توضیح آسیب های رایج وب سوکت پیدا نمیشه ... پست های دیگه اش هم حتما برسی کنید😉

آسیب پذیری مد نظر ما اسمش هست CSWSH! قبول دارم اسمش ترسناکه اما تستش خیلی راحته😅
وقتی درخواستی که ما میفرستیم پارامتر origin به درستی برسی نشه میتونیم مقدارش رو تغییر بدیم و بتونیم این درخواست رو از دامنه دیگه ای بزنیم اما خب چرا اصلا باید مهم باشه؟
بزار اسم کاملش رو بگم:
Cross-site websocket hijacking
فکر کنم راحت تر بفهمی دقیقا چرا مهمه! چون میتونه با ساختن یه فرم جعلی یا صفحه مشابه به ما کاربر رو فریب بده که درخواست بزنه با وب سوکت و ارتباط بگیره و تمام دیتایی که منتقل میشه برای ما قابل مشاهده باشه :)

پس ساده ترین کار ممکن وقتی یه وب سوکت دیدید اینه که با همون برپ خوشگلت تست کنی اتفاقا خیلی هم راحته!
کافیه بری بخش رپیتر بعد یه تب websocket باز کنید و یکی از درخواست های وب سوکت رو انتخاب کنیم حالا از هدر ها بخش origin رو خالی بزارید یا یه آدرس دیگه بهش‌ بدید🤷🏻‍♀️
وقتی مسیج رو send کنید و جواب بگیرید و بتونیم ارتباط بگیرید ... بهتره سریع گزارشش کنی☺️

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

@Hackhive_channel 🐝

یه چیزی قراره زیاد اذیتتون کنه مدام قطع و وصل شده کانکشن با وب سوکت هستش🤦🏻‍♀️
یعنی باعث میشه از زندگی سیر بشید پس هروقت حوصله داشتید برید پای این تست ها و اگر حوصله ندارید مدام دکمه reconnect توی برپ رو بزنید میتونیم از این سایت برای ارسال درخواست ها استفاده کنید که میتونیم توی تنظیمات درخواست بخش auto connect رو فعال کنید تا هربار وب سوکت رفت دوباره بهش ریکوئست بزنه و وصل بشید🙂‍↔️

@Hackhive_channel 🐝

پیکار Auroral رفت بالا، اگه تو امنیت «صفر مطلقین» کافیه پیکار رو باز کنین و مرحله به مرحله جلو برین و کلی چیز یاد بگیرین. محوریت پیکار کاملا آموزشیه و سعی کردیم مفاهیم امنیت رو به ساده‌ترین شکل ممکن طراحی کنیم:
Link:
https://auroral.liara.run/

LDAP Injection Leading to Internal User Impersonation and Authorization Bypass

Linkedin

⭐️ @RadvanSec

https://elliott.diy/blog/curseforge/

ارزش خوندن داره 👀

تو این ریسرچ برنا نعمت‌زاده به بررسی api tRPC پرداخته و تفاوت‌های کلیدی اون رو با متدهای رایجی مثل REST و GraphQL توضیح داده.

https://medium.com/@LogicalHunter/trpc-security-research-hunting-for-vulnerabilities-in-modern-apis-b0d38e06fa71