• سلاام و شب بخیر✋ پرقدرت بریم سراغ جلسه دوم😉 •

• روز دوم | Request چیه و مرورگر دقیقاً چه چیزی برای سرور می‌فرسته؟🧐 روز قبل فهمیدیم که وقتی یک سـایت رو باز می‌کنیم، مرورگر و سرور با هــمـدیگه ارتـبـاط برقرار می‌کنن و بینشون درخواسـت و جواب رد و بدل می‌شود. همچنین در تمرین روز اول یاد گرفتیم که با DevTools وارد بخش Network بـشـیم و Requestهای مختلفی رو که هـنـگام باز شدن یک صفحه ارسال می‌شن ببینیم.🙌 امروز می‌خوایم یک درخواست رو باز کنیم و ببینیم دقیقاً از چه قسمت‌هایی تشکیل شده.🔥 •

• قبلش بریم سراغ یک داستان واقعی : سال ۲۰۱۰، یک ابزار امنیتی به نام Firesheep منتشر شد. این ابزار توسط اریک باتلر ساخته شده بود و یک مشکل مهم در امنیت وب را به شکل بسیار ساده نشان می‌داد. »»» در آن سال‌ها بعضی وب‌سایت‌ها هنگام ورود کاربر از HTTPS استفاده می‌کردند، اما بعد از ورود، تمام ارتباطات کاربر را به شکل امن ادامه نمی‌دادند. در نتیجه مـمـکـن بود رمز عبور مسـتـقیماً در اختیار مهاجم قرار نگیرد، اما اطلاعات مربوط به نشست کاربر در معرض خــطـر باشد. برای فهمیدن اهمیت این موضوع، باید یک سؤال بپرسیم:⚠️ سرور از کجا می‌فهمد درخواست جدیدی که از مرورگــر دریــافــت کـرده، مربـوط به همـان کاربری است که چند لحظه قبل واردحساب شده است؟ اینجا مفهوم Cookie و Session اهمیت پیدا می‌کنه 👆⭕️ •

• برای درک بهتر درخواست | Request, فــرض کــن مـرورگـر این آدرس رو برای سرور ارسال کرده: GET /profile?id=123 HTTP/1.1 قسمت اول(GET)، یک Request Method | روش درخواست روش درخواست مشخص می‌کنه مرورگر چه نوع عملی رو از سرور می‌خواد. دو روش بسیار مهم برای شروع وجود داره: GET برای زمانی که معمولا می‌خوایم اطلاعاتی رو از سرور دریافت کنیم. POST برای زمانی که معمولاً می‌خوایم اطلاعاتی را به سرور ارسال کنیم. برای مثال، وقتی یک صفحه رو باز می‌کنی، مرورگر معمولاً از GET استفاده می‌کنه. اما وقتـی اطلاعــات یـک فرم را برای سـرور ارسال می‌کنی، احتمالا از POST استـفاده می‌کنه. اما قسمت جالب‌تر Request اینجاست👇 •

• /profile?id=123 بخش /profile مسیر درخواستِ.✅ یعنی مرورگر درخواست میکنه: «منبعی به نام profile را می‌خواهم.» اما جلوی علامت سؤال: id=123 به این بخش Query Parameter یا «پارامتر پرس‌وجو» گفته می‌شه. 👉 تعریف پارامتر: اطلاعـاتـی که هـمـراه درخواست برای سرور ارسال می‌شود 💻 در این مثال: id اسم پارامترِ 123 مقدار پارامترِ حالا یه مثال ساده‌تر👇 مثلا یک سایت فروشگاهی داریم و آدرس صفحه محصول اینه: /product?id=25 یعنی مرورگر از سرور محصولی با شناسه 25 رو درخواست می‌کنه😇 •

• اگه بنویسی: /product?id=26 احتمالا محصول دیگه‌ای رو نمایش میده. این به خودی خود مشکل امنیتی نیست🤷‍♂ اما اگر به جای محصول، اطلاعات حساب کاربران با شناسه مـشـخـص در دسـتـرس باشه چطور میشه❌⚠️ مثلاً: /profile?id=25 و با تغییر عدد به: /profile?id=26 اطلاعات کاربر دیگری نمایش داده بشه.(همون مواردی که قبلا گفته بودیم) در این حالت یه سوال امنیتی مهم مواجه میشیم: آیا برنامه بررسی می‌کنه که کاربر اجازه مشاهده اطلاعات شماره 26 رو داره؟🧐 اگر پاسخ منفی باشه، ممکنه با یک مشکل تو کنترل دستـرسی رو به رو باشیم. این همون مفهومیه که در روزهای آینده با عنوان IDOR و Broken Access Control بیشتر بررسی میکنیم •

• برای امشب کافیه💙 این مطالب رو با دقـت بخـونـیـن و اســتـفاده کنید ازش، تماما توسط متخصـصـیـن امنیت کدنا نوشته میشه و خیلیی میتونه بهتون تو این حوزه کمک کنه🙂🔥 اگر بعضی هارو متوجه نشدین نگران نباشید، یه بار دیگه با دقت بخونین :) •

• سلام رفیق ارزشمندم ✌️🏻 چطوری؟ آماده‌ای بریم برای بخش بعدی آموزش😉 •

• حالا می‌رسیم به Cookie، فکـر کن وارد یک سایت مـیـشی، نام کاربری و رمز عبورت رو وارد می‌کنی.💻 سرور اطلاعات رو بررسی می‌کنه و متوجه می‌شه که ورود موفق بوده.✅ اما وقتی چند ثانیه بعد وارد صفحه دیگه‌ای مـی‌شـی، سـرور بـایـد بدونه ایـن درخـواسـت متعلق به همون کاربر قبلیه. 🤌🏻 برای این کار، بسیاری از برنامه‌های وب از Session استفاده می‌کنن در واقع Session یا «نشست»، روشی برای نگهداری وضعیت یک کاربر در طول چندین درخواستِ. ⏰ به زبان ساده، Session کمک می‌کنه سرور متوجه بشه چند Request مــخــتلف مربوط به یک نشست کاربری هست. •

• برای مثال ممکن است چیزی شبیه این ببینی:👀 Cookie: session=abc123 (صرفاً یک مثال آموزشی) در یک برنامه واقعی، مقدار Session معمولاً ساختار و مقدار متفاوتی داره. اگر اطلاعات مربوط به Session یـک کاربرـ به دست فرد دیگری بیفته، بسته به نـحـوه طراحی برنامه، ممکنه اون فـرد بـتـونه ازش سوءاستـفـاده کــنـه و خـودش رو جای کاربر معرفی کنه به همین دلیل Session یکی از بخش‌های بسیار مهم امنیت برنامه‌های وب محـسوب میشه. حالا اگه یک Request رو از دید متخصص امنیت نگاه کـنـیـم🏴‍☠ وقتی یک Request رو در DevTools باز می‌کنی، فقط به URL نباید نگاه کنی. این سؤال‌ها رو بپرس از خودت که: این درخواست با چه Methodی ارسال شده؟ به چه URLای ارسال شده؟ چه Parameterهایی داره؟ آیا Cookie همراه آن وجود داره؟ و Response دقیقاً چه چیزی را برگردونده؟ اینجا یه Request ساده تبدیل به یک مـنــبـع اطلاعاتـی مــهـم می‌شه 😇🔥 •

• حالا تو DevTools، روی یکی از درخواست هایی که دو روز قبل پیدا کردی کلیک کن🎩 وارد قسمت Headers شو. دنبال چهار چیز مشخص بگرد: Request URL Request Method Status Code Request Headers بعد تو همون Request، قسمت Response رو باز کن. چیزی که اینجا می‌بینی، پاسخ سرور به درخواست مرورگرِ. ممکن HTML باشه. ممکن JSON باشه. ممکن هرچیزی باشه... حالا سوال) اگر Request رو می‌بینیم: آیا می‌توانیم بفهمـیم چـه اطـلاعاتـی از طرف کاربر وارد برنامه شده ؟ بله. «هر چیزی که از کاربر وارد برنامه می‌شه، از دید امنیتی ارزش بررسی داره» نکته: این به معنی آسیب‌پذیر بودن اون نیست ❌ برنامه‌ای که ورودی کاربر دریافت می‌کنه، اگه اون ورودی رو به شکل صحیح پردازش کنه، می‌تونه کاملاً امن باشه. مشکل زمانی ایجاد میشه که برنامه به ورودی اعتماد بیش از حد داشـته باشه یا اون رو به شکل ناامن پردازش کنه🤷‍♂ •

• برای امشب هم تماام✋ اونایی که آموزش رو خوندن یا سوالی دارن بپرسن ناشناس جواب بدیم ❤️‍🔥 •