📚 کتابچه Kerberos For Pentesters
📌 یک راهنمای تخصصی برای شناخت Kerberos و نحوه استفاده از آن در تست نفوذ و Red Team محیط‌های Active Directory.
این کتاب از مبانی شروع میکند و تلاش میکند قبل از ورود به تکنیک‌های حمله، ساختار و منطق Kerberos را برای خواننده روشن کند. در ابتدا با تاریخچه و تکامل Kerberos، معماری Kerberos v5 و اجزای اصلی آن آشنا میشوید و سپس نحوه پیاده‌سازی این پروتکل در Active Directory بررسی میشود.
در بخش Active Directory، موضوعاتی مانند نقش Domain Controller به‌عنوان KDC، ارتباط Kerberos با حساب‌های کاربری و سرویس‌ها، TGT و Service Ticket و مکانیزم Pre-authentication مورد بررسی قرار می‌گیرند.
📌 توضیحات تکمیلی
📕 نمونه کتاب
📄 صفحات : ۱۷۷
💰 قیمت اصلی : ۲۶۹,۰۰۰ هزارتومان
🔥برای ۳ نفر اول : ۱۹۹,۰۰۰ هزارتومان
📌 جهت خرید به ایدی زیر پیام دهید:
@THBxSupport
@KavehOffSec
@TryHackBox
📌 یک راهنمای تخصصی برای شناخت Kerberos و نحوه استفاده از آن در تست نفوذ و Red Team محیط‌های Active Directory.
این کتاب از مبانی شروع میکند و تلاش میکند قبل از ورود به تکنیک‌های حمله، ساختار و منطق Kerberos را برای خواننده روشن کند. در ابتدا با تاریخچه و تکامل Kerberos، معماری Kerberos v5 و اجزای اصلی آن آشنا میشوید و سپس نحوه پیاده‌سازی این پروتکل در Active Directory بررسی میشود.
در بخش Active Directory، موضوعاتی مانند نقش Domain Controller به‌عنوان KDC، ارتباط Kerberos با حساب‌های کاربری و سرویس‌ها، TGT و Service Ticket و مکانیزم Pre-authentication مورد بررسی قرار می‌گیرند.
📌 توضیحات تکمیلی
📕 نمونه کتاب
📄 صفحات : ۱۷۷
💰 قیمت اصلی : ۲۶۹,۰۰۰ هزارتومان
🔥
📌 جهت خرید به ایدی زیر پیام دهید:
@THBxSupport
@KavehOffSec
@TryHackBox
❤1
Try Hack Box
🌐 Web Pentesting | Field Notes - #01 قبل از اینکه Payload بفرستی، اول ببین اصلاً کجا باید بفرستی. یکی از رایج ترین اشتباهات پنتسترهای تازه‌کار اینه که خیلی زود میپرن سراغ SQLi، XSS، یا اجرای یک Automated Scanner. اما یک پنتستر باتجربه، قبل از هر چیز، یک…
🌐 Web Pentesting | Field Notes - #02
SQL Injection را با SQLmap شروع نکنید
یکی از رایج ترین اشتباه‌ها در تست نفوذ وب این است که پنتستر به یک پارامتر میرسد و بلافاصله ابزار را اجرا می کند؛ منتظر میماند تا SQLmap اعلام کند «Vulnerable».
پیش از آنکه حتی یک ابزار را اجرا کنید، باید دقیقاً بدانید به دنبال چه چیزی هستید.
فرض کنید به این درخواست رسیده‌اید:
اول دست نزنید.
رفتار عادی برنامه را مشاهده کنید:
کد پاسخ چیست؟
طول پاسخ چقدر است؟
چه محتوایی برمی گردد؟
خطایی دیده می شود؟
آیا پاسخ تغییر می کند؟
تفاوتی در زمان پاسخ دهی وجود دارد؟
سپس ورودی را تغییر دهید و رفتار برنامه را با حالت عادی مقایسه کنید.
اگر با تغییر مقدار id، پاسخ به شکل قابل توجهی دگرگون شود، این دیگر یک تغییر ساده نیست؛ یک سیگنال است.
در این نقطه باید فرضیه بسازید:
«ممکن است این پارامتر در یک کوئری پایگاه‌داده استفاده شود.»
حالا تست واقعی آغاز میشود.
و اینجا یک نکتهٔ حیاتی وجود دارد:
اSQL Injection لزوماً قرار نیست خطای زیبا و واضحی روی صفحه نشان دهد.
در Blind SQL Injection ممکن است:
هیچ خطای پایگاه‌داده‌ای نبینید.
هیچ داده‌ای مستقیماً برنگردد.
و حتی پاسخ ظاهراً کاملاً عادی به نظر برسد.
اما اگر برنامه بین شرایط مختلف رفتار متفاوتی از خود نشان دهد، همین تفاوت می تواند سیگنال مهمی باشد.
پس وقتی خروجی واضحی ندارید، سؤال درست این نیست که:
«چه پیلود دیگری بزنم؟»
سؤال درست این است:
«چه چیزی را میتوانم اندازه‌گیری و مقایسه کنم؟»
پاسخ؟
رفتار بولین؟
طول پاسخ؟
زمان پاسخ‌دهی؟
محتوا؟
اینجاست که مرز میان یک جمع کنندهٔ پیلود و یک پنتستر وب واقعی مشخص میشود.
اSQLmap ابزار فوق‌العاده‌ای است.
اما قرار نیست به‌جای شما برنامه را بفهمد.
شما باید فرضیه بسازید؛ ابزار فقط باید فرآیند تحقیق را سریع‌تر کند.
اگر از ابتدا ابزار تصمیم بگیرد که به دنبال چه چیزی بگردد، ممکن است آسیب‌پذیری را پیدا کنید بدون آنکه واقعاً بفهمید چرا وجود دارد.
و این برای یک پنتستر حرفه‌ای کافی نیست.
@TryHackBox
#تست_نفوذ #امنیت_سایبری
SQL Injection را با SQLmap شروع نکنید
یکی از رایج ترین اشتباه‌ها در تست نفوذ وب این است که پنتستر به یک پارامتر میرسد و بلافاصله ابزار را اجرا می کند؛ منتظر میماند تا SQLmap اعلام کند «Vulnerable».
پیش از آنکه حتی یک ابزار را اجرا کنید، باید دقیقاً بدانید به دنبال چه چیزی هستید.
فرض کنید به این درخواست رسیده‌اید:
GET /products?id=42
اول دست نزنید.
رفتار عادی برنامه را مشاهده کنید:
کد پاسخ چیست؟
طول پاسخ چقدر است؟
چه محتوایی برمی گردد؟
خطایی دیده می شود؟
آیا پاسخ تغییر می کند؟
تفاوتی در زمان پاسخ دهی وجود دارد؟
سپس ورودی را تغییر دهید و رفتار برنامه را با حالت عادی مقایسه کنید.
اگر با تغییر مقدار id، پاسخ به شکل قابل توجهی دگرگون شود، این دیگر یک تغییر ساده نیست؛ یک سیگنال است.
در این نقطه باید فرضیه بسازید:
«ممکن است این پارامتر در یک کوئری پایگاه‌داده استفاده شود.»
حالا تست واقعی آغاز میشود.
و اینجا یک نکتهٔ حیاتی وجود دارد:
اSQL Injection لزوماً قرار نیست خطای زیبا و واضحی روی صفحه نشان دهد.
در Blind SQL Injection ممکن است:
هیچ خطای پایگاه‌داده‌ای نبینید.
هیچ داده‌ای مستقیماً برنگردد.
و حتی پاسخ ظاهراً کاملاً عادی به نظر برسد.
اما اگر برنامه بین شرایط مختلف رفتار متفاوتی از خود نشان دهد، همین تفاوت می تواند سیگنال مهمی باشد.
پس وقتی خروجی واضحی ندارید، سؤال درست این نیست که:
«چه پیلود دیگری بزنم؟»
سؤال درست این است:
«چه چیزی را میتوانم اندازه‌گیری و مقایسه کنم؟»
پاسخ؟
رفتار بولین؟
طول پاسخ؟
زمان پاسخ‌دهی؟
محتوا؟
اینجاست که مرز میان یک جمع کنندهٔ پیلود و یک پنتستر وب واقعی مشخص میشود.
اSQLmap ابزار فوق‌العاده‌ای است.
اما قرار نیست به‌جای شما برنامه را بفهمد.
شما باید فرضیه بسازید؛ ابزار فقط باید فرآیند تحقیق را سریع‌تر کند.
اگر از ابتدا ابزار تصمیم بگیرد که به دنبال چه چیزی بگردد، ممکن است آسیب‌پذیری را پیدا کنید بدون آنکه واقعاً بفهمید چرا وجود دارد.
و این برای یک پنتستر حرفه‌ای کافی نیست.
@TryHackBox
#تست_نفوذ #امنیت_سایبری
👍5❤2
⭕ یک خط برای پیدا کردن فایل ها
@TryHackBox
#باگ_بانتی
subfinder -d domain.com -silent | \
while read host; do \
for path in /config.js /config.json /app/config.js /settings.json /database.json /firebase.json /.env /.env.production /api_keys.json /credentials.json /secrets.json /google-services.json /package.json /package-lock.json /composer.json /pom.xml /docker-compose.yml /manifest.json /service-worker.js; do \
echo "$host$path"; \
done; \
done | httpx -mc 200
@TryHackBox
#باگ_بانتی
❤8👎1
📌 استفاده از ماشین‌های مجازی برای بایپس کردن ابزارهای امنیتی
📌 مهاجمان همچنان به آزمایش با پلتفرم های مختلف مدیریت از راه دور
📌 مینی دوره #رایگان نصب و راه‌اندازی لابراتورهای تست نفوذ وب قسمت اول
📌 فکر می‌کنید، xss نمی تواند در اندپوینت .html فعال شود؟
📌 کجا می توان به صورت قانونی LLM را هک کرد؟
📌 درک معماری های سندباکس
📌 بررسی تهدیدها : OWASP Top 10 برای LLM
📌 بازنشانی رمز عبور منقضی شده حساب دامنه از طریق null-session و SAMR
📌 جستجو برای فایل‌های رمزگذاری شده
📌 نشت اطلاعات حساس و عدم وجود مجوز از طریق اندپوینت API
📌 دستورات کاربردی و سریع برای Host & Network Discovery و Service Enumeration و Web Enumeration
📌 بایپس احراز هویت از طریق Forged Session Cookie
📌 هک سیستم های SCADA : پیداکردن سیستم های SCADA با استفاده از Censys
ا📌 AMSI Bypass و چالش‌های اجرای PowerShell در محیط‌های ویندوزی
📌 نکته‌ای برای باگ بانتی: بایپس احراز هویت
📌 دورک های مفید برای باگ هانترها
📌 جمع آوری اطلاعات سریع تر
📌 100 آسیب پذیری وب
📌 یه Google Dork ساده، ولی با ...
📌 شروع دوره #رایگان Network+
📌 مهاجمان همچنان به آزمایش با پلتفرم های مختلف مدیریت از راه دور
📌 مینی دوره #رایگان نصب و راه‌اندازی لابراتورهای تست نفوذ وب قسمت اول
📌 فکر می‌کنید، xss نمی تواند در اندپوینت .html فعال شود؟
📌 کجا می توان به صورت قانونی LLM را هک کرد؟
📌 درک معماری های سندباکس
📌 بررسی تهدیدها : OWASP Top 10 برای LLM
📌 بازنشانی رمز عبور منقضی شده حساب دامنه از طریق null-session و SAMR
📌 جستجو برای فایل‌های رمزگذاری شده
📌 نشت اطلاعات حساس و عدم وجود مجوز از طریق اندپوینت API
📌 دستورات کاربردی و سریع برای Host & Network Discovery و Service Enumeration و Web Enumeration
📌 بایپس احراز هویت از طریق Forged Session Cookie
📌 هک سیستم های SCADA : پیداکردن سیستم های SCADA با استفاده از Censys
ا📌 AMSI Bypass و چالش‌های اجرای PowerShell در محیط‌های ویندوزی
📌 نکته‌ای برای باگ بانتی: بایپس احراز هویت
📌 دورک های مفید برای باگ هانترها
📌 جمع آوری اطلاعات سریع تر
📌 100 آسیب پذیری وب
📌 یه Google Dork ساده، ولی با ...
📌 شروع دوره #رایگان Network+
🔥 #باگ_بانتی فکر کنم این یکی برای بیشتر باگ هانترها آشنا باشه
چند ساعت روی یه مورد وقت میذاری، مطمئنی یه آسیب پذیری پیدا کردی، حتی سناریوی Exploit رو هم تو ذهنت کامل کردی بعد آخرش میفهمی یا Out of Scope بوده، یا اصلاً آسیب پذیری محسوب نمیشده.
برای خیلیا False Positive بیشتر از چیزی که انتظار داشتن اتفاق افتاده.
برای شما چطور؟ بیشتر با Duplicate مواجه میشید، Out of Scope، False Positive یا باگی که در نهایت Impact قابل توجهی نداره؟
لینک گروه جهت مشارکت :
https://t.me/+XPV3S0tygl1lZGE0
TryHackBox | Ai Sec | Radio | RoadMap
چند ساعت روی یه مورد وقت میذاری، مطمئنی یه آسیب پذیری پیدا کردی، حتی سناریوی Exploit رو هم تو ذهنت کامل کردی بعد آخرش میفهمی یا Out of Scope بوده، یا اصلاً آسیب پذیری محسوب نمیشده.
برای خیلیا False Positive بیشتر از چیزی که انتظار داشتن اتفاق افتاده.
برای شما چطور؟ بیشتر با Duplicate مواجه میشید، Out of Scope، False Positive یا باگی که در نهایت Impact قابل توجهی نداره؟
اگه تجربه جالبی داشتید، بدون اشاره به اسم تارگت برامون بنویسید.
لینک گروه جهت مشارکت :
https://t.me/+XPV3S0tygl1lZGE0
TryHackBox | Ai Sec | Radio | RoadMap
🔥5
ا📌 Source Code رو از نگاه یک Pentester چطور بررسی کنیم؟
وقتی توی تست نفوذ به Repository دسترسی داری، قرار نیست فقط بشینی کد رو خط به خط بخونی.
چیزی که برای من مهم تره اینه که بفهمم کجاهایی از Attack Surface از بیرون دیده نمیشن.
مثلاً یک Endpoint که از بیرون پیدا نکردیم، یک Background Job، یک File Handler یا جایی که Authorization فقط توی بعضی مسیرها انجام شده.
معمولاً کار رو اینطوری جلو میبرم:
اول یک SAST نسبتاً گسترده اجرا میکنم و چیزهایی مثل Dependencyها، Generated Code و Testها رو تا حد ممکن از نتایج کنار میذارم.
بعد دیگه قرار نیست تک‌تک Alertها رو باور کنیم.
برای هر مورد باید برگردیم به Code و مسیر رو دنبال کنیم:
مثلاً اگر یک Input کاربر به یک SQL Query میرسه، باید ببینیم واقعاً همین مسیر در Application قابل دسترسیه؟ داده Sanitize یا Parameterize شده؟ و در نهایت واقعاً چه اثری برای مهاجم داره؟
همین موضوع برای File Operation، Deserialization، Secrets، Access Control و Business Logic هم صدق میکنه.
یکی از اشتباهات رایج اینه که:
نه.
ممکنه کد مربوط به Test باشه، مسیر اصلاً Reachable نباشه یا قبل از رسیدن به Sink یک Security Control درست وجود داشته باشه.
برای همین Finding خوب باید یک Chain قابل اثبات داشته باشه.
از کجا شروع شد؟
کجا رفت؟
کجا به نقطه خطرناک رسید؟
مهاجم دقیقاً چه کاری میتونه انجام بده؟
و مهم تر از همه چی باید Fix بشه؟
به‌نظرم ارزش Code Analysis این نیست که ۲۰۰ تا Alert تحویل بدیم.
ارزشش اینه که از بین اون ۲۰۰ مورد، چند Finding واقعی و قابل اثبات پیدا کنیم.
@TryHackBox
@TryHackBoxOfficial
@AiTHB
@RadioZeroPod
وقتی توی تست نفوذ به Repository دسترسی داری، قرار نیست فقط بشینی کد رو خط به خط بخونی.
چیزی که برای من مهم تره اینه که بفهمم کجاهایی از Attack Surface از بیرون دیده نمیشن.
مثلاً یک Endpoint که از بیرون پیدا نکردیم، یک Background Job، یک File Handler یا جایی که Authorization فقط توی بعضی مسیرها انجام شده.
معمولاً کار رو اینطوری جلو میبرم:
اول یک SAST نسبتاً گسترده اجرا میکنم و چیزهایی مثل Dependencyها، Generated Code و Testها رو تا حد ممکن از نتایج کنار میذارم.
بعد دیگه قرار نیست تک‌تک Alertها رو باور کنیم.
برای هر مورد باید برگردیم به Code و مسیر رو دنبال کنیم:
Entry Point → Data Flow → Validation → Dangerous Sink
مثلاً اگر یک Input کاربر به یک SQL Query میرسه، باید ببینیم واقعاً همین مسیر در Application قابل دسترسیه؟ داده Sanitize یا Parameterize شده؟ و در نهایت واقعاً چه اثری برای مهاجم داره؟
همین موضوع برای File Operation، Deserialization، Secrets، Access Control و Business Logic هم صدق میکنه.
یکی از اشتباهات رایج اینه که:
SAST Alert = Vulnerability
نه.
ممکنه کد مربوط به Test باشه، مسیر اصلاً Reachable نباشه یا قبل از رسیدن به Sink یک Security Control درست وجود داشته باشه.
برای همین Finding خوب باید یک Chain قابل اثبات داشته باشه.
از کجا شروع شد؟
کجا رفت؟
کجا به نقطه خطرناک رسید؟
مهاجم دقیقاً چه کاری میتونه انجام بده؟
و مهم تر از همه چی باید Fix بشه؟
به‌نظرم ارزش Code Analysis این نیست که ۲۰۰ تا Alert تحویل بدیم.
ارزشش اینه که از بین اون ۲۰۰ مورد، چند Finding واقعی و قابل اثبات پیدا کنیم.
@TryHackBox
@TryHackBoxOfficial
@AiTHB
@RadioZeroPod
👍7❤1
thb-ctf-01-broken-trust.zip
14.4 KB
THB CTF Team Qualification : Challenge #01
The Broken Trust
دسته: Web Pentesting
سطح سختی: Hard
پروژه: TCTQ : مسیر پذیرش تیم CTF TryHackBox
📖 سناریو
شرکت خیالی Trustonic Corp یه پورتال داخلی کارمندی جدید راه‌اندازی کرده. HR، دایرکتوری بخشها، تنظیمات حساب کاربری همه پشت یه صفحه لاگین قرار گرفته و تیم فنی‌شون مطمئنه که آماده‌ی audit هست.
شما به عنوان یه پنتستر خارجی استخدام شدید. کارتون رو با هیچی شروع کنید فقط یه فرم ثبت‌نام ساده و ببینید یه اکانت کارمند عادی تا کجا میتونه شما رو پیش ببره.
🎯 هدف: رسیدن به پنل Administrator و گرفتن Flag.
⚙️ نحوه اجرا
سرویس روی آدرس زیر بالا میاد:
یه اکانت برای خودتون بسازید نیازی به حدس زدن یا brute-force کردن اکانت های موجود نیست.
فرمت فلگ :
THB{ }
ارسال فلگ :
@Unique_exploitbot
قوانین و توضیحات تکمیلی
@TryHackBox
#CTF_THB
The Broken Trust
دسته: Web Pentesting
سطح سختی: Hard
پروژه: TCTQ : مسیر پذیرش تیم CTF TryHackBox
📖 سناریو
شرکت خیالی Trustonic Corp یه پورتال داخلی کارمندی جدید راه‌اندازی کرده. HR، دایرکتوری بخشها، تنظیمات حساب کاربری همه پشت یه صفحه لاگین قرار گرفته و تیم فنی‌شون مطمئنه که آماده‌ی audit هست.
شما به عنوان یه پنتستر خارجی استخدام شدید. کارتون رو با هیچی شروع کنید فقط یه فرم ثبت‌نام ساده و ببینید یه اکانت کارمند عادی تا کجا میتونه شما رو پیش ببره.
🎯 هدف: رسیدن به پنل Administrator و گرفتن Flag.
⚙️ نحوه اجرا
docker compose up --build
سرویس روی آدرس زیر بالا میاد:
http://localhost:8001
یه اکانت برای خودتون بسازید نیازی به حدس زدن یا brute-force کردن اکانت های موجود نیست.
فرمت فلگ :
THB{ }
ارسال فلگ :
@Unique_exploitbot
قوانین و توضیحات تکمیلی
@TryHackBox
#CTF_THB
This media is not supported in your browser
VIEW IN TELEGRAM
حل چلنچ : The Broken Trust : THB CTF
سناریوی حل چالش توسط اقا آرمین عزیز از اعضای کانال .
@TryHackBox
#CTF_THB
سناریوی حل چالش توسط اقا آرمین عزیز از اعضای کانال .
@TryHackBox
#CTF_THB
❤3
thb-ctf-02-trustpay-player.zip
28.3 KB
🔐 THB CTF Team Qualification : Challenge #02 - Race Against Trust
دسته: Web Pentesting / Business Logic
سطح سختی: Hard
پروژه: TCTQ مسیر پذیرش تیم CTF TryHackBox
📖 سناریو
اTrustPay یه پلتفرم پرداخت داخلیه که تو کل شرکت برای صدور Invoice و انتقال وجه بین بخشها استفاده میشه. کارمندها میتونن Invoiceهاشون رو ببینن، مرجع صورت‌حساب رو جستجو کنن، و موجودی حسابشون رو پیگیری کنن.
شما به‌عنوان یه پنتستر خارجی استخدام شدید. یه اکانت کارمند عادی بسازید و ببینید یه کاربر معمولی تا کجا میتونه پیش بره.
🎯 هدف: دسترسی به پنل Treasury و گرفتن Flag.
هیچ آسیب‌پذیری به تنهایی شما رو به هدف نمیرسونه. این چالش نیاز به زنجیره‌کردن چند تا ضعف داره، فهمیدن اینکه چرا هر مرحله به‌تنهایی کافی نیست.
⚙️ نحوه اجرا
یا
اپلیکیشن روی آدرس زیر بالا میاد:
فرمت فلگ :
THB{ }
ارسال فلگ :
@Unique_exploitbot
قوانین و توضیحات تکمیلی
@TryHackBox
#CTF_THB
دسته: Web Pentesting / Business Logic
سطح سختی: Hard
پروژه: TCTQ مسیر پذیرش تیم CTF TryHackBox
📖 سناریو
اTrustPay یه پلتفرم پرداخت داخلیه که تو کل شرکت برای صدور Invoice و انتقال وجه بین بخشها استفاده میشه. کارمندها میتونن Invoiceهاشون رو ببینن، مرجع صورت‌حساب رو جستجو کنن، و موجودی حسابشون رو پیگیری کنن.
شما به‌عنوان یه پنتستر خارجی استخدام شدید. یه اکانت کارمند عادی بسازید و ببینید یه کاربر معمولی تا کجا میتونه پیش بره.
🎯 هدف: دسترسی به پنل Treasury و گرفتن Flag.
هیچ آسیب‌پذیری به تنهایی شما رو به هدف نمیرسونه. این چالش نیاز به زنجیره‌کردن چند تا ضعف داره، فهمیدن اینکه چرا هر مرحله به‌تنهایی کافی نیست.
⚙️ نحوه اجرا
docker compose up --build
یا
./start.sh
اپلیکیشن روی آدرس زیر بالا میاد:
http://localhost:8002
فرمت فلگ :
THB{ }
ارسال فلگ :
@Unique_exploitbot
قوانین و توضیحات تکمیلی
@TryHackBox
#CTF_THB
👍3
Try Hack Box
🌐 Web Pentesting | Field Notes - #02 SQL Injection را با SQLmap شروع نکنید یکی از رایج ترین اشتباه‌ها در تست نفوذ وب این است که پنتستر به یک پارامتر میرسد و بلافاصله ابزار را اجرا می کند؛ منتظر میماند تا SQLmap اعلام کند «Vulnerable». پیش از آنکه حتی…
🧨 WEB PENTESTING FIELD NOTES #03
یک اشتباه رایج در تست XSS
یه چیزی توی Search Box وارد میکنی.
بر میگرده توی صفحه.
بعد اولین فکری که میاد:
«خب، حالا یه Payload بزنیم ببینیم اجرا میشه یا نه.»
اینجا دقیقاً جاییه که خیلی از تست ها اشتباه شروع میشن.
قبل از Payload، من معمولاً یه سؤال ساده‌تر می‌پرسم:
این Input دقیقاً کجا قرار گرفته؟
داخل HTML؟
داخل یک Attribute؟
داخل JavaScript؟
توی URL؟
یا اصلاً JavaScript سمت Client داره این مقدار رو از جایی میخونه و وارد DOM میکنه؟
چون این:
<input>
به تنهایی چیزی بهت نمیگه.
مهم اینه که Application و Browser باهاش چه رفتاری میکنن.
یه سناریوی ساده:
تو Search میزنی:
THB
صفحه هم نشون میده:
Search results for: THB
خوبه.
حالا به جای اینکه سریع بری سراغ Payloadهای مختلف، مسیر مقدار رو دنبال کن.
Input → Source → Data Flow → Sink → Context → Execution
اگر بفهمی داده از کجا وارد شده و نهایتاً به کجا رسیده، تازه می فهمی باید دنبال چه چیزی بگردی.
حالا سه حالت اصلی XSS رو از هم جدا کن:
🔹 Reflected XSS
اInput از Request میاد و در Response برمیگرده.
🔹 Stored XSS
اInput ذخیره میشه و بعداً وقتی یک User دیگه صفحه رو می‌بینه، Render میشه.
🔹 DOM-Based XSS
این یکی جالب تره.
ممکنه Server اصلاً چیزی از Payload نبینه.
جاوااسکریپت سمت Client داده رو از یک Source میگیره و به یک Sink خطرناک میرسونه.
یعنی اگر فقط Responseهای Server رو نگاه کنی، ممکنه کل داستان رو از دست بدی.
حالا یه سؤال برای خودت:
فرض کن مقدار زیر رو وارد کردی:
THB123
و این مقدار داخل HTML صفحه ظاهر شد.
آیا همین به معنی XSS Vulnerability هست؟
@TryHackBox
#تست_نفوذ #امنیت_سایبری
یک اشتباه رایج در تست XSS
یه چیزی توی Search Box وارد میکنی.
بر میگرده توی صفحه.
بعد اولین فکری که میاد:
«خب، حالا یه Payload بزنیم ببینیم اجرا میشه یا نه.»
اینجا دقیقاً جاییه که خیلی از تست ها اشتباه شروع میشن.
قبل از Payload، من معمولاً یه سؤال ساده‌تر می‌پرسم:
این Input دقیقاً کجا قرار گرفته؟
داخل HTML؟
داخل یک Attribute؟
داخل JavaScript؟
توی URL؟
یا اصلاً JavaScript سمت Client داره این مقدار رو از جایی میخونه و وارد DOM میکنه؟
چون این:
<input>
به تنهایی چیزی بهت نمیگه.
مهم اینه که Application و Browser باهاش چه رفتاری میکنن.
یه سناریوی ساده:
تو Search میزنی:
THB
صفحه هم نشون میده:
Search results for: THB
خوبه.
حالا به جای اینکه سریع بری سراغ Payloadهای مختلف، مسیر مقدار رو دنبال کن.
Input → Source → Data Flow → Sink → Context → Execution
اگر بفهمی داده از کجا وارد شده و نهایتاً به کجا رسیده، تازه می فهمی باید دنبال چه چیزی بگردی.
حالا سه حالت اصلی XSS رو از هم جدا کن:
🔹 Reflected XSS
اInput از Request میاد و در Response برمیگرده.
🔹 Stored XSS
اInput ذخیره میشه و بعداً وقتی یک User دیگه صفحه رو می‌بینه، Render میشه.
🔹 DOM-Based XSS
این یکی جالب تره.
ممکنه Server اصلاً چیزی از Payload نبینه.
جاوااسکریپت سمت Client داده رو از یک Source میگیره و به یک Sink خطرناک میرسونه.
یعنی اگر فقط Responseهای Server رو نگاه کنی، ممکنه کل داستان رو از دست بدی.
حالا یه سؤال برای خودت:
فرض کن مقدار زیر رو وارد کردی:
THB123
و این مقدار داخل HTML صفحه ظاهر شد.
آیا همین به معنی XSS Vulnerability هست؟
اگر جوابت «بله» یا «نه» هست، دلیلش رو هم بنویس.
ببینیم چند نفر واقعاً Context رو بررسی میکنن، نه فقط دنبال Payload می گردن.
@TryHackBox
#تست_نفوذ #امنیت_سایبری
❤7
🧩 WINDOWS INTERNALS FIELD NOTES #01
اException Handling فقط برای Crash کردن برنامه نیست
وقتی یک برنامه در Windows با یک Exception مواجه می شود، اولین چیزی که معمولاً به ذهنمان میرسد این است:
«خب، برنامه خطا داد.»
اما از دید یک Reverse Engineer، سؤال مهم‌تر این است:
بعد از رخ دادن Exception، چه چیزی تصمیم میگیرد Execution کجا ادامه پیدا کند؟
اینجا Exception Handling وارد ماجرا میشود.
فرض کن برنامه این دستور را اجرا میکند:
int *ptr = NULL; *ptr = 1337;
طبیعتاً CPU نمی‌تواند این Memory Access را انجام دهد و یک Exception ایجاد میشود.
اما داستان همان‌جا تمام نمیشود.
اWindows Exception را دریافت میکند و وارد یک مسیر مشخص برای پیدا کردن Handler مناسب میشود.
به زبان ساده:
و همین مسیر ساده، یک نکته مهم دارد:
اException می‌تواند روی مسیر اجرای برنامه تأثیر بگذارد.
First-Chance و Second-Chance Exception
در Debugging با این دو مفهوم زیاد برخورد می‌کنید.
First-Chance Exception
اولین مرحله‌ای است که Exception به Debugger و سپس مکانیزم Exception Handling ارائه میشود.
اگر برنامه Handler مناسبی داشته باشد، ممکن است Exception مدیریت شود و Execution ادامه پیدا کند.
اگر نه، Exception دوباره در مسیر Handling بررسی میشود.
در نهایت اگر هیچ Handler مناسبی پیدا نشود:
Second-Chance Exception
یعنی دیگر جایی برای Handle کردن Exception باقی نمانده و معمولاً Process به پایان میرسد.
برای همین وقتی در x64dbg یا WinDbg با Exception مواجه میشوید، نباید فوراً فرض کنید:
«برنامه Crash کرد.»
باید بپرسید:
این Exception چرا ایجاد شد؟
چه کسی آن را Handle میکند؟
و Execution بعد از آن کجا ادامه پیدا میکند؟
اینجا موضوع برای Security جالب میشود
یک Exception Handler می‌تواند صرفاً برای مدیریت خطا استفاده شود.
اما اگر کسی عمداً Exception ایجاد کند و از Handler برای تغییر مسیر Execution استفاده کند چه؟
آن وقت Exception Handling دیگر فقط یک مکانیزم Error Handling نیست.
می‌تواند تبدیل شود به یک Control-Flow Primitive.
در Malware و بعضی تکنیک های Anti-Analysis، این رفتار می‌تواند برای سخت‌تر کردن تحلیل برنامه استفاده شود.
اAnalyst ممکن است یک مسیر Execution را دنبال کند، اما بخشی از Control Flow از طریق Exception اتفاق بیفتد.
و این دقیقاً جایی است که باید نگاه Reverse Engineer از «چه خطایی رخ داده؟» به «این Exception چه نقشی در Control Flow دارد؟» تغییر کند.
🎯 چیزی که باید از این قسمت یاد بگیری
هر Exception را Crash در نظر نگیر.
وقتی در یک Binary رفتار غیرعادی دیدی، این چند سؤال را از خودت بپرس:
اException از کجا Trigger شد؟
اException Code چیست؟
چه Handlerای آن را دریافت میکند؟
اHandler چه تغییری در Execution ایجاد میکند؟
آیا Instruction Pointer بعد از Handler تغییر میکند؟
آیا Exception بخشی از Logic برنامه است یا صرفاً Error Handling؟
@TryHackBox
#WindowsInternals #ReverseEngineering #MalwareAnalysis #x64dbg #CyberSecurity
اException Handling فقط برای Crash کردن برنامه نیست
وقتی یک برنامه در Windows با یک Exception مواجه می شود، اولین چیزی که معمولاً به ذهنمان میرسد این است:
«خب، برنامه خطا داد.»
اما از دید یک Reverse Engineer، سؤال مهم‌تر این است:
بعد از رخ دادن Exception، چه چیزی تصمیم میگیرد Execution کجا ادامه پیدا کند؟
اینجا Exception Handling وارد ماجرا میشود.
فرض کن برنامه این دستور را اجرا میکند:
int *ptr = NULL; *ptr = 1337;
طبیعتاً CPU نمی‌تواند این Memory Access را انجام دهد و یک Exception ایجاد میشود.
اما داستان همان‌جا تمام نمیشود.
اWindows Exception را دریافت میکند و وارد یک مسیر مشخص برای پیدا کردن Handler مناسب میشود.
به زبان ساده:
Instruction
↓
Exception
↓
Windows Exception Dispatcher
↓
Exception Handler
↓
Handle / Continue / Terminate
و همین مسیر ساده، یک نکته مهم دارد:
اException می‌تواند روی مسیر اجرای برنامه تأثیر بگذارد.
First-Chance و Second-Chance Exception
در Debugging با این دو مفهوم زیاد برخورد می‌کنید.
First-Chance Exception
اولین مرحله‌ای است که Exception به Debugger و سپس مکانیزم Exception Handling ارائه میشود.
اگر برنامه Handler مناسبی داشته باشد، ممکن است Exception مدیریت شود و Execution ادامه پیدا کند.
اگر نه، Exception دوباره در مسیر Handling بررسی میشود.
در نهایت اگر هیچ Handler مناسبی پیدا نشود:
Second-Chance Exception
یعنی دیگر جایی برای Handle کردن Exception باقی نمانده و معمولاً Process به پایان میرسد.
برای همین وقتی در x64dbg یا WinDbg با Exception مواجه میشوید، نباید فوراً فرض کنید:
«برنامه Crash کرد.»
باید بپرسید:
این Exception چرا ایجاد شد؟
چه کسی آن را Handle میکند؟
و Execution بعد از آن کجا ادامه پیدا میکند؟
اینجا موضوع برای Security جالب میشود
یک Exception Handler می‌تواند صرفاً برای مدیریت خطا استفاده شود.
اما اگر کسی عمداً Exception ایجاد کند و از Handler برای تغییر مسیر Execution استفاده کند چه؟
آن وقت Exception Handling دیگر فقط یک مکانیزم Error Handling نیست.
می‌تواند تبدیل شود به یک Control-Flow Primitive.
در Malware و بعضی تکنیک های Anti-Analysis، این رفتار می‌تواند برای سخت‌تر کردن تحلیل برنامه استفاده شود.
اAnalyst ممکن است یک مسیر Execution را دنبال کند، اما بخشی از Control Flow از طریق Exception اتفاق بیفتد.
Normal Flow
↓
Instruction
↓
Exception
↓
Handler
↓
Modified Context
↓
Different Execution Flow
و این دقیقاً جایی است که باید نگاه Reverse Engineer از «چه خطایی رخ داده؟» به «این Exception چه نقشی در Control Flow دارد؟» تغییر کند.
🎯 چیزی که باید از این قسمت یاد بگیری
هر Exception را Crash در نظر نگیر.
وقتی در یک Binary رفتار غیرعادی دیدی، این چند سؤال را از خودت بپرس:
اException از کجا Trigger شد؟
اException Code چیست؟
چه Handlerای آن را دریافت میکند؟
اHandler چه تغییری در Execution ایجاد میکند؟
آیا Instruction Pointer بعد از Handler تغییر میکند؟
آیا Exception بخشی از Logic برنامه است یا صرفاً Error Handling؟
@TryHackBox
#WindowsInternals #ReverseEngineering #MalwareAnalysis #x64dbg #CyberSecurity
👍4❤1
Media is too big
VIEW IN TELEGRAM
📌 معرفی دوره :
THB-WP101 : Web Penetration Testing Fundamentals
ورود به Web Penetration Testing با حفظ کردن چند Vulnerability شروع نمی شود.
اگر قرار است یک Web Pentester باشید، باید بتوانید یک Web Application را بشناسید، Attack Surface آن را پیدا کنید، نقاط ورودی را بررسی کنید، رفتار Authentication و Access Control را تحلیل کنید، Vulnerabilityها را تست و Validate کنید و در نهایت Impact و مسیر حمله را مستند کنید.
دوره ما برای ساختن همین مهارت‌ها طراحی شده است.
⏳زمان یادگیری: حدود 40-50 ساعت
🛠 80 الی 90 درصد Practical
📌 کلاس : آنلاین
💠 مشاهده سرفصل ها
💢 ثبت نام اولیه شروع شد
⭕ تاریخ شروع کلاس : ۱۴۰۵/۰۶/۲۲
👤 مدرس : مهندس محمد طاهری
💠 لینکدین مدرس
📌 توضیحات تکمیلی
💰ارزش اصلی دوره: ۵،۹۰۰،۰۰۰ تومان
💰قیمت استاندارد : ۳,۹۸۹,۰۰۰ تومان
🔥 تخفیف ویژه برای ۵ نفر اول : ۲,۸۹۹,۰۰۰ تومان
این قیمت برای ثبت‌نام اولیه در نظر گرفته شده و پس از پایان این مرحله تغییر خواهد کرد.
اگر واقعاً میخوای Web Pentesting رو شروع کنی، از همینجا شروع کن.
📌 جهت ثبت نام،به ایدی زیر پیام دهید:
@ThbxSupport
@TryHackBox
THB-WP101 : Web Penetration Testing Fundamentals
ورود به Web Penetration Testing با حفظ کردن چند Vulnerability شروع نمی شود.
اگر قرار است یک Web Pentester باشید، باید بتوانید یک Web Application را بشناسید، Attack Surface آن را پیدا کنید، نقاط ورودی را بررسی کنید، رفتار Authentication و Access Control را تحلیل کنید، Vulnerabilityها را تست و Validate کنید و در نهایت Impact و مسیر حمله را مستند کنید.
دوره ما برای ساختن همین مهارت‌ها طراحی شده است.
⏳زمان یادگیری: حدود 40-50 ساعت
🛠 80 الی 90 درصد Practical
📌 کلاس : آنلاین
💠 مشاهده سرفصل ها
💢 ثبت نام اولیه شروع شد
⭕ تاریخ شروع کلاس : ۱۴۰۵/۰۶/۲۲
👤 مدرس : مهندس محمد طاهری
💠 لینکدین مدرس
📌 توضیحات تکمیلی
💰
💰
🔥 تخفیف ویژه برای ۵ نفر اول : ۲,۸۹۹,۰۰۰ تومان
این قیمت برای ثبت‌نام اولیه در نظر گرفته شده و پس از پایان این مرحله تغییر خواهد کرد.
اگر واقعاً میخوای Web Pentesting رو شروع کنی، از همینجا شروع کن.
📌 جهت ثبت نام،به ایدی زیر پیام دهید:
@ThbxSupport
@TryHackBox
🔥4
Try Hack Box
🛡️ SAML SECURITY SERIES | PART 02 🎫 Signature Wrapping وقتی Signature معتبره، ولی Application چیز دیگه‌ای رو میخونه! در قسمت قبل گفتیم یکی از اولین چیزهایی که در بررسی یک SAML Implementation باید بهش توجه کنیم، Signature Validation هست. حالا بریم سراغ یکی…
🛡️ SAML SECURITY SERIES | PART 03
ا💥 XML Attacks : وقتی خود Parser تبدیل به Attack Surface میشه
قسمت قبل رفتیم سراغ XSW (XML Signature Wrapping).
حالا یه سؤال که خیلی وقت ها ازش رد می‌شیم:
فرض کن Signature رو بررسی کردی.
درست هم Validate شد.
میتونی بگی:
«خب، پس SAML امنه.»
نه.
چون یه لایه‌ی دیگه هنوز سر جاشه:
XML.
اSAML شدیداً به XML وابسته است.
یعنی حتی اگر منطق Authentication و Signature Validation درست پیاده‌سازی شده باشن، هنوز نحوه‌ی پردازش XML میتونه خودش یک Attack Surface باشه.
اینجا اولین چیزی که ارزش بررسی داره:
DTD Processing
چرا؟
چون اگر XML Parser اجازه‌ی پردازش DTD یا External Entityها رو بده، ممکنه وارد یک دسته‌ی کاملاً متفاوت از حملات بشیم:
🔹 XXE — XML External Entity
🔹 XML DoS
🔹 Billion Laughs Attack
این مشکلات لزوماً به Signature مربوط نیستن.
حتی ممکنه Signature کاملاً معتبر باشه، ولی XML Parser رفتار ناامنی داشته باشه.
پس وقتی یک SAML Endpoint جلوی شماست، فقط نپرسید:
«Signature اوکیه؟»
یه قدم عقب تر برید.
بپرسید:
اXML چطور Parse میشه؟
اDTD چطور Handle میشه؟
اExternal Entityها اجازه‌ی پردازش دارن؟
اParser با XMLهای غیرعادی یا Malformed چطور رفتار میکنه؟
اینجا دقیقاً همون جاییه که طرز فکر Security Tester مهم میشه.
چون هدف فقط پیدا کردن یک Payload نیست.
اول باید بفهمی:
اApplication دقیقاً چطور XML رو پردازش میکنه؟
یک SAML Implementation ممکنه از نظر Signature Validation کاملاً درست باشه...
ولی XML Parser اون همچنان میتونه یک Attack Surface مستقل داشته باشه.
و این دو موضوع رو نباید با هم قاطی کرد.
حالا نوبت شماست
فرض کن رسیدی به یک SAML Endpoint.
قبل از اینکه بری سراغ Authentication Logic، فقط اجازه داری یکی از این موارد رو بررسی کنی:
1️⃣ DTD Processing
2️⃣ External Entities
3️⃣ Entity Expansion
4️⃣ رفتار Parser در برابر XMLهای غیرعادی / Malformed
کدوم رو انتخاب میکنی؟
و مهم تر:
چرا همون یکی؟
میخوام ببینم انتخابت بر اساس Attack Surface و رفتار Applicationه...
یا فقط چون اسم یک Vulnerability رو شنیدی.
@TryHackBox
#امنیت_سایبری #تست_نفوذ
ا💥 XML Attacks : وقتی خود Parser تبدیل به Attack Surface میشه
قسمت قبل رفتیم سراغ XSW (XML Signature Wrapping).
حالا یه سؤال که خیلی وقت ها ازش رد می‌شیم:
فرض کن Signature رو بررسی کردی.
درست هم Validate شد.
میتونی بگی:
«خب، پس SAML امنه.»
نه.
چون یه لایه‌ی دیگه هنوز سر جاشه:
XML.
اSAML شدیداً به XML وابسته است.
یعنی حتی اگر منطق Authentication و Signature Validation درست پیاده‌سازی شده باشن، هنوز نحوه‌ی پردازش XML میتونه خودش یک Attack Surface باشه.
اینجا اولین چیزی که ارزش بررسی داره:
DTD Processing
چرا؟
چون اگر XML Parser اجازه‌ی پردازش DTD یا External Entityها رو بده، ممکنه وارد یک دسته‌ی کاملاً متفاوت از حملات بشیم:
🔹 XXE — XML External Entity
🔹 XML DoS
🔹 Billion Laughs Attack
این مشکلات لزوماً به Signature مربوط نیستن.
حتی ممکنه Signature کاملاً معتبر باشه، ولی XML Parser رفتار ناامنی داشته باشه.
پس وقتی یک SAML Endpoint جلوی شماست، فقط نپرسید:
«Signature اوکیه؟»
یه قدم عقب تر برید.
بپرسید:
اXML چطور Parse میشه؟
اDTD چطور Handle میشه؟
اExternal Entityها اجازه‌ی پردازش دارن؟
اParser با XMLهای غیرعادی یا Malformed چطور رفتار میکنه؟
اینجا دقیقاً همون جاییه که طرز فکر Security Tester مهم میشه.
چون هدف فقط پیدا کردن یک Payload نیست.
اول باید بفهمی:
اApplication دقیقاً چطور XML رو پردازش میکنه؟
یک SAML Implementation ممکنه از نظر Signature Validation کاملاً درست باشه...
ولی XML Parser اون همچنان میتونه یک Attack Surface مستقل داشته باشه.
و این دو موضوع رو نباید با هم قاطی کرد.
حالا نوبت شماست
فرض کن رسیدی به یک SAML Endpoint.
قبل از اینکه بری سراغ Authentication Logic، فقط اجازه داری یکی از این موارد رو بررسی کنی:
1️⃣ DTD Processing
2️⃣ External Entities
3️⃣ Entity Expansion
4️⃣ رفتار Parser در برابر XMLهای غیرعادی / Malformed
کدوم رو انتخاب میکنی؟
و مهم تر:
چرا همون یکی؟
میخوام ببینم انتخابت بر اساس Attack Surface و رفتار Applicationه...
یا فقط چون اسم یک Vulnerability رو شنیدی.
@TryHackBox
#امنیت_سایبری #تست_نفوذ
Media is too big
VIEW IN TELEGRAM
حل چلنچ : The Broken Trust : THB CTF
حل چالش توسط اقا احمد عزیز از اعضای کانال .
@TryHackBox
#CTF_THB
حل چالش توسط اقا احمد عزیز از اعضای کانال .
@TryHackBox
#CTF_THB
❤3
📌 دوره THB-WP101 : Web Penetration Testing Fundamentals
ورود به Web Penetration Testing با حفظ کردن چند آسیب پذیری شروع نمی شود.
اگر قرار است یک Web Pentester باشید، باید بتوانید یک Web Application را بشناسید، Attack Surface آن را پیدا کنید، نقاط ورودی را بررسی کنید، رفتار Authentication و Access Control را تحلیل کنید، Vulnerabilityها را تست و Validate کنید و در نهایت Impact و مسیر حمله را مستند کنید.
دوره ما برای ساختن همین مهارت‌ها طراحی شده است.
📌 ویدئو معرفی دوره
⏳زمان یادگیری: حدود 40-50 ساعت
🛠 80 الی 90 درصد عملی
📌 کلاس : آنلاین
💠 مشاهده سرفصل ها
💢 ثبت نام اولیه شروع شد
⭕ تاریخ شروع کلاس : ۱۴۰۵/۰۶/۲۲
👤 مدرس : مهندس محمد طاهری
💠 لینکدین مدرس
📌 توضیحات تکمیلی
💰 ارزش اصلی دوره: ۵،۹۰۰،۰۰۰ تومان
💰 قیمت استاندارد : ۳,۹۸۹,۰۰۰ تومان
🔥 تخفیف ویژه برای ۵ نفر اول : ۲,۸۹۹,۰۰۰ تومان
این قیمت برای ثبت‌نام اولیه در نظر گرفته شده و پس از پایان این مرحله تغییر خواهد کرد.
اگر واقعاً میخوای Web Pentesting رو شروع کنی، از همینجا شروع کن.
📌 جهت ثبت نام،به ایدی زیر پیام دهید:
@ThbxSupport
@TryHackBox
ورود به Web Penetration Testing با حفظ کردن چند آسیب پذیری شروع نمی شود.
اگر قرار است یک Web Pentester باشید، باید بتوانید یک Web Application را بشناسید، Attack Surface آن را پیدا کنید، نقاط ورودی را بررسی کنید، رفتار Authentication و Access Control را تحلیل کنید، Vulnerabilityها را تست و Validate کنید و در نهایت Impact و مسیر حمله را مستند کنید.
دوره ما برای ساختن همین مهارت‌ها طراحی شده است.
📌 ویدئو معرفی دوره
⏳زمان یادگیری: حدود 40-50 ساعت
🛠 80 الی 90 درصد عملی
📌 کلاس : آنلاین
💠 مشاهده سرفصل ها
💢 ثبت نام اولیه شروع شد
⭕ تاریخ شروع کلاس : ۱۴۰۵/۰۶/۲۲
👤 مدرس : مهندس محمد طاهری
💠 لینکدین مدرس
📌 توضیحات تکمیلی
💰 ارزش اصلی دوره: ۵،۹۰۰،۰۰۰ تومان
💰 قیمت استاندارد : ۳,۹۸۹,۰۰۰ تومان
🔥 تخفیف ویژه برای ۵ نفر اول : ۲,۸۹۹,۰۰۰ تومان
این قیمت برای ثبت‌نام اولیه در نظر گرفته شده و پس از پایان این مرحله تغییر خواهد کرد.
اگر واقعاً میخوای Web Pentesting رو شروع کنی، از همینجا شروع کن.
📌 جهت ثبت نام،به ایدی زیر پیام دهید:
@ThbxSupport
@TryHackBox
❤4👎3🔥1
🔐 چک لیست تست نفوذ شبکه های بی سیم (Wi-Fi Pentest Checklist)
تیم TryHackbox یک متدولوژی کامل برای تست امنیت شبکه های Wi-Fi (شامل WEP، WPA/WPA2 و WPA2-Enterprise) تهیه کرده که میتونه برای کارشناسان امنیت و علاقه مندان این حوزه مفید باشه.
جزئیات کامل + دسترسی به این چک لیست رو در پست لینکدین ما ببینید 👇
🔗 https://lnkd.in/d47sHZTe
#امنیت_سایبری #تست_نفوذ #تست_نفوذ_وایرلس
@TryHackBox
تیم TryHackbox یک متدولوژی کامل برای تست امنیت شبکه های Wi-Fi (شامل WEP، WPA/WPA2 و WPA2-Enterprise) تهیه کرده که میتونه برای کارشناسان امنیت و علاقه مندان این حوزه مفید باشه.
جزئیات کامل + دسترسی به این چک لیست رو در پست لینکدین ما ببینید 👇
🔗 https://lnkd.in/d47sHZTe
#امنیت_سایبری #تست_نفوذ #تست_نفوذ_وایرلس
@TryHackBox
👏3❤1
ا🔎 IDOR را با عوض کردن ID اشتباه نگیرید
خیلی ها وقتی یک Endpoint مثل این میبینند:
اولین کاری که میکنند این است:
اگر جواب گرفتند، می گویند IDOR پیدا شد.
اما تست حرفه ای کمی متفاوت است.
اول باید بفهمی این Endpoint چه Objectی را کنترل میکند و Authorization دقیقاً کجا اعمال میشود.
یک روش ساده:
با Account A یک Object بساز.
همان Object را با Account B درخواست کن.
ببین Server فقط Authentication را بررسی میکند یا واقعاً Ownership را هم بررسی میکند.
بعد سراغ تغییر Identifier برو.
چون سؤال اصلی این نیست:
سؤال اصلی این است:
«آیا Server قبل از دسترسی به Object، بررسی میکند این Object واقعاً متعلق به من است؟»
اگر پاسخ دوم «نه» باشد، مشکل فقط یک ID قابل‌حدس نیست؛ یک Authorization Failure است.
@TryHackBox
#تست_نفوذ #امنیت_وب #امنیت_سایبری
خیلی ها وقتی یک Endpoint مثل این میبینند:
GET /api/users/123
اولین کاری که میکنند این است:
GET /api/users/124
اگر جواب گرفتند، می گویند IDOR پیدا شد.
اما تست حرفه ای کمی متفاوت است.
اول باید بفهمی این Endpoint چه Objectی را کنترل میکند و Authorization دقیقاً کجا اعمال میشود.
یک روش ساده:
با Account A یک Object بساز.
همان Object را با Account B درخواست کن.
ببین Server فقط Authentication را بررسی میکند یا واقعاً Ownership را هم بررسی میکند.
بعد سراغ تغییر Identifier برو.
چون سؤال اصلی این نیست:
«آیا میتوانم ID را تغییر بدهم؟»
سؤال اصلی این است:
«آیا Server قبل از دسترسی به Object، بررسی میکند این Object واقعاً متعلق به من است؟»
اگر پاسخ دوم «نه» باشد، مشکل فقط یک ID قابل‌حدس نیست؛ یک Authorization Failure است.
@TryHackBox
#تست_نفوذ #امنیت_وب #امنیت_سایبری
👍7❤6
Media is too big
VIEW IN TELEGRAM
حل چلنچ دوم :
Race Against Trust : THB CTF
حل CTF توسط اقا ایمان عزیز از اعضای کانال .
@TryHackBox
#CTF_THB
Race Against Trust : THB CTF
حل CTF توسط اقا ایمان عزیز از اعضای کانال .
@TryHackBox
#CTF_THB
❤8
This media is not supported in your browser
VIEW IN TELEGRAM
حل چلنچ دوم :
Race Against Trust : THB CTF
حل CTF توسط اقا احمد عزیز از اعضای کانال .
@TryHackBox
#CTF_THB
Race Against Trust : THB CTF
حل CTF توسط اقا احمد عزیز از اعضای کانال .
@TryHackBox
#CTF_THB
❤5