⭕ تصاحب حساب کاربری
تو این مقاله یک تکنیک جالب بایپس 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
تو این مقاله یک تکنیک جالب بایپس 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
Medium
Account Takeover Worth of $2500
whoami?
👍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
تکنیک های دور زدن مسیر های 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