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

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

🔹 همیشه کنجکاو باش 🤔
هر چیزی که می‌بینی (یه فرم، یه 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 اتفاق نیفته.

***این مرحله توسط کاربر دیده نمیشه***

مرحله 3: تبدیل Authorization Code به Access Token

حالا سایت ما باید این Authorization Code رو به یه Access Token تبدیل کنه.

🔹 سایت یه درخواست POST می‌فرسته به سرور فیسبوک:

POST https://graph.facebook.com/v12.0/oauth/access_token
Content-Type: application/x-www-form-urlencoded

client_id=123456789
&client_secret=SECRET123
&redirect_uri=https://yourwebsite.com/callback
&code=A1B2C3D4
&grant_type=authorization_code

توضیح:

client_id :

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

client_secret :
یه مقدار مخفی که فقط سایت ما داره (برای احراز هویت).

redirect_uri :
باید همون چیزی باشه که توی مرحله اول فرستادیم.


code=A1B2C3D4 :
همون کد موقتی که فیسبوک داده بود.

grant_type=authorization_code :
می‌گیم که می‌خوایم Authorization Code رو به Access Token تبدیل کنیم.



پاسخ فیسبوک:

{
  "access_token": "EAAJ3gZB4ZC9wBABZC...",
  "token_type": "bearer",
  "expires_in": 5184000
}

چی گرفتیم؟

access_token:

این توکن رو داریم و می‌تونیم ازش برای گرفتن اطلاعات کاربر استفاده کنیم!

token_type :
همیشه bearer هست.

expires_in :
زمان اعتبار توکن (معمولاً چند ساعت یا روز).

مرحله 4: استفاده از Access Token برای گرفتن اطلاعات کاربر

حالا سایت ما می‌تونه از این Access Token استفاده کنه و اطلاعات کاربر رو از فیسبوک بگیره.

🔹 درخواست به API فیسبوک:

GET https://graph.facebook.com/me
    ?fields=id,name,email
    &access_token=EAAJ3gZB4ZC9wBABZC...

پاسخ فیسبوک:

{
  "id": "123456789",
  "name": "zarvan",
  "email": "zarvan@example.com"
}

حالا سایت ما اطلاعات کاربر رو داره و می‌تونه اونو لاگین کنه!

جمع‌بندی مراحل

1️⃣ کاربر روی "Login with Facebook" کلیک می‌کنه.
2️⃣ سایت کاربر رو می‌فرسته به فیسبوک برای لاگین و اجازه دادن.
3️⃣ فیسبوک بعد از تایید، Authorization Code رو به سایت ما میده.
4️⃣ سایت ما اون کد رو به Access Token تبدیل می‌کنه.
5️⃣ سایت با Access Token به API فیسبوک درخواست میده و اطلاعات کاربر رو می‌گیره.
6️⃣ حالا سایت می‌تونه کاربر رو احراز هویت کنه و داخل سیستم خودش لاگین کنه.

✅ با این روش، سایت بدون اینکه پسورد کاربر رو بگیره، از طریق فیسبوک لاگین انجام میده! 🚀

انواع توکن‌ها در OAuth

1️⃣ Access Token (توکن دسترسی)


🔹 یه رشته‌ی یونیک که کلاینت ازش برای درخواست به API استفاده می‌کنه.
🔹 عمرش محدوده (چند دقیقه یا ساعت) و بعدش منقضی میشه.

2️⃣ Refresh Token (توکن تمدید)


🔹 وقتی Access Token منقضی بشه، کلاینت از Refresh Token استفاده می‌کنه تا یه توکن جدید بگیره، بدون اینکه کاربر دوباره لاگین کنه!
🔹 عمر طولانی داره (مثلاً چند روز یا هفته).

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


راجب دوتا مقدار توی درخواست ها من چیزی نگفتم
این دوتا به نظرتون چیه و از کجا اومدن؟
client_id
client_secret

وقتی یه کاربر روی "ورود با Google" کلیک می‌کنه، فرآیند OAuth Authorization Code Flow (رایج‌ترین فلو) اجرا میشه. حالا، بعد از اینکه سرور OAuth به Client App یه Access Token میده، این توکن یا از نوع JWT هست یا Opaque

JWT (JSON Web Token)

یه توکن که داخلش اطلاعات کاربر هست و میشه بدون تماس به سرور، اعتبارش رو چک کرد.
کلاینت بدون نیاز به تماس با سرور OAuth، می‌تونه اطلاعات یوزر رو از داخل توکن استخراج کنه. چون JWT شامل اطلاعات کاربره، میشه از اون برای احراز هویت یوزر هم استفاده کرد.
هر کسی که این توکن رو داشته باشه، می‌تونه اطلاعاتش رو بخونه و بررسی کنه، اما نمی‌تونه تغییرش بده، چون امضاش چک می‌شه.
اگه لو بره، هر کسی می‌تونه ازش استفاده کنه تا زمانی که منقضی بشه.
🔹 بخش Payload شامل اطلاعاتی مثل user_id, exp (زمان انقضا), scopes (دسترسی‌ها) هست.

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30

Opaque Token

یه رشته تصادفی و بدون معنیه که فقط Authorization Server می‌فهمه چی توشه.
کلاینت باید هر بار که می‌خواد از API استفاده کنه، توکن رو به سرور OAuth بفرسته تا اعتبارش رو چک کنه.
امنیت بیشتری داره چون کلاینت نمی‌تونه محتوای توکن رو ببینه.

c48a87f3-d5a4-42f3-84f5-9e5a2c62115b

وقتی توی وبسایت وارد بخش login بشیم با این صفحه مواجه میشیم
من روی log in with google کلیک میکنم و یه درخواست ۳۰۲ ارسال میشه
به کجا ریداریکت میشیم؟ به گوگل

این صفحه بهمون نشون داده میشه
و آدرس ایمیل رو انتخاب میکنیم بعدش وارد صفحه دیگه میشیم که باید پسورد رو بزنیم