Network Security Channel
2.57K subscribers
5.33K photos
3.42K videos
5.56K files
4.44K links
شروع از سال 1395
Security Operation Center (SOC)
Bug Bounty
Vulnerability
Pentest
Hardening
Linux
Reasearch
Security Network
Security Researcher
DevSecOps
Blue Team
Red Team
Download Telegram
تصاحب حساب کاربری

تو این مقاله یک تکنیک جالب بایپس 403 در API بررسی میشه
اندپوینت زیر در صورت ارسال درخواست کد 403 میده و میگه دسترسی ندارید
POST /<organizationID>/addEmail/<DemoUserID>/
تست نفوذگر اینجا با یک تکنیک ساده از traversal sequence استفاده کرده و در ادامه اش از UserID قربانی استفاده کرده
POST /<organizationID>/addEmail/<DemoUserID>/../<UserID>/

و در اینجا کد 200 گرفته و با موفقیت ایمیل قربانی رو تغییر داده

لینک مقاله:
https://gonzxph.medium.com/account-takeover-worth-of-2500-e643661f94e9

تحلیل:‌ به نظر میاد برنامه نویس اینجا اومده Requests URI رو گرفته و  چک کرده که آیا DemoUserID در organization وجود داره یا خیر؟ اگر وجود نداشت به کاربر بگه که شما دسترسی این کار رو ندارید و اگر وجود داشت بنظر میاد این درخواست برای سرویس دیگه ای که مسئول تغییر ایمیل بوده ارسال شده
در اینجا ما ۲ تا زبان مختلف پایتون و php رو در مواجه با این موضوع تست کردیم تا ببینم رفتار این ها با traversal sequence به چه صورت هست؟(‌ traversal sequence هم همون /.. هست). و آیا path normalization دارند؟ ( یعنی فانکشن با لایبرری بیاد traversal sequence هارو apply‌ کنه و مسیر یا path به اصطلاح normalize بشه
لینک مرتبط با path normalization اگر خواستید مطالعه کنید
https://en.wikipedia.org/wiki/URI_normalization

در اینجا یک سرور apache بالا آوردیم و بهش درخواست ارسال کردیم
درخواست اول با پایتون به این صورت
import requests
requests.get("https://server/a/b/../c")
درخواست دوم با php به این صورت
file_get_contents("https://server/a/b/../c");

نتایج جالب بود
لاگ سرور آپاچی:
"GET /a/c HTTP/1.1" 404 492 "-" "python-requests/2.28.1"
"GET /a/b/../c HTTP/1.1" 404 455 "-" "-"

این یعنی لایبرری requests پایتون اینجا path normalization رو اپلای کرده و php این کار رو نکرده
این تست هایی که انجام دادیم صرفا نشان دهنده این هستند که رفتار زبان و لایبرری و فریمورک های مختلف فرق میکنه.
حالا برگردیم به آسیب پذیری ای که داشتیم توضیحش میدادیم

گفتیم بعد از بررسی request uri برنامه نویس میاد این رو به سرویس دیگه ای ارسال میکنه حالا اگر این ارسال کردن با زبانی یا لایبرری اتفاق بیفته که path normalization انجام بده آسیب پذیری وجود داره و اگر انجام نده آسیب پذیری وجود نداره.

این ها صرفا یک فرض بود و ممکنه موضوع به طور کل چیز دیگه ای باشه ولی خب ما نیاز داشتیم یکم دیپ بشیم و ببینم موضوع از چه قرار هست

#ATO #bypass403
کانال آموزش کامپیوتر
@Engineer_Computer
👍2
⭕️ Bypassing 403 endpoints using automated Trickest workflows

تکنیک های دور زدن مسیر های 403 در وب سرور و API ها:

1. فاز تو در تو
اگر به مسیری مثل log/ درخواست زدید و 403 گرفتید ادامه این مسیر رو به شکل /log/FUZZ/ میتونید فاز کنید

2. هدر های HTTP
بعضی از هدر های خاص HTTP مثل X-Forwarded-For میتونه در این زمینه کمکتون کنه

3. استفاده از کاراکتر های خاص
برای مثال اگر به info.php/ درخواست زدید و 403 گرفتید میتونید
مسیر */info.php/ رو هم تست کنید

4. تغییر HTTP Method
این موضوع که تحت عنوان verb tampering هم شناخته میشه بررسی کردن متد های مختلف HTTP نظیر GET POST PUT PATCH در مسیر ها و اندپوینت های مختلف هست.

5. تغییر extension فایل
برای مثال تغییر config.php/ به .config.php/ ( به نقطه آخرش توجه کنید)

6. تغییر ورژن پروتکل HTTP
شما می تونید نسخه های مختلف این پروتکل رو بررسی کنید مثلا HTTP/1.0 و HTTP/1.1 و ...

منبع
https://trickest.com/blog/bypass-403-endpoints-with-trickest/

#bypass403
@Engineer_Computer
👍2🔥1