دفاع در مقابل آسیب پذیری CSRF


5/5 - (1 امتیاز)

حالا که آشنایی کامل با آسیب پذیری CSRF پیدا کردیم وقتش هست که راجب CSRF Prevent صحبت کنیم.

به طور خلاصه، ما باید اصول زیر را برای دفاع در برابر CSRF رعایت کنیم:

  • بررسی کنید که آیا Framework شما دارای محافظ CSRF داخلی است یا خیر و از آن استفاده کنید.
    • اگر Framework دارای محافظت داخلی CSRF نباشد، Token های CSRF را به همه Request های تغییر وضعیت (درخواست‌هایی که باعث Action در سایت می‌ شوند) اضافه کنید و آنها را در Back-End تأیید کنید.
  • برای نرم افزار های Stateful از Synchronizer Token Pattern استفاده کنید.
  • برای نرم افزار های Stateless، از Double Submit Cookie ها استفاده کنید.
  • حداقل یک Mitigation (کاهش حملات) از بخش Defense in Depth Mitigations را پیاده سازی کنید.
    • SameSite Cookie Attribute را برای Session Cookie ها در نظر بگیرید، اما مراقب باشید که Cookie ها را به‌طور خاص برای دامنه تنظیم نکنید، زیرا باعث ایجاد یک آسیب‌ پذیری امنیتی می‌ شود که همه زیر دامنه‌ های آن دامنه، Cookie را به اشتراک می‌ گذارند. این موضوع به ویژه زمانی که یک زیر دامنه دارای CNAME برای دامنه هایی است که تحت کنترل شما نیستند، مشکل ایجاد می کند.
    • اجرای حفاظت User Interaction Based CSRF را برای عملیات بسیار حساس در نظر بگیرید
    • استفاده از Header های Request سفارشی را در نظر بگیرید
    • بررسی Origin با Header های استاندارد را در نظر بگیرید
  • به یاد داشته باشید که هر XSS را می توان برای شکست تمام تکنیک های کاهش Mitigations CSRF استفاده کرد!
  • از Request های GET برای عملیات تغییر حالت استفاده نکنید.
    • اگر به هر دلیلی این کار را انجام دادید، از آن Resource ها در برابر CSRF محافظت کنید

Token Based Mitigation:

Token Based Mitigation یکی از محبوب‌ ترین و توصیه‌ شده‌ ترین روش‌ ها برای کاهش CSRF است.

استفاده از پیاده سازی های داخلی یا موجود CSRF برای محافظت CSRF:

دفاع Synchronizer Token در بسیاری از Framework ها ساخته شده است. اکیداً توصیه می‌ شود قبل از ساختن سیستم تولید Token سفارشی، در مورد اینکه آیا Framework که استفاده می‌ کنید به طور پیش‌ فرض تنظیماتی برای دستیابی به حفاظت CSRF دارد یا خیر، تحقیق کنید. به عنوان مثال، NET. دارای حفاظت داخلی است که یک Token به Resource های آسیب پذیر CSRF اضافه می کند. ما مسئول پیکربندی مناسب (مانند مدیریت Key و مدیریت Token) قبل از استفاده از این محافظ‌ های داخلی CSRF که Token هایی را برای محافظت از Resource های آسیب‌ پذیر CSRF تولید می‌ کنند، هستیم.

Synchronizer Token Pattern:

Token های CSRF باید در سمت سرور تولید شوند. آنها را می توان یک بار در هر Session کاربر یا برای هر Request ایجاد کرد. Token های هر Request از Token های هر Session ایمن‌ تر هستند، زیرا محدوده زمانی مهاجم برای سوء استفاده از Token های دزدیده شده بسیار کم است. با این حال، ممکن است منجر به نگرانی در مورد استفاده شود. به عنوان مثال، قابلیت دکمه “بازگشت” مرورگر اغلب مانع می شود زیرا صفحه قبلی ممکن است حاوی رمزی باشد که دیگر معتبر نیست. تعامل با این صفحه قبلی منجر به یک رویداد امنیتی False Positive در سرور می شود. در اجرای Token هر Session پس از تولید اولیه Token ، مقدار در Session ذخیره می شود و برای هر Request بعدی تا پایان Session استفاده می شود.

هنگامی که یک Request توسط Client صادر می شود، Component سمت سرور باید وجود و اعتبار Token در Request را در مقایسه با Token موجود در Session کاربر تأیید کند. اگر Token در Request یافت نشد، یا مقدار ارائه شده با مقدار در Session کاربر مطابقت نداشت، Request باید لغو شود. اقدامات اضافی مانند ثبت رویداد به عنوان یک حمله CSRF در حال انجام نیز باید در نظر گرفته شود.

Token های CSRF باید دارای پارامتر های زیر باشند:

  • منحصر به فرد در هر Session کاربر.
  • Secret
  • غیر قابل پیش بینی (مقدار تصادفی بزرگ توسط یک روش امن).

Token های CSRF از CSRF جلوگیری می‌ کنند زیرا بدون Token، مهاجم نمی‌ تواند Request های معتبری برای سرور Back-End ایجاد کند.

Token های CSRF نباید با استفاده از Cookie ها منتقل شوند.

Token مربوط به CSRF را می توان از طریق فیلد های مخفی، Header ها اضافه کرد و با فرم ها و فراخوانی های AJAX استفاده کرد. مطمئن شوید که Token در لاگ های سرور یا در URL لو نرود. Token های CSRF در Request های GET به طور قابل توجهی در مکان‌ های مختلفی مانند تاریخچه مرورگر، فایل‌ های لاگ ، ابزارهای شبکه که خط اول HTTP Request را لاگ می‌ کنند و اگر سایت محافظت‌ شده به یک سایت خارجی پیوند داده شود، Referer Header ها به لو میروند.

<form action=”/transfer.php” method=”post”>
<input type=”hidden” name=”CSRFToken” value=”OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2JmNGYxYjJiMGI4MjJjZDE1ZDZMGYwMGEwOA==”>
[…]
</form>

قرار دادن Token مربوط به CSRF در Header مربوط به HTTP Request سفارشی از طریق Java Script امن تر از افزودن Token در پارامتر فرم فیلد پنهان است زیرا از Request Headrer های سفارشی استفاده می کند.

Double Submit Cookie:

اگر حفظ وضعیت CSRF Token در سمت سرور مشکل ساز است، یک دفاع جایگزین استفاده از تکنیک Double Submit Cookie است. اجرای این تکنیک آسان است و Stateless است. در این تکنیک، ما یک مقدار تصادفی را هم در یک Cookie و هم به عنوان پارامتر Request ارسال می‌ کنیم و سرور تأیید می‌ کند که آیا مقدار Cookie و مقدار Request مطابقت دارند یا خیر. هنگامی که یک کاربر بازدید می کند (حتی قبل از احراز هویت برای جلوگیری از Login CSRF)، سایت باید یک مقدار تصادفی (از لحاظ رمزنگاری قوی) ایجاد کند و آن را به عنوان یک Cookie در دستگاه کاربر جدا از Session Identifier تنظیم کند. سپس سایت لازم است که هر Transaction Request این مقدار تصادفی را به عنوان یک مقدار فرم پنهان (یا پارامتر/Header درخواست دیگر) داشته باشد. اگر هر دوی آنها در سمت سرور مطابقت داشته باشند، سرور آن را به عنوان Request قانونی می پذیرد و اگر اینطور نباشد، درخواست را رد می کند.

برای افزایش امنیت این راه حل، رمز را در یک Cookie رمزگذاری شده قرار دهید – به غیر از Cookie احراز هویت (از آنجایی که آنها اغلب در SubDomian ها به اشتراک گذاشته می شوند) – و سپس در سمت سرور، آن را (پس از رمزگشایی کوکی رمزگذاری شده) با Token در فرم فیلد مخفی یا پارامتر/Headrer برای تماس های AJAX مطابقت دهید. این عمل به این دلیل کار می‌ کند که یک Sub Domain راهی برای بازنویسی یک Cookie رمزگذاری شده که به درستی ساخته شده است بدون اطلاعات لازم مانند کلید رمزگذاری ندارد.

یک جایگزین ساده تر برای کوکی Cookie رمزگذاری شده این است که رمز را با یک کلید مخفی که فقط سرور می شناسد HMAC کنید و این مقدار را در یک Cookie قرار دهید. این شبیه به یک Cookie رمزگذاری شده است (هر دو نیاز به دانشی دارند که فقط سرور در اختیار دارد)، اما از نظر محاسباتی کمتر از رمزگذاری و رمزگشایی کوکی است. چه از رمزگذاری و چه از HMAC استفاده شود، مهاجم بدون اطلاع از اسرار سرور نمی‌ تواند مقدار Cookie را از Token ساده ایجاد کند.

Defense In Depth Techniques:

ویژگی های SameSite Cookie:

SameSite یک ویژگی Cookie است (مشابه HTTPOnly، Secure و …) که هدف آن کاهش حملات CSRF میباشد که در RFC6265bis تعریف شده است. این ویژگی به مرورگر کمک می کند تصمیم بگیرد که آیا Cookie ها را همراه با Cross-Site Request ها ارسال کند یا خیر. مقادیر ممکن برای این ویژگی عبارتند از Lax، Strict یا None.

مقدار Strict از ارسال Cookie توسط مرورگر به سایت مورد نظر در تمام زمینه های Cross-Site Browsing، حتی زمانی که یک پیوند معمولی را دنبال می کنید، جلوگیری می کند. برای مثال، برای یک وب‌ سایت شبیه به GitHub، این بدان معناست که اگر یک کاربر Logged-In پیوندی را به یک پروژه GitHub خصوصی ارسال شده در یک انجمن گفتگو یا ایمیل شرکتی دنبال کند، GitHub دیگر Session Cookie را دریافت نخواهد کرد و کاربر قادر به دسترسی به پروژه نخواهد بود. با این حال، یک وب‌ سایت بانکی نمی‌ خواهد اجازه دهد هیچ صفحه تراکنشی از سایت‌ های خارجی پیوند داده شود، بنابراین Strict Flag مناسب‌ ترین است.

مقدار Lax پیش‌ فرض تعادل معقولی بین امنیت و قابلیت استفاده برای وب‌ سایت‌ هایی فراهم می‌ کند که می‌ خواهند پس از ورود کاربر از یک پیوند خارجی، Session ورود کاربر را حفظ کنید. در سناریوی GitHub فوق، Session Cookie هنگام دنبال کردن یک پیوند معمولی از یک وب سایت خارجی در حالی که آن را در روش های Request مستعد CSRF مانند POST مسدود می کند مجاز است. فقط Cross-Site-Request هایی که در حالت Lax مجاز هستند، آنهایی هستند که ناوبری سطح بالایی دارند و همچنین روش‌ های HTTP ایمن هستند.

برای جزئیات بیشتر در مورد مقادیر SameSite، بخش زیر را از rfc بررسی کنید.

نمونه ای از Cookie ها با استفاده از این ویژگی:

Set-Cookie: JSESSIONID=xxxxx; SameSite=Strict
Set-Cookie: JSESSIONID=xxxxx; SameSite=Lax

همه مرورگرهای دسکتاپ و تقریباً همه مرورگر های تلفن همراه اکنون از ویژگی SameSite پشتیبانی می کنند. توجه داشته باشید که Chrome اعلام کرده است که Cookie ها را به‌طور پیش‌ فرض از Chrome 80 به‌ عنوان SameSite=Lax علامت‌ گذاری می‌ کنند و فایرفاکس و Edge هر دو در حال برنامه‌ ریزی هستند. علاوه بر این، برای Cookie هایی که به عنوان SameSite=None علامت گذاری شده اند، Secure Flag مورد نیاز خواهد بود.

توجه به این نکته مهم است که این ویژگی باید به عنوان یک لایه دفاعی اضافی در مفهوم عمقی پیاده سازی شود. این ویژگی از طریق مرورگر های پشتیبانی کننده از کاربر محافظت می کند و همچنین دارای 2 راه برای دور زدن آن است که در بخش زیر ذکر شد. این ویژگی نباید جایگزین داشتن یک توکن CSRF شود. در عوض، باید با آن Token همراه باشد تا از کاربر به روشی قوی‌ تر محافظت شود.

Verifying Origin With Standard Headers:

دو مرحله برای این کاهش وجود دارد که هر دو به بررسی مقدار HTTP Request Header متکی هستند.

  1. تعیین مبدا Request از آن (Source Origin). از طریق Header های Origin یا Referer قابل انجام است.
  2. تعیین مبدا Request (Target Origin).

در سمت سرور، بررسی می کنیم که آیا هر دوی آنها مطابقت دارند یا خیر. اگر این کار را انجام دهند، ما Request را قانونی می‌ پذیریم (یعنی همان Origin Request است) و اگر نپذیرند، Request را رد می‌کنیم (به این معنی که Request از Cross-Domain منشا گرفته است). قابلیت اطمینان در این Header ها از این واقعیت ناشی می شود که نمی توان آنها را از نظر برنامه ریزی تغییر داد زیرا در لیست Header های ممنوعه قرار می گیرند، به این معنی که فقط مرورگر می تواند آنها را تنظیم کند.

Identifying Source Origin (via Origin/Referer header)

CHECKING THE ORIGIN HEADER

اگر Origin Header وجود دارد، بررسی کنید که مقدار آن با Target Origin مطابقت دارد. برخلاف Referer، باید بگیم که Origin Header در HTTP Request هایی که از URL HTTPS نشات می‌ گیرند وجود دارد.

CHECKING THE REFERER HEADER

اگر Origin Header وجود ندارد، بررسی کنید که نام Host در Referer Header با Target Origin مطابقت داشته باشد. همچنین این روش CSRF Mitigation معمولاً با Request های احراز هویت نشده، مانند Request هایی که قبل از ایجاد وضعیت Session ارائه شده‌ اند، استفاده می‌ شود، که برای پیگیری یک Synchronization Token لازم است.

در هر دو مورد، مطمئن شوید که بررسی Target Origin به درستس تمام انجام شده باشد. به عنوان مثال، سایت ما NewsSec.IR است، باید مطمئن شویم که NewsSec.IR.attacker.com بررسی Origin ما را تأیید نمی کند (یعنی مطابقت از طریق Trailing / بعد از Origin برای اطمینان از مطابقت با کل Origin).

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

Identifying the Target Origin

ممکن است فکر کنید تعیین Target Origin آسان است، اما اغلب اینطور نیست. اولین فکر این است که به سادگی Origin هدف (یعنی نام Host و شماره Port آن) را از URL موجود در Request بگیرید. با این حال، Application Server اغلب پشت یک یا چند Proxy قرار می‌گیرد و URL اصلی با نشانی اینترنتی که Application Server دریافت می‌ کند متفاوت است. اگر کاربران به Application Server شما مستقیماً دسترسی دارند، استفاده از Origin در URL خوب است.

اگر پشت Proxy هستید، تعدادی گزینه برای بررسی وجود دارد.

برنامه خود را به گونه ای پیکربندی کنید که به سادگی Target Origin آن را بدانید: این برنامه شماست، بنابراین می توانید Target Origin آن را پیدا کرده و آن مقدار را در برخی از ورودی های پیکربندی سرور تنظیم کنید. این ایمن ترین رویکرد به عنوان Server-Side تعریف شده است، با این حال، اگر برنامه شما در بسیاری از مکان‌ ها، به عنوان مثال، dev، test، QA، تولید و احتمالاً چندین نمونه تولید مستقر شده باشد، ممکن است حفظ آن مشکل ساز باشد. تنظیم مقدار صحیح برای هر یک از این موقعیت‌ ها ممکن است دشوار باشد، اما اگر بتوانید آن را از طریق پیکربندی مرکزی انجام دهید و نمونه‌ های خود را برای گرفتن مقدار از آن ارائه دهید، عالی است! (توجه: مطمئن شوید که ذخیره پیکربندی متمرکز ایمن نگهداری می شود زیرا بخش عمده ای از دفاع CSRF شما به آن بستگی دارد.)

از مقدار Host Header استفاده کنید: اگر ترجیح می‌ دهید که برنامه هدف خاص خود را پیدا کند تا نیازی به پیکربندی برای هر نمونه نصب‌ شده نباشد، توصیه می‌کنیم از خانواده Host Header استفاده کنید. هدف Host Header این است که Target Origin Request را در بر بگیرد. اما، اگر Application Server شما پشت Proxy قرار دارد، مقدار Host Header به احتمال زیاد توسط Proxy به Target Origin URL پشت Proxy تغییر می‌ کند، که با URL اصلی متفاوت است. این Host Header Origin تغییر یافته با Source Origin در Header های Origin یا Referer قرار دارد، مطابقت ندارد.

از مقدار X-Forwarded-Host Header استفاده کنید: برای جلوگیری از مشکل تغییر Host Header Proxy، خوشبختانه Header دیگری به نام X-Forwarded-Host وجود دارد که هدف آن شامل مقدار Host Header اصلی است که Proxy دریافت کرده است. اکثر Proxy ها در امتداد مقدار Host Header اصلی در X-Forwarded-Host Header منتقل می شوند. بنابراین، مقدار Header احتمالاً همان مقدار Target Origin است که باید با Source Origin در Origin Header یا Referer Header مقایسه کنید.

این کاهش زمانی به درستی کار می کند که Header های Origin یا Referer در Request ها وجود داشته باشد. اگرچه این Header ها در اکثر مواقع گنجانده می‌ شوند، اما استثنائاتی کمی وجود دارد که در آن گنجانده نشده‌ اند (بیشتر آنها به دلایل قانونی برای حفظ حریم خصوصی کاربران/برای تنظیم Ecosystem مرورگر ها هستند). موارد زیر برخی از موارد استفاده را فهرست می کند:

  • اینترنت اکسپلورر 11 Origin Hader را در CORS Request در سراسر سایت های یک منطقه قابل اعتماد اضافه نمی کند. Referer Header تنها نشانه UI Origin باقی خواهد ماند.
  • در نمونه‌ 302 Redirect Cross-Origin، جالب است که Origin در Request هدایت‌ شده گنجانده نمی‌ شود زیرا ممکن است اطلاعات حساسی در نظر گرفته شود که نباید به Origin دیگر ارسال شود.
  • برخی زمینه‌ های حفظ حریم خصوصی وجود دارد که Origin روی “null” تنظیم شده است، برای مثال، موارد زیر را اینجا ببینید.
  • Origin Header برای همه cross origin request ها گنجانده شده است، اما برای Origin Request های یکسان، در اکثر مرورگر ها فقط در POST/DELETE/PUT گنجانده شده است. توجه: اگرچه ایده‌آل نیست، بسیاری از توسعه‌ دهندگان از Request های GET برای انجام عملیات تغییر حالت استفاده می‌ کنند.
  • Referer header نیز از این قاعده مستثنی نیست. موارد استفاده متعددی وجود دارد که Referrer Header نیز حذف شده است (1، 2، 3، 4 و 5). Load balancer ها، Proxy ها و دستگاه‌ های شبکه تعبیه‌ شده نیز به‌خوبی شناخته شده‌ اند که Referrer Header را به دلایل حفظ حریم خصوصی در ثبت آنها حذف می‌ کنند.

معمولاً درصد کمی از ترافیک در دسته های فوق قرار می گیرد (1-2%) و هیچ شرکتی نمی خواهد این ترافیک را از دست بدهد. یکی از روش‌ های محبوبی که در سراسر اینترنت برای قابل استفاده‌ تر کردن این تکنیک استفاده می‌شود این است که اگر Origin/Referrer فهرست پیکربندی شده شما از دامنه‌ ها “OR” با مقدار تهی مطابقت داشته باشد، Request را بپذیرید (مثال‌ هایی در اینجا. مقدار null برای Edge Case هاست. در بالا ذکر شد، جایی که این Header ها ارسال نمی شوند). لطفاً توجه داشته باشید که مهاجمان می‌ توانند از این مورد سوء استفاده کنند، اما افراد ترجیح می‌ دهند از این تکنیک به عنوان یک دفاع عمیق استفاده کنند، زیرا تلاش‌ های جزئی در به کارگیری آن انجام می‌ شود.

Cookie with __Host- prefix

راه حل دیگر برای این مشکل استفاده از Prefix های Cookie برای Cookie با CSRF Token است. اگر Cookie دارای پیشوند __Host- باشد، به عنوان مثال Set-Cookie: __Host-token=RANDOM; path=/; Secure سپس کوکی:

  • را نمی توان از زیر دامنه دیگری (بیش از حد) نوشت.
  • باید مسیر / را داشته باشد.
  • باید به عنوان امن علامت گذاری شود (یعنی نمی توان از طریق HTTP رمزگذاری نشده ارسال شود).

استفاده از Custom Request Headers:

افزودن Token های CSRF، یک Cookie و مقدار Double Submit Cookie، یک Token رمزگذاری‌ شده، یا سایر دفاع‌ هایی که مستلزم تغییر رابط کاربری است اغلب می‌ تواند پیچیده یا مشکل‌ ساز باشد. یک دفاع جایگزین که مخصوصاً برای نقاط پایانی AJAX یا API مناسب است، استفاده از Custom Request Header هاست. این دفاع متکی بر محدودیت سیاست همان مبدأ (SOP) است که فقط Java Script می تواند برای افزودن یک Custom Header و فقط در مبدا آن استفاده شود. به‌طور پیش‌ فرض، مرورگر ها به Java Script اجازه نمی‌ دهند تا Cross Origin Request ها را با Custom Header ها ایجاد کند.

اگر این مورد برای سیستم شما است، می توانید به سادگی وجود این Header و مقدار را در تمام نقاط انتهایی AJAX سمت سرور خود به منظور محافظت در برابر حملات CSRF تأیید کنید. این رویکرد دارای مزیت مضاعف است که معمولاً نیازی به تغییر رابط کاربری ندارد و هیچ حالت سمت سرور را معرفی نمی کند که به ویژه برای خدمات REST جذاب است. اگر ترجیح داده شود، همیشه می توانید Header و مقدار سفارشی خود را اضافه کنید.

این تکنیک بدیهی است که برای تماس‌ های AJAX کار می‌ کند، اما همچنان باید از تگ‌ های <form> با رویکرد های توصیف‌ شده در این سند مانند Token ها محافظت کنید. همچنین، پیکربندی CORS نیز باید قوی باشد تا این راه حل به طور مؤثر کار کند (زیرا Custom Header ها برای Request های ارسال شده از دامنه های دیگر باعث بررسی Pre-Flight CORS می شوند).

User Interaction Based CSRF Defense:

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

  • ~~ احراز هویت مجدد~~ مکانیسم مجوز (رمز عبور یا قوی تر)
  • Token یکبار مصرف
  • CAPTCHA (نسخه‌ های جدیدتر CAPTCHA را بدون User Interaction یا Visual Pattern Matching ترجیح دهید)

در حالی که اینها یک دفاع CSRF بسیار قوی هستند، اما می تواند تأثیر قابل توجهی بر تجربه کاربر ایجاد کند. به این ترتیب، آنها معمولاً فقط برای عملیات های حیاتی امنیتی (مانند تغییر رمز عبور، انتقال پول و …) در کنار سایر دفاعیات مورد بحث در این Cheat Sheet استفاده می شوند.

Login CSRF:

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

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

ورود CSRF را می توان با ایجاد pre-session ها (Session های قبل از احراز هویت کاربر) و گنجاندن Token ها در فرم ورود کاهش داد. برای تولید Token ها می توانید از هر یک از تکنیک های ذکر شده در بالا استفاده کنید. به یاد داشته باشید که پس از احراز هویت کاربر، نمی‌ توان pre-session ها را به Session واقعی منتقل کرد – Session باید از بین برود و Session جدیدی برای جلوگیری از حملات Session Fixation ایجاد شود.

مثال Java Reference:

فیلتر وب JEE زیر یک مرجع مثال برای برخی از مفاهیم توصیف شده در این Cheatsheet ارائه می دهد که کاهش‌ دهنده‌ های Stateless زیر را اجرا می‌ کند (OWASP CSRFGuard، پوشش یک رویکرد Stateful).

  • تأیید Same Origin با Header های استاندارد
  • Double Submit Cookie
  • SameSite Cookie Attribute

لطفاً توجه داشته باشید که فقط یک نمونه Reference عمل می کند و کامل نیست (به عنوان مثال: بلوکی برای هدایت جریان کنترل در صورت موفقیت آمیز بودن بررسی Header مبدا و ارجاع دهنده ندارد و همچنین دارای اعتبار سنجی Port/Host/Protocol برای Header ارجاع دهنده نیست. ). به توسعه دهندگان توصیه می شود که کاهش کامل خود را در بالای این نمونه مرجع ایجاد کنند. توسعه دهندگان همچنین باید مکانیسم های احراز هویت و مجوز را قبل از اینکه بررسی CSRF موثر در نظر بگیرند، پیاده سازی کنند.

Source کامل در اینجا قرار دارد و یک POC قابل اجرا را ارائه می دهد.

بدون دیدگاه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد.