Try Hack Box: post #3220 — TG.ME

وقتی یک Chrome Extension روی سیستم نصب میشه، فایل‌ ها و منابع اون به‌صورت Local در دسترس قرار میگیرن. همین موضوع باعث میشه در یک Authorized Security Assessment امکان بررسی ساختار، Source Code و رفتار Extension وجود داشته باشه.

گاهی داخل همین فایل‌ ها میشه چیزهای جالبی پیدا کرد؛ مثلاً:

🔹 API Key
🔹 Token
🔹 Endpointهای داخلی
🔹 اطلاعات حساس
🔹 Permissionهای غیرضروری
🔹 ضعف‌ های موجود در منطق Extension


اما نکته مهم اینجاست:

صرفاً پیدا کردن یک API Key یا Token به معنی وجود آسیب پذیری نیست.

باید ببینیم این اطلاعات دقیقاً چه سطحی از دسترسی ایجاد میکنن و آیا واقعاً قابل سوءاستفاده هستن یا نه.

🔎 حتی برای پیدا کردن Extensionهای مرتبط با یک شرکت مشخص، میشه از Google Dork استفاده کرد.

مثلاً:
site:chromewebstore.google.com "nasa.gov"

کافیه nasa.gov رو با Domain موردنظر جایگزین کنید.

بعد از پیدا کردن Extension، مرحله جالب‌تر شروع میشه:


Source Code → Permissions → Endpoints → Secrets → Impac

t

🎯 ذهنیت باگ هانتر

به‌ جای اینکه فقط بپرسیم:
«چه چیزی پیدا کردم؟»
باید بپرسیم:

واقعاً با این چیزی که پیدا کردم، چه کاری میتونم انجام بدم

همین تغییر نگاه، یک Recon ساده رو به مسیر واقعی Vulnerability Discovery تبدیل می‌کنه.

💬 حالا سؤال:

اگر در Source Code یک Chrome Extension به یک API Key یا Token برخورد کنید، اولین چیزی که بررسی میکنید چیه؟

🔹 API Key
🔹 Endpoint
🔹 Permissions
🔹 Token Usage

انتخابتون رو بنویسید و بگید چرا. 👇



@TryHackBox

#باگ_بانتی #امنیت_سایبری #نکات_باگ_بانتی #امنیت_وب #امنیت_اپلیکیشن #تست_نفوذ #امنیت_اطلاعات
🔥2❤1
August 22, 2026 929 22