نوشته‌شده در

محافظت از CSRF و برنامه های صفحه ای تنها در میزبان S3 (بدون پشت صحنه).

من یک webapp نوشته شده در JS که در AWS S3 اجرا می شود. هیچ راهی برای راه اندازی یک نشانه امن CSRF در بارگذاری صفحه وجود ندارد، زیرا هیچ سرور پشتیبان وجود ندارد. این شناسه باید از طریق یک تماس AJAX به سرور API من در یک دامنه متفاوت بازیابی شود. سیاست API CORS برای ثبت درخواست از برنامه js به لیست سفید اضافه شده است.

آیا علامت CSRF از طریق ajax درخواست می شود؟ آیا کسی که می خواهد یک نشانه معتبر CSRF را بدست آورد، می تواند هدرهای مبدأ را جعل کند؟ (این نشانه توسط لاراول ساخته شده است)

نوشته‌شده در

کوکی ها – حفاظت CSRF برای درخواست های GET مورد نیاز است

یک API REST دارم که اجازه می دهد تا کاربران تأیید اعتبار اطلاعات خود را در مورد حساب خودشان بخوانند و تغییرات را در حساب هایشان انجام دهند. برای احراز هویت، از JWT ها به عنوان کوکی های httpOnly ذخیره می شود. برای محافظت در برابر حملات CSRF، API REST همچنین مشتری را با آنچه زاویه ای نامیده می شود، نشان می دهد "XSRF token"

روش زاویه ای برای محافظت از CSRF این است که علامت XSRF را برای API شما ایجاد و دوباره آن را به API ارسال نماید هر درخواست در هدر "X-XSRF-Token". این به API شما بستگی دارد تا تعیین کند که آیا درخواست مجاز باشد یا نه. یک اسکریپت که در یک وبسایت خصمانه اجرا می شود، به نشانه XSRF دسترسی نخواهد داشت و بنابراین نمی تواند آن را همراه با درخواست های CSRF ارسال کند.

وقتی برای اجرای درخواست های اولیه خود در Angular با استفاده از HttpClient رفتم متوجه شدم که HttpXsrfInterceptor هدر X-XSRF-Token را با درخواستهای GET و HEAD ارسال نمی کند.

از نظرات من آنلاین خواندن، حفاظت از CSRF برای درخواست های GET مورد نیاز نیست زیرا آنها نمی کنند (یا نباید آنها را ) هر گونه اطلاعات را تغییر دهید بیشترین حمله یک حمله CSRF با یک درخواست GET می تواند REST API ارسال اطلاعات حساس به مرورگر وب کاربر باشد. وب سایت خصمانه نمیتواند این اطلاعات را ببیند.

اگر یک وبسایت خصمانه سعی کند یک درخواست CSRF GET مانند این

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

اگر یک وب سایت خصمانه سعی کند یک درخواست CSRF POST مانند این 




  
  


 را صادر کند ...

پس از آن وب سایت خصمانه هنوز هیچ اطلاعاتی را نمی بیند، اما هنوز هم می تواند به یک کاربر آسیب برساند. اگر API نیازمند هدر X-XSRF-Token باشد، این حمله نمی تواند موفقیت آمیز باشد.

اما اگر وب سایت خصمانه مرورگر را مجبور به درخواست GET می کند مانند:

بعضی از سیاست های CORS این را متوقف می کنند، اما سایر سیاست های CORS همچنان این اتفاق می افتد.

به نظر می رسد که نیاز به حفاظت CSRF در درخواست های GET، این آسیب پذیری را کاهش می دهد.

آیا چیزی مهم را از دست می دهم؟

نوشته‌شده در

قرار دادن csrf نشانه

من می دانم که چندین مکان برای قرار دادن یک نشانه csrf وجود دارد و شایع ترین آن این است که یک فیلد ورودی مخفی در یک فرم قرار دهید. آنچه که من می خواهم بدانم این است که مخالفت آن ها با قرار دادن آن در یک متغیر جاوا اسکریپت است، بنابراین می توان آن را هر بار که درخواست ارسال شده برای تغییر داده ها استفاده می شود استفاده شود.

در غیر این صورت شما باید آن را در فیلد پنهان فرم برای هر فرم قرار دهید و اگر فرم به صورت پویا تولید شود، مشکل می تواند باشد.

نوشته‌شده در

آیا در این تنظیم نیاز به حفاظت از CSRF با یک API REST با پشتیبانی oauth2 و یک سرور معتبر SSO Auth SSO دارم؟

من دیدم پاسخ آیا CSRF امکان پذیر است اگر من حتی از کوکی ها استفاده نمی کنم؟ اما 2 پاسخ متقابل وجود دارد و خود سوال این اطلاعات را نیز ارائه نمی دهد.

من یک API REST ایجاد می کنم که توسط یک سرویس دهنده وب (از ایجاد خود ما) در حال اجرا در دامنه دیگری استفاده می شود، بنابراین ما درخواست CORS را انجام دهید این API به عنوان یک سرور منبع oauth2 اجرا می شود، بنابراین دسترسی توسط توالی هایی که در هدر احراز هویت منتقل می شوند محدود شده است. ما هیچ کوکی وجود ندارد، همه چیز بی ثمر است. من از مقاله در https://spring.io/blog/2011/11/30/cross-site-request-forgery-and-oauth2

  • دنبال میکنم. ما از SSL استفاده خواهیم کرد
  • ثبت نام تغییر مسیر uri
  • تنها نوع اعطاء ما، کد مجوز است، بدون نیاز به یک مخفی مشتری (به عنوان منبع مشتری وب عمومی) به جای نوع کمک ضمنی، به عنوان در مورد توصیه های در https://oauth.net/2/ grant-types / implicit /
  • مشتری با یک سرصفحه تایید می کند زمانی که سرور سرور واقعی آن را فراخوانی می کند
  • دریافت پروانه دسترسی توسط گذراندن کد مجوز 1 بار در پارامترهای فرم صورت می گیرد ( x-www- Form-urlencoded )، که به نظر می رسد راه طبیعی است، نباید در تاریخ مرورگر به عنوان پارامتر query باشد.
  • مشتری همچنین از برخی از پارامترهای حالت مخفی هنگام استفاده از کد مجوز استفاده می کند. در این مورد من مطمئن نیستم که یک نقطه وجود دارد زیرا مشتری به یک رمز محرمانه برای دسترسی به یک نشانه دسترسی دسترسی پیدا نمی کند.
  • برای نقطه پایانی oauth / token که در واقع شما یک token دسترسی دریافت می کنید، تنها مجاز هسته دامنه مشتری وب ما است
  • برای نقطه پایانی oauth / authorize CORS مجاز نیست. شاید این بیش از حد باشد زیرا تغییر مسیر یوری فقط به حوزه ی خود ما اشاره می کند؟

من فکر می کنم که تقریبا همه چیز را در آن قسمت پوشش می دهد.

اکنون یک بردار حمله دیگر وجود دارد که در قالب سرور تأیید هویت oauth2 وجود دارد خود، که قرار است SSO باشد و جلسات داشته باشد و با مجوز اولیه در دسترس است. با این حال، به نظر نمی رسد هیچ اقدامی را که می توانید با یک حمله csrf انجام دهید که در واقع مفید خواهد بود. شما می توانید درخواست خود را به این نقطه های oauth انجام دهید، اما شما باید قادر به خواندن نتیجه، که توسط پیکربندی CORS جلوگیری می کند و این واقعیت است که تغییر مسیر uri از قبل ثبت شده است. هیچ POST شما وجود ندارد که بتوانید رمز عبور خود را عوض کنید، آدرس ایمیل خود را بازنشانی کنید، و غیره، همه چیز در واقع به عنوان یک سرور منبع نیز در معرض قرار دارد.

آیا چیزی از دست رفته؟ چگونه می توان در مورد جستجوی آسیب پذیری ها در اینجا جستجو کرد؟