uk
Feedback
🕸 Articles

🕸 Articles

Відкрити в Telegram

Web Security Researcher, Bug Hunter 369

Показати більше
416
Підписники
Немає даних24 години
+127 днів
+7730 день
Архів дописів
Author: zarvan Language: Persian Telegram channel: @web_articles

سلام به همه امیدوارم حالتون خوب باشه دومین مقاله من راجب HTTP Host Header Attacks هست توی این مقاله سعی کردم به صورت عمیق این آسیب پذیری رو بررسی کنم.

در حال پخت و پز 🧑🏻‍💻
در حال پخت و پز 🧑🏻‍💻

Author: zarvan Language: Persian Telegram channel: @web_articles

در این مقاله Web Timing Attack رو شکافتیم - تکنیکی که با تحلیل زمان پاسخ سرور، اطلاعات حساس رو از سیستم قربانی استخراج میکنه.

اینم خود ابزار

اینم خروجی ابزار
اینم خروجی ابزار

ابزار روی دامنه att.com اجرا می‌کنیم
ابزار روی دامنه att.com اجرا می‌کنیم

photo content

یه ابزار ساختم که یه لیست ساب‌دامنه می‌گیره، می‌ده به هوش مصنوعی و اونم ساب‌دامنه‌های جدید برات می‌سازه. دوتا حالت داره: یا خودت لیست رو بهش بدی، یا اگه چیزی ندی، خودش می‌ره از crt.sh ساب‌دامنه‌های تارگت رو می‌گیره و بعد یه لیست جدید تحویلت می‌ده." این ابزار قابلیت پیشرفته شدن خیلی داره ولی فقط خواستم بگم به جای نگران بودن از موقعیت پیش اومده استفاده کنید. @web_articles

یه جمله هست میگه: توی هر تهدیدی یه فرصت هست. من خیلی هارو دیدم که نگران هوش مصنوعی هستن برای اینکه آیا با اومدنش یه شغلی رو شروع کنن یا نه! یا اینکه میگن با اومدن هوش مصنوعی شغل ما از بین میره به نظرم فقط باید از هر چیزی که دم دستتون هست برای رسیدن به هدفتون استفاده کنید.

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

خب Refresh Token باید یه مکانیسم لغو داشته باشه تا اگه لو رفت، کاربر بتونه از همه‌جا لاگ‌اوت بشه. سرور یه API می‌ده که کلاینت می‌تونه توکن‌ها رو باطل کنه درخواست برای لغو (Revoke) یک Access Token
POST /revoke
Content-Type: application/x-www-form-urlencoded

token=ACCESS_TOKEN
&client_id=your-client-id
&client_secret=your-client-secret
بعد از این درخواست، توکن دیگه معتبر نیست و نمی‌شه باهاش درخواست زد.

اگه Refresh Token هم منقضی بشه چی؟ اگه Refresh Token هم منقضی بشه یا سرور تشخیص بده که نباید دیگه ازش استفاده بشه، این پیام برمی‌گرده معمولا:
{
  "error": "invalid_grant",
  "error_description": "Refresh token is expired"
}
اینجا کاربر باید دوباره لاگین کنه تا یه Refresh Token جدید بگیره یه نکته رو بگم ما با استفاده از Refresh Token برای گرفتن Access Token جدید استفاده می‌کنیم. اگه Refresh Token منقضی بشه، کاربر باید دوباره لاگین کنه پس استفاده ما از Refresh Token فقط برای گرفتن یه Access Token جدید هست.

حالا اگر access token منقضی بشه چی؟ وقتی Access Token منقضی می‌شه، کلاینت باید این درخواست رو به Authorization Server بفرسته:
POST /token HTTP/1.1
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&refresh_token=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...
&client_id=your-client-id
&client_secret=your-client-secret
اگه Refresh Token معتبر باشه، سرور یه Access Token جدید می‌ده:
{
  "access_token": "new-access-token-123",
  "token_type": "Bearer",
  "expires_in": 3600
}
✅ حالا کلاینت از Access Token جدید برای درخواست‌هاش استفاده می‌کنه.

حالا که کلاینت Access Token داره، یه درخواست به ریسورس سرور (مثلاً API گوگل) می‌فرسته:
GET https://www.googleapis.com/oauth2/v3/userinfo
Authorization: Bearer ya29.A0AfH6SM...
ریسورس سرور (یعنی www.googleapis.com) بررسی می‌کنه که توکن معتبره یا نه، اگه معتبر باشه، اطلاعات کاربر رو برمی‌گردونه: { "sub": "110169484474386276334", "name": "zarvan0x01", "given_name": "zarvan", "family_name": "zurvanism", "email": "zarvan@gmail.com", "picture": "https://lh3.googleusercontent.com/a-/AOh14Gj..." } حالا کلاینت چیکار می‌کنه؟ ✅ اطلاعات کاربر رو ذخیره می‌کنه. ✅ کاربر رو به حالت لاگین‌شده درمیاره. ✅ احتمالاً یه سشن (Session) یا کوکی (Cookie) بسته به نوع پیاده سازیش برای کاربر ایجاد می‌کنه که لاگینش حفظ بشه. و اینجوریه که کاربر بدون دیدن Access Token، لاگین می‌شه! توی این مرحله که ریپلای زدم اگر یادتون باشه بعد از ریدارکت به کلاینت یهو ما دیدیم که لاگین شدیم ولی اون پشت برای لاگین شدن این درخواست ها هم زده شده

یه توضیح اضافه تر راجب اینکه چطوری کلاینت میاد و access token رو دریافت میکنه بگم این مرحله توی مرورگر کاربر انجام نمیشه، بلکه کلاینت پشت‌صحنه یه درخواست دیگه به سرور OAuth می‌زنه کلاینت این درخواست رو از سمت سرور خودش به Authorization Server (گوگل) می‌فرسته:
POST https://oauth2.googleapis.com/token
Content-Type: application/x-www-form-urlencoded

client_id=YOUR_CLIENT_ID
&client_secret=YOUR_CLIENT_SECRET
&code=4/0AQSTgQFzS9eHAd2HHL9-GEX4BsDgucBYuBwWuOFhFp8puAa1TgAihhDnQITlvHKRo8TTdA
&redirect_uri=https://yourwebsite.com/google-login
&grant_type=authorization_code
توی این درخواست، Authorization Code که از قبل توی URL بود، ارسال می‌شه به گوگل. اگه این درخواست موفقیت‌آمیز باشه، گوگل یه Access Token برمی‌گردونه، مثل این:
{
  "access_token": "ya29.A0AfH6SM...",
  "expires_in": 3600,
  "refresh_token": "1//0gQ...",
  "scope": "email profile openid",
  "token_type": "Bearer"
}

photo content

و در نهایت access token داده میشه به کلاینت و ما توی وبسایت لاگین میشیم.