مبانی و مفاهیم اساسی امنیت وب سایت

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

ایجاد یک وب سایت ایمن سخت است، اما بسیار مهم است. ما این پست را نوشته ایم زیرا منابع در مورد این موضوع در اینترنت بسیار نایاب است و به اندازه کافی برای تازه واردان توضیح داده نشده است.

مفاهیم برجسته‌شده در مقاله، باید به شما کمک کند تا اصول مسائل و حملات رایجی را که برنامه‌های کاربردی تحت وب در اینترنت با آن‌ها مواجه می‌شوند و نحوه رفع آن‌ها درک کنید.

جلسات (Sessions) و کوکی ها (Cookies)

صرف نظر از نوع وب سایتی که می سازید، شاید نیاز باشد تا کاربران را برای ارائه خدمات، احراز هویت کنید، در این صورت با کوکی ها و جلسات، نیاز است تا این کار انجام شود.

هر سایت، می تواند درخواست های گوناگونی را از کاربران مختلف دریافت کند. مشکل کلیدی که ما در اینجا سعی در حل آن داریم این است: چگونه وب سرور می داند که کدام کاربر کدام درخواست را ارسال می کند؟

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

مشکل این است که این کار امن نیست چرا که هر مرورگر دیگری (شاید مرورگر دیگری که کاربر قبلا وارد آن شده است) نیز می تواند با این شناسه ها، درخواست احراز هویت کند و امنیت کاربران را به خطر بیندازد.

ما به چیزی موقتی تری نیاز داریم.

توکن‌های جلسه ای (Session Tokens)

به نفع ماست که تا حد امکان اطلاعات کمتری در مورد کاربر به مرورگر بدهیم. بنابراین، به جای بازگرداندن اطلاعات شناسایی در مورد کاربر احراز هویت شده، به جای آن، بخشی از داده ها را با نام «توکن جلسه» برمی گردانیم.

چیزی که این را ایمن می کند این است که هر جلسه با یک توکن جلسه متفاوت همراه است و توکن جلسه به خودی خود، هیچ نشانه ای در مورد هویت کاربر وارد شده نشان نمی دهد.

اکنون هر بار که کاربری به نام علی درخواستی از مرورگر خود ارسال می‌کند، توکن جلسه فعلی خود را همراه با درخواست خود به سمت سرور ارسال می‌کند.

سرور اطلاعات مربوط به کد جلسه را برای هر کدام از کاربران ذخیره می کند. هنگامی که کاربر از سیستم خارج می شود (یا دوباره وارد سیستم می شود)، یا پس از یک دوره زمانی مشخص، یک توکن جلسه جدید برای کاربر تولید و تخصیص می یابد، و توکن قدیمی منقضی می شود.

در تصویر بالا، «مرورگر 2» جایی است که علی قبلا با آن وارد شده است. توکن آن جلسه w344e3 بود که اکنون منقضی شده است. هنگامی که علی از مرورگر 1 خارج می شود، توکن جلسه فعلی او (a23ww2) نیز منقضی می شود.

هیچ راهی برای هیچ شخص ثالثی وجود ندارد که حدس بزند کدام جلسه برای کدام کاربر است، زیرا آن اطلاعات به طور ایمن در سرور ذخیره می‌شود و در اختیار عموم قرار ندارد.

مشکل اکنون این است: کاربر همیشه باید رمز جلسه خود را با هر درخواستی که ارسال می کند ذکر کند.

این بدان معنی است که هر کسی که کد سمت کلاینت را توسعه می دهد باید مطمئن شود که کوکی جلسه را با هر درخواستی، ضمیمه درخواست خود کند. خوشبختانه، مرورگرها یک روش داخلی برای ضمیمه کردن این اطلاعات با هر درخواست کاربر دارند:

کوکی‌های جلسه ای

به طور خلاصه، کوکی قطعه کوچکی از داده است که در مرورگر کاربر نگهداری می شود، که (در صورتی که درخواست از همان دامنه باشد) با هر درخواست به طور خودکار به سرور ارسال می شود.

در مثال ما، کوکی با مقدار توکن جلسه تنظیم پر می‌شود (زیرا این تمام چیزی است که سرور واقعا به آن نیاز دارد). تبادل بین مرورگر و سرور مانند قبل خواهد بود، با این تفاوت که درخواست مرورگر هر بار حاوی توکن جلسه نیز است.

علاوه بر راحتی، کوکی ها را می توان با ویژگی های اضافی نیز پیکربندی کرد، مانند:

• 1. زمان انقضا - کوکی ها را می توان به طور خودکار پس از یک دوره زمانی مشخص حذف کرد.
  
  
• 2. قابلیت مشاهده با جاوا اسکریپت - می توانید تصمیم بگیرید که آیا کوکی از روی کد جاوا اسکریپت در حال اجرا در صفحه وب قابل مشاهده باشد یا خیر
  
  
• 3. دید متقابل سایت (Cross site visibility) - کوکی‌ها را می‌توان محدود کرد تا فقط به دامنه‌ای که توسط آن ایجاد شده‌اند ارسال شوند.

اگر می‌خواهید کوکی‌هایی را که در حال حاضر برای وب‌سایت فعلی که بازدید می‌کنید (مانند همین سایت نویا سیستم) ذخیره شده است را ببینید، در هر نقطه از صفحه، کلیک راست کرده و بر روی «Inspection» کلیک کنید تا ابزارهای توسعه‌دهنده مرورگر باز شود (اگر در کروم هستید). سپس به تب Program بروید و روی قسمت کوکی ها در زیر آن کلیک کنید.

ذخیره رمز عبور

ذخیره گذرواژه کاربران شما یک مسئولیت بزرگ در برنامه های تحت وب است. اگر این کار را به درستی انجام ندهید، می توانید کل برنامه خود را به راحتی به خطر اندازید.

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

ذخیره‌سازی به صورت متن ساده

اولین سوالی که بسیاری از تازه واردان می پرسند این است: چرا نباید رمز عبور را مانند هر داده دیگری ذخیره کنم؟

برای پاسخ به این سوال، یک جدول پایگاه داده حاوی ستون های نام کاربری و رمز عبور را در نظر بگیرید که پسوردهای آن به صورت زیر ذخیره شده اند:

اشکال این روش: ذخیره رمز به این صورت، بسیار ناامن است. هر چیز ساده ای نظیر باز نگه داشتن لپ تاپ توسط مدیر سیستم به اشتباه، می تواند منجر به به خطر افتادن رمز عبور کاربران شما شود.

رمزگذاری

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

به عنوان مثال، اجازه دهید هر حرف رمز عبور را با حرف بعدی آن در جدول الفبا جایگزین کنیم.

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

اشکال این روش: هنوز کسانی وجود دارند که از رمزهای عبور در سیستم می توانند مطلع شوند. در مورد مثال ما، ما می دانیم که رمز عبور با افزایش هر حرف به حرف بعدی خود در جدول الفبا، تشکیل می شود، بنابراین بازیابی رمز عبور کاربران برای ما، کاملا امکان پذیر است.

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

هشینگ (Hashing) یک طرفه

به جای استفاده از یک الگوریتم رمزگذاری برگشت پذیر، می توانید از یک الگوریتم هش ثابت مانند md5 یا sha-1 استفاده کنید. این الگوریتم های هش را نمی توان در تئوری معکوس کرد.

این بدان معناست که فقط به این دلیل که هش md5 یک کلمه را می‌دانیم، به این معنی نیست که اگر فقط هش md5 آن را داشته باشیم، می‌توانیم بفهمیم آن کلمه چیست.

بیایید جدول خود را اصلاح کنیم تا هش md5 رمز عبور را شامل شود.

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

اشکال این روش: خیلی زود متوجه خواهید شد که کاربران، بیشتر از آنچه فکر می کنید شبیه هم هستند، و در نتیجه، رمزهای عبور زیادی پیدا خواهید کرد که فقط کلمات و عبارات رایج هستند. بسیاری از وب سایت ها مانند این، جداول جستجوی هش های md5 از کلمات رایج را دارند. این به این معنی است که اگر کاربر شما یک کلمه معمولی را به عنوان رمز عبور خود تنظیم کند، می توان آن را به راحتی جستجو و کرک کرد.

برای اثبات چیزی که می گوییم، در اینجا چند هش md5 از کلمات رایج آورده شده است:

• ali123: 8cbd191432b5f52b48497313f966a4f8
  
  
• admin: d077f244def8a70e5ea758bd8352fcd8
  
  
• good: 3a385ac07dcec4dde1a4ca47a9802c96

هکرها پس از دسترسی به دیتابیس، به دنبال رمزهای رایج هش شده می گردند و به رمز عبور بسیاری از کاربران، دسترسی پیدا خواهند کرد.

هشینگ یک طرفه همراه با نمک (Salt)

ما می دانیم که جداول جستجو برای کلمات رایج وجود دارد که به هکرها کمک می کند رمزهای رایج را در md5 پیدا کنند، و همچنین می دانیم که نمی توانیم به کاربران خود اعتماد کنیم که از کلمات رایج استفاده نکنند.

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

Salting به معنای اضافه کردن یک رشته تصادفی از حروف و اعداد به رمز عبور کاربران و سپس هش کردن آن است. این کم و بیش تضمین می کند که کلمه منحصر به فرد است و بنابراین نمی تواند توسط هکرها، از جداول پیش فرض، جستجو و پیدا شود.

خروجی نهایی که مشاهده می کنید دارای دو نماد $ است که نمک استفاده شده برای تولید بقیه هش، بین آنها قرار دارد. این برای این است که بتوانیم این هش را با رمز عبور وارد شده توسط کاربر مقایسه کنیم.

اگر کاربر در هنگام ورود، رمز عبور خود را وارد کند، می‌توانیم آن را با دنبال کردن مراحل زیر تأیید و لاگین کنیم:

• 1. رمز عبور هش شده همراه با نمک را از دیتابیس بخوانید
  
  
• 2. نمک را از داده های ذخیره شده (بخش بین نمادهای $) بخوانید
  
  
• 3. نمک را به پسورد وارد شده کاربر اضافه کنید و نتیجه را هش کنید
  
  
• 4. خروجی این هش را با قسمت سمت راست دومین نماد $ مقایسه کنید

اکنون یک فرمت امن برای ذخیره رمزهای عبور دارید. و اکنون هیچ کس، حتی شما، هرگز نمی توانید رمز عبور کاربران خود را پیدا کنید.

روش بعدی یک نسخه تکراری از هش کردن و نمک زدن است:

هش کردن مکرر

به یاد دارید که در روش شماره 4 چه کردیم؟ حالا، نتیجه را بگیرید، روش شماره 4 را روی آن مجددا اجرا کنید... حالا آن نتیجه را بگیرید و روش شماره 4 را دوباره و دوباره روی آن اجرا کنید.

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

مراحل مقایسه دو رمز عبور شامل هش مکرر رمز عبور وارد شده به تعداد یکسان و مقایسه نتیجه با هش ذخیره شده است.

پیاده سازی عملی ذخیره کردن رمز عبور امن

ضرب المثلی عاقلانه وجود دارد که می گوید اکثر مردم هرگز نباید خودشان الگوریتم های رمزگذاری را پیاده سازی کنند. در صورت ایراد یا اشتباه، نتایج، فاجعه بار خواهد بود. الگوریتم‌های زیادی وجود دارد که می‌توانند هش و نمک‌سازی را برای شما پیاده‌سازی کنند.

Bcrypt نمونه خوبی از چنین الگوریتمی است. همچنین دارای پیاده سازی و کتابخانه ای برای اکثر زبان های برنامه نویسی است.

اسکریپت متقابل سایت Cross Site Scripting (XSS)

حملات XSS یکی از رایج ترین انواع حملات است و اغلب نقطه شروع بسیاری از مهاجمانی است که به دنبال به خطر انداختن وب سایت شما هستند.

بهترین راه برای توضیح XSS این است که مستقیما با یک مثال شروع کنیم. کد HTML زیر را در نظر بگیرید:

<div id="status"> I am feeling alright </div>

بیایید فرض کنیم این div برای نشان دادن وضعیت شما در یک سایت شبکه اجتماعی محبوب استفاده می شود. این وضعیت، توسط بسیاری از دوستان شما در فید خبری آنها دیده می شود و به صورت احساس خوبی دارم دیده می شود.

به عنوان یک کاربر، می توانید وضعیت خود را به هر چیزی که می خواهید به روز کنید و این وضعیت، در داخل این عنصر div ظاهر می شود. اگر هکر باشید، می‌توانید وضعیت خود را از من احساس خوبی دارم به <script>alert(\"من احساس خوبی دارم!\")</script> تغییر دهید.

با این حال، دوستان شما وضعیت شما را به عنوان "\<script>alert('من احساس خوبی دارم!')</script>\" نمی بینند، اما در عوض، یک پیام هشدار دریافت می کنند که چیزی شبیه به این است:

این به این دلیل است که متنی که شما وارد کرده اید به طور پیش فرض در HTML ارائه می شود، که محتوای داخل div را به شکل زیر در می آورد:

<div id="status"> <script> alert('I am feeling great!') </script> </div>

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

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

جلوگیری از XSS

اطمینان حاصل کنید که تمام اطلاعاتی که به مرورگر تحویل داده می شوند منحصرا کد HTML هستند. این بدان معنی است که ابتدا باید برخی از کاراکترهای خاص را به معادل های کدگذاری شده HTML خود تبدیل کنید.

راه‌های مختلفی برای پیاده‌سازی رمزگذاری کاراکترهای HTML وجود دارد، و بسیاری از فریم‌ورک‌های محبوب وب از این موضوع پشتیبانی می‌کنند.

جعل درخواست متقابل سایت Cross Site Request Forgery (CSRF)

جعل درخواست متقابل سایت (CSRF یا XSRF)، نوعی حمله است که در آن درخواستی که از یک وب‌سایت می‌آید پنهان می‌شود تا این تصور ایجاد شود که از وب‌سایت دیگری می‌آید. این حمله می تواند بسیار مرگبار باشد چرا که می تواند در نخستین زمان های حمله، توسط کاربران و حتی سرور مورد هدف غیر قابل تشخیص باشد.

این بخش ما توضیح خواهیم داد که چه چیزی باعث حملات CSRF می‌شود و برای جلوگیری از آنها به عنوان یک توسعه‌دهنده چه کاری می‌توانید انجام دهید.

CSRF دقیقا چیست؟ نام این حمله از دو بخش اساسی تشکیل شده است:

• جعل درخواست Request forgery : ارسال درخواستی که ظاهرا قانونی است اما در واقع مخرب است.
  
  
• از ساتی دیگر Cross site: از سایتی غیر از سایتی که برای آن در نظر گرفته شده است.

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

دو وب‌سایت را به عنوان مثال در نظر بگیرید: یک وب‌سایت خبری نه چندان بی‌گناه (اجازه دهید آن را sillyfakenews.com بنامیم)، و پورتال رسانه‌های اجتماعی شما (اجازه دهید آن را facehook.com بنامیم).

فرض کنید قبلا در یک برگه دیگر در مرورگر خود به facehook.com وارد شده اید. یکی از بسیاری از پست‌هایی که در آن مشاهده می‌کنید شامل پیوندی به sillyfakenews.com است، و از آنجایی که جالب به نظر می‌رسد، و در حالی که هنوز وارد فیس‌هوک هستید، آن را در برگه دیگری باز می‌کنید.

به نظر می رسد که sillyfakenews.com در کنار نمایش اخبار، سعی دارد حساب فیس هوک شما را نیز هک کند و به خطر بیندازد. این سایت خبری جعلی، یک درخواست POST برای facehook می فرستد تا چند نفر از لیست دوستان شما را از آنفالو کند (این کار را می توان به راحتی با استفاده از فرم های HTML و کمی جاوا اسکریپت انجام داد.

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

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

مرورگرها طوری طراحی شده اند که هر درخواستی که از هر سایتی ارسال می شود را با توجه به کوکی ها پردازش و ارسال می کنند. به همین دلیل است که حتی اگر درخواست facehook از sillyfakenews.com ارسال می شود، تمام کوکی های مرتبط با جلسه فعلی وارد شده در facehook.com نیز ارسال می شوند.

جلوگیری از CSRF

چند اقدام وجود دارد که می توانید برای اطمینان از اینکه این حملات روی کاربران سایت شما انجام نمی شود، انجام دهید.

ساده ترین روش مسدود کردن درخواست های HTTP است که از سایر وب سایت ها در مرورگر ارسال می شود. اکثر مرورگرهای محبوب به «خط مشی مبدا یکسان» یا «same origin policy» احترام می‌گذارند، جایی که به‌طور پیش‌فرض (یا اگر سرور آن را مشخص کند) درخواست‌هایی که از مبدأ دیگری به غیر از منبعی که سایت فعلی از آن ارسال می‌شود، توسط مرورگر ارسال نمی‌شود.

از آنجایی که این چیزی است که مرورگر به آن احترام می‌گذارد، اگر کاربر ما از مرورگری استفاده می‌کند که same origin policy را پشتیبانی نمی‌کند، CSRF همچنان یک نگرانی امنیتی خواهد بود. برای این حالات می توانیم اقدامات دیگری انجام دهیم:

توکن های CSRF

این محبوب ترین روش برای مقابله با حملات CSRF است. با هر جلسه ای که کاربر در آن است، یک توکن CSRF منحصر به فرد تولید می شود. این توکن مجموعه ای از کاراکترهای تصادفی است که توسط هیچ دشمن احتمالی قابل پیش بینی نیست.

هر بار که مشتری درخواستی می دهد، توکن CSRF در یکی از فیلدهای پاسخ (بیشتر اوقات در هدر درخواست) تعبیه می شود. سپس این توکن روی سرور تأیید می شود.

به این ترتیب، حتی اگر سایت دیگری درخواست مخربی را همراه با کوکی‌ها از facehook.com ارسال کند، درخواست همچنان حاوی توکن CSRF نخواهد بود و به این ترتیب توسط سرور پذیرفته نمی‌شود.

تزریق SQL یا SQL Injection

پایگاه های داده مدرن دارای ویژگی های امنیتی زیادی هستند تا از به خطر افتادن آنها توسط یک مهاجم جلوگیری کنند. با این حال، حتی با امن ترین پایگاه های داده، هنوز راهی برای به خطر انداختن آن از طریق مرورگر وجود دارد!

این بخش توضیح می دهد که چرا تزریق SQL رخ می دهد و چگونه می توانید از آن جلوگیری کنید.

فرض کنید یک فرم ساده در وب سایت شما برای ثبت نام کاربر جدید وجود دارد.

اکنون به محض ثبت نام یک کاربر جدید، باید یک ورودی جدید در پایگاه داده ایجاد کنید.

در سمت بک اند، کوئری پایگاه داده چیزی شبیه به این خواهد بود:

INSERT INTO `users` (username, password) VALUES ('<username>', '<password>');

کاری که اکنون انجام می دهید این است که <username> و <password> را با مقادیر وارد شده در فرم ثبت نام ما جایگزین کنید. بنابراین، اگر نام کاربری خود را به عنوان John Doe و رمز عبور خود را به عنوان j0hnd03 وارد کنیم، درخواست ثبت نام ما اینگونه خواهد بود:

INSERT INTO `users` (username, password) VALUES ('John Doe', 'j0hnd03');

به طور معمول، این به خوبی کار می کند. اما اگر نام کاربری خود را به شکل زیر تغییر دهیم چه اتفاقی می افتد؟

',');DROP TABLE `users`;--

هنگامی که این نام کاربری را وارد می کنیم، کوئری به صورت زیر در خواهد آمد:

INSERT INTO `users` (username, password) VALUES (',');DROP TABLE `users`;--', '<password>');

بیایید آنچه را که در اینجا اتفاق افتاد شرح دهیم: معلوم شد که این کوئری حاوی کاراکترهای خاصی مانند `, " یا - است.

از آنجایی که ما ساده لوحانه نام کاربری و رمز عبور وارد شده را برای ساخت کوئری به هم متصل می کنیم، دقیقا راهی نداریم که به درخواست خود بگوییم که این کاراکترهای خاص باید بخشی از نام کاربری باشند و نه بخشی از کوئری.

نتیجه همانطور که انتظار می رفت فاجعه بار است. در این مورد، منجر به حذف کل جدول کاربران ما خواهد شد.

جلوگیری از تزریق SQL

مطمئن شوید که همیشه کاراکترهای خاص تمام کوئری های SQL خود با نسخه فرار شده (escape) آنها جایگزین می کنید. این به معنای جایگزینی کاراکترهای خاص مانند `، " با نسخه های فرار شده آنها (یعنی \` و < span style='background-color:#eef;padding:2px;border-radius:2px;>\" است)

گفتن این کار در واقع آسان تر از انجام آن است، با توجه به اینکه پروژه های بزرگتر اغلب دارای صدها کوئری با پارامترهای حتی بیشتر برای انجام کارها هستند، و اغلب غیرممکن است که مطمئن شوید همه چیز به درستی انجام شده است. راه حل چیست؟

به جای نوشتن پرس و جوهای خود از یک ORM استفاده کنید. ORMهایی مانند این مورد برای پایتون یا این مورد برای NodeJs مطمئن می شوند که کوئری های شما ایمن هستند، حتی اگر تعداد زیادی کاراکتر مشکوک در پارامترهای ورودی خود داشته باشید.

اشتراک گذاری منابع متقاطع Cross Origin Resource Sharing (CORS)

CORS یا اشتراک‌گذاری منابع متقاطع، یکی از غیر قابل فهم ترین مفاهیم امنیت وب است. بسیاری می دانند که چیست، برخی دیگر نیز می دانند که چرا ما به آن نیاز داریم، و تنها تعداد کمی با محدودیت های آن آشنا هستند.

این بخش برخی از مفاهیم کلیدی CORS را بررسی می کند و تاکید می کند که چرا ما به آن برای وب مدرن نیاز داریم.

بهترین راه برای توضیح آن از طریق یک مثال است.

ابتدا مرورگر خود را باز کرده و به stackoverflow.com بروید.

سپس کنسول مرورگر خود را باز کنید و این قطعه را اجرا کنید:

fetch('http://stackoverflow.com').then(res => console.log(res))

در این لحظه پاسخی تمیز و به خوبی برگشت داده شده ای را از سمت سرور می بینید، چیزی شبیه به این:

هنگام اجرای کد جاوا اسکریپت مثال فوق، ما از دستور fetch مرورگر برای دریافت محتوای صفحه وب StackOverflow با درخواست http استفاده کردیم. اکنون، اجازه دهید به جای آن، صفحه اصلی ویکی پدیا را دریافت کنیم:

به نظر می‌رسد که ما مجاز به دریافت جزئیات صفحه اصلی ویکی‌پدیا نیستیم.

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

به بیان ساده، ارسال درخواست به هر منبعی، غیر از منبعی که کد شما در آن اجرا می شود، ممنوع است، مگر اینکه سرور به آن اجازه دهد. به این می گویند همان سیاست مبدا.

تقریبا همه نشانی‌های اینترنتی که منابع خود را ارائه می‌کنند دارای یک خط مشی CORS هستند. به طور پیش فرض، اگر خط مشی وجود نداشته باشد، فرض می شود که CORS غیرفعال است.

ممکن است بپرسید چرا؟ ممکن است فکر کنید اجازه دادن درخواست ها به مبدأ دیگر، کاری بی ضرر است. ممکن است فکر کنید اگر اجازه آن داده شود، آن آدرس اینترنتی می تواند میلیون‌ها درخواست دیگر را از منابع ناشناس دریافت کند و خطری نیز او را تهدید نمی کند. پاسخ در نحوه کار مرورگرها نهفته است.

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

این به این معنی است که اگر در یک سایت وارد شده باشید و در حال مرور یک سایت دیگر باشید، یک درخواست http توسط آن سایت ها به سایت اول، می تواند به عنوان یک درخواست واقعی از شما تلقی می شود.

این به این معنی است که:

می تواند به این تبدیل شود:

اجرای خط مشی CORS (CORS Policy Enforcement)

CORS Policy Enforcement اغلب غیر قابل فهم ترین جنبه CORS است. کاملا گیج کننده است که چرا یک نفر نمی تواند یک درخواست http ساده از مرورگر خود به منبع دیگری ارسال کند، اما می تواند همان درخواست را با استفاده از چیزی مانند postman یا curl از خط فرمان انجام دهد.

اگر این نوع درخواست ها را نمی توان از مرورگر انجام داد، چگونه به راحتی از طریق این برنامه های شخص ثالث که می توانند به همان اندازه مخرب باشند، انجام شوند؟

CORS در واقع توسط سرور اعمال نمی شود، بلکه توسط مرورگر اجرا می شود. سرور به سادگی اجازه دسترسی متقاطع به سایت هایی را که در هدر خود Access-Control-Allow-Origin را در تمام پاسخ های خود دارند، می دهد. رعایت این سیاست بر عهده مرورگر است.

البته، همه مرورگرهای محبوبی که امروزه مورد استفاده قرار می‌گیرند، از سیاست مبدأ پیروی می‌کنند. برخی از برنامه‌ها مانند postman، curl به این خط‌مشی احترام نمی‌گذارند، زیرا قرار است به عنوان ابزار توسعه‌دهنده استفاده شوند.

اخطارها و استثناها

1. fetch می‌تواند درخواست‌های متقاطع ایجاد کند: یک حالت no-cors وجود دارد که می‌توان از آن برای ایجاد درخواست‌های متقاطع با getch استفاده کرد، مانند این: code 7 با این حال، به دلایل قبلی نمی‌توانید این پاسخ را بخوانید. این فقط در صورتی مفید است که بخواهید کارهایی مانند ارسال پاسخ را انجام دهید.

2. CORS می تواند سختگیرتر از حد معمول باشد: مسخره بازی اشاره شده در بالا همیشه درست کار نخواهد کرد. اگر سرور واقعا نمی‌خواهد سایر کلاینت‌ها پاسخی دریافت کنند، می‌تواند CORS را برای مشتریان غیر مرورگر نیز غیرفعال کند. این بدان معناست که شما فقط می‌توانید درخواست‌هایی را از همان مبدأ ارسال کنید، و ابزارهایی مانند postman و curl نیز نمی‌توانند درخواست ارسال کنند.

خلاصه و کلام پایانی

ما به چندین نوع حمله متداول و اقدامات برای جلوگیری از آنها نگاه کردیم.

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