ذهنیت یک هکر حرفه‌ای

برای اینکه توی دنیای امنیت وب موفق بشی، باید طرز فکر یه محقق امنیتی رو داشته باشی:

🔹 همیشه کنجکاو باش 🤔
هر چیزی که می‌بینی (یه فرم، یه URL، یه API) رو زیر سوال ببر:
💭 "اگه اینو دستکاری کنم چی می‌شه؟ اگه یه مقدار غیرمنتظره بفرستم چی؟ اگه جای یه عدد، یه رشته متنی بذارم؟"

🔹 شکستن رو یاد بگیر 🔨
سیستم‌ها رو مثل یه پازل ببین که باید راهی برای دور زدنش پیدا کنی. هر چیزی که ساخته شده، یه جایی ممکنه قابل شکستن باشه.

🔹 مثل یه توسعه‌دهنده فکر کن 🧑‍💻
بفهم برنامه‌نویس‌ها چطور کد می‌زنن و کجا ممکنه اشتباه کنن. خیلی از باگ‌ها حاصل بی‌دقتی توی کد نویسیه.

🔹 صبر و دقت داشته باش 🔍
باگ‌های بزرگ توی جزئیات ریز پنهان شدن. یه هکر واقعی کسیه که جزئیات رو نادیده نمی‌گیره!

⚡️ یادگیری امنیت وب از اینجا شروع می‌شه: با ذهنیت درست!


#Hacker_mindset


۱۲ ⁄ ۱۲ ⁄ ۱۴۰۳

سلام به همه! 👋🏻

از امروز هر چیزی که درباره وب و امنیتش یاد می‌گیرم، اینجا با شما به اشتراک می‌ذارم. قراره آسیب‌پذیری‌های وب رو باهم بررسی کنیم و قدم‌به‌قدم یاد بگیریم.

اگه مطالب براتون مفید بود، معرفی کانال به بقیه می‌تونه بهم انگیزه بیشتری بده تا با انرژی ادامه بدم.

خب OAuth چیه؟ داستان از کجا شروع شد؟

این کلمه OAuth مخفف Open Authorization هست. یه پروتکل استاندارد برای اینه که یه اپلیکیشن (کلاینت) بتونه بدون نیاز به گرفتن یوزرنیم و پسورد از یه کاربر، به منابع امنی که روی یه سرور دیگه هست دسترسی بگیره.

چرا OAuth به وجود اومد؟

یه زمانی هر سرویسی که می‌خواست به اطلاعات کاربر توی یه سایت دیگه دسترسی بگیره، باید یوزرنیم و پسوردش رو می‌گرفت! 😵
مثلاً یه اپ موبایل که می‌خواست به ایمیل‌های جیمیل کاربر دسترسی داشته باشه، باید پسورد جیمیل رو ازش می‌خواست! 🤦‍♂️
مشکلات این روش:
❌ امنیت پایین (چون ممکنه کلاینت مخرب باشه و پسورد رو جایی ذخیره کنه)
❌ عدم کنترل دسترسی (اگه پسورد رو بدی، کل دسترسی رو دادی!)
❌ امکان تغییر پسورد (اگه پسورد تغییر کنه، همه چی از کار می‌افته)

پس یه روش بهتر لازم بود که هم امن باشه، هم کنترل‌شده، هم استاندارد. اینجاست که OAuth اومد وسط!

دو تا نسخه اصلی داره OAuth:
OAuth 1.0 (قدیمی‌تر، پیچیده‌تر، امضای دیجیتال داشت ولی کمتر استفاده شد)
OAuth 2.0 (ورژن امروزی که همه جا استفاده میشه)

ما فقط درباره OAuth 2.0 صحبت می‌کنیم چون نسخه 1 دیگه کمتر استفاده میشه

چطوری کار می‌کنه؟

برای این ساخته شده که یه کلاینت بتونه با اجازه‌ی کاربر، یه توکن (کلید دسترسی) بگیره و بعدش با اون توکن به یه API مشخص دسترسی داشته باشه.

🏛 اجزای اصلی OAuth

1️⃣ Resource Owner (صاحب منابع) → همون کاربر که اطلاعاتش رو داریم.
2️⃣ Client (کلاینت) → همون اپلیکیشنی که می‌خواد به اطلاعات کاربر دسترسی داشته باشه.
3️⃣ Authorization Server (سرور احراز هویت) → سروری که احراز هویت انجام میده و توکن میده.
4️⃣ Resource Server (سرور منابع) → همون جایی که داده‌های کاربر نگه‌داری میشه.

نحوه تعامل:
مرحله اول: کاربر به کلاینت اجازه میده که به اطلاعاتش دسترسی بگیره.
مرحله دوم: کلاینت یه درخواست به Authorization Server میفرسته.
مرحله سوم: Authorization Server یه کد موقت (Authorization Code) به کلاینت میده.
مرحله چهارم: کلاینت این کد رو می‌فرسته به Authorization Server تا توکن دسترسی (Access Token) بگیره.
مرحله پنجم: کلاینت حالا می‌تونه با Access Token به Resource Server درخواست بفرسته و داده‌ها رو بگیره.

💡 نکته: کاربر هیچ وقت پسوردش رو به کلاینت نمیده، بلکه مستقیم توی سرور احراز هویت لاگین میکنه! ✅

یه مفهوم داریم به اسم Grant Types بیایید ببینیم این چیه؟

این کلمه Grant Type یعنی روشی که کلاینت توکن رو می‌گیره. توی OAuth 2.0 چند نوع مختلف داریم:

1️⃣ Authorization Code (مهم‌ترین و امن‌ترین روش)

بیشتر برای وب‌سایت‌ها و اپ‌های سمت سرور استفاده میشه.
💡 توی این روش، کاربر اول توی سرور احراز هویت لاگین می‌کنه و بعد به کلاینت یه کد موقت (Authorization Code) داده میشه. بعدش کلاینت اون کد رو به سرور احراز هویت می‌فرسته و یه Access Token می‌گیره.
✅ امن‌ترین روشه، چون پسورد هیچ وقت به کلاینت داده نمیشه.

2️⃣ Implicit Grant (حذف شده!)


برای اپ‌های فرانت‌اند استفاده می‌شد ولی به خاطر مشکلات امنیتی دیگه پیشنهاد نمیشه.

3️⃣ Client Credentials (بدون کاربر، فقط بین سرورها)


وقتی دو تا سرور میخوان با هم صحبت کنن و نیازی به کاربر نیست، از این روش استفاده میشه.
💡 توی این روش، کلاینت مستقیم اطلاعاتش رو به سرور میده و یه توکن می‌گیره.

4️⃣ Password Grant (بدترین روش، دیگه استفاده نمیشه)


این روش مستقیم یوزرنیم و پسورد رو از کاربر می‌گیره و توکن میده. خیلی خطرناکه و دیگه توصیه نمیشه.

🔄 فلوهای OAuth 2.0 چطوری کار می‌کنه؟

حالا بیایم دقیق‌تر و مرحله‌به‌مرحله بررسی کنیم که وقتی یه کاربر روی دکمه "Login with Facebook" کلیک می‌کنه، چه اتفاقی می‌افته.

ورود با فیسبوک (Authorization Code Flow)
فرض کنید یه سایت داره از OAuth 2.0 برای ورود با فیسبوک استفاده می‌کنه.

مرحله 1: کلیک روی دکمه "Login with Facebook"

کاربر روی دکمه کلیک می‌کنه، و سایت باید کاربر رو بفرسته به سرور احراز هویت فیسبوک.
درخواست ریدایرکت به این URL میره:

GET https://www.facebook.com/v12.0/dialog/oauth
    ?client_id=123456789
    &redirect_uri=https://yourwebsite.com/callback
    &response_type=code
    &scope=email,public_profile
    &state=randomstring123

توضیح پارامترها:

client_id :
آی‌دی کلاینت که فیسبوک به سایت ما داده.

redirect_uri :
بعد از احراز هویت، کاربر رو به این URL برمی‌گردونه.

response_type=code

چون می‌خوایم Authorization Code بگیریم.

scope=email,public_profile :
داریم می‌گیم که می‌خوایم به ایمیل و پروفایل عمومی کاربر دسترسی داشته باشیم.

state=randomstring123:
یه مقدار تصادفی که از CSRF جلوگیری کنه.


اتفاقی که اینجا میفته:
🔹 کاربر به صفحه لاگین فیسبوک هدایت میشه.
🔹 فیسبوک از کاربر می‌پرسه که آیا اجازه میده این سایت به اطلاعاتش دسترسی داشته باشه یا نه؟

مرحله 2: تایید کاربر در فیسبوک
🔹 کاربر توی فیسبوک لاگین می‌کنه و روی دکمه "Allow" کلیک می‌کنه.
🔹 فیسبوک حالا کاربر رو برمی‌گردونه به سایت ما و یه Authorization Code میده.

GET https://yourwebsite.com/callback
    ?code=A1B2C3D4
    &state=randomstring123

توضیح:

code=A1B2C3D4 :

یه کد موقت که فقط چند دقیقه اعتبار داره.

state=randomstring123:

اینو چک می‌کنیم که همون مقداریه که قبلاً فرستادیم، تا حمله CSRF اتفاق نیفته.