• 0 رای - 0 میانگین
  • 1
  • 2
  • 3
  • 4
  • 5
نحوه پچ کردن باگ csrf
#1
با سلام
میخواستم بصورت کامل نحوه پچ کردن باگ csrf رو واسم توضیح بدید .
هر چی سرچ کردم خوب متوجه نشدم .
ممنون
  پاسخ
تشکر شده توسط :
#2
روال پاسخ به سوالات در انجمن به این شکل نیست که کسی پاسخ کامل مشکلات افراد را بدهد اما در اینجا برایتان متد جلوگیری از این حمله (و نه باگ) را توضیح خواهم داد.
در حالت کلی (برای Verbهای GET و POST) باید برای GET تنها اطلاعات را استخراج کنید و هیچ عملیات ذخیره سازی‌ای توسط درخواست‌های GET انجام نشود در درخواست‌های POST باید یک مقدار رندوم که در سرور به نوعی نگهداری می‌شود (مثلا در Session) همراه با دیگر مقادیر ارسال شود پیش از هر اقدامی مقدار ارسالی با مقدار موجود در سرور کنترل شود اگر برابر بود بقیه عملیات انجام شود.

۱-درخواست GET برای یک صفحه حاوی فرم اطلاعات
۲-تولید رشته رندوم ذخیره کردن آن در سرور و قرار دادن آن در فرم به صورت یک فیلد hidden
۳-ارسال اطلاعات توسط کاربر
۴-چک کردن مقدار ارسالی و مقدار ذخیره شده در سرور
  پاسخ
تشکر شده توسط :
#3
خط دوم رو نگرفتم چی شد!!!
مگه این نوع حمله در روش ارسال GET یا POST فرق میکنه ؟؟

یعنی کد زیر که برای حذف یک رکورد بکار میره
www.site.com/deletepost.php?id=25
باید بصورت زیر بکار رفته بشه
www.site.com/deletepost.php?id=25&token=123135454646465656

که این token که رندوم تولید شده باید در سشن زمان ورود کاربر ذخیره بشه
بخش دوم باید فیلد hidden در deletepost.php ذخیره بشه یا در فرمی که اطلاعات submit میشه ؟؟؟؟
  پاسخ
تشکر شده توسط :
#4
(۱۳۹۳ شهریور ۰۶, ۱۰:۱۷ ق.ظ)phpveteran نوشته: ...
در حالت کلی (برای Verbهای GET و POST) باید برای GET تنها اطلاعات را استخراج کنید و هیچ عملیات ذخیره سازی‌ای توسط درخواست‌های GET انجام نشود
...

چنانچه در نقل قول مشاهده می‌شود توضیح دادم که بهتر است در درخواست‌های GET عملیات ذخیره سازی (حذف/ویرایش/نوشتن) در پایگاه داده انجام نشود لذا تنها کافیست که درخواست‌های POST خود را در مقابل این حملات مقاوم نمایید.

در مورد token در هنگام ورود کاربر خیر بلکه در هر بار ارسال درخواست این رشته باید مجددا تولید شده و در Session بجای رشته قبلی ذخیره گردد

این token باید در فرمی که قرار است ارسال شود در مقدار یک فیلد مخفی قرار گیرد.


نکته: دوست گرامی پاسخ بنده بسیار مختصر هست و در برخی موارد بدون توضیحات اضافی شاید در ابتدا حتی نادرست به نظر آید فرض بنده بر این بوده که شما اطلاعات کافی در مورد این حمله دارید و همچنین من مواردی را در نظر گرفتم که نتیجه تجربیات مختلف است به طور مثال در یک استثنا (خروج Logout) شما لازم دارید که token را در درخواست GET استفاده نمایید یا اینکه در درخواست DELETE/PUT/POST بهتر است از TOKEN استفاده شود یا اینکه دلیل استفاده نشده در GET این است که استفاده از این روش ملزم می‌کند که برای تمام ریکوئست‌ها Session تولید شود (auto start) این تنظیم سربار بسیار زیادی را به سرور وارد می‌اورد خصوصا اگر از Storage فایل یا memcache برای session استفاده کرده باشید مشکلات زیادی را برای ترافیک‌های معمولی و بالا به همراه خواهد داشت و...
لذا پیشنهاد می‌کنم اولا از یک فریم‌ورک برای انجام پروژه‌های خود استفاده کنید ثانیا با مطالعه پست‌های بیشتر در همین انجمن و دیگر منابع موجود در اینترنت دانش خود را افزایش دهید.

نکته ۲: (لطفا پس از اشراف به مطالب بالا این نکته را مطالعه فرمایید) در سال ۲۰۱۳ یک آسیب پذیری جدید در روش بالا مشاهده شد که به حملات BREACH موسوم شد. برای پیشگیری از این آسیب پذیری بهترین کار استفاده از یک Mask برای رشته Token خام است جهت مطالعه بیشتر به منابع زیر مراجعه نمایید:

http://breachattack.com


https://community.qualys.com/blogs/secur...ach-attack
  پاسخ
تشکر شده توسط :
#5
برای تمام ریکوئست‌ها Session تولید شود

چرا باید برای هر ریکوئست یک session تولید شود
مگر نمیشه یک سشن تولید کرد و اونو در همه رکوئست ها بکار برد
  پاسخ
تشکر شده توسط :
#6
بله اشتباه در ادبیات من بود auto start همین کار را انجام می دهد و همین هم مشکلات زیادی ایجاد می کند در مورد نوشتن در سشن هم بخصوص اگر storage فایل باشد مسئله ساز خواهد شد
  پاسخ
تشکر شده توسط : ImanAzadi


پرش به انجمن:


کاربران در حال بازدید این موضوع: 1 مهمان