نوشته‌شده در

تأیید اعتبار – تفاوت بین res.header (x-auth، JWTtoken) و res.cookies (JWTtoken)؟

من در تمام وبلاگ ها و مقالات دیده ام که دو راه برای اداره JWTtokens وجود دارد، آنها را داخل localStorage قرار داده و برای حمله XSS آنها در داخل کوکی ها و مجموعه httpOnly و امن پرچم برای جلوگیری از XSS .

با استفاده از localStorage

سرور علامت را خارج از localStorage استخراج کرده و آن را به مجوز: Bearer بطور دستی وارد می کند.

با استفاده از کوکی ها

آن را توسط طرف JS قابل دسترسی نخواهید بود، آنچه که شما انجام می دهید، res.cookies (token) است و به صورت خودکار برای هر تماس بعدی ارسال می شود بر خلاف localStorage

اما اخیرا برخی از توسعه دهندگان را دیدم که علامت گذاری شده در هدر ها با استفاده از res.headers ('x-auth'، token) .

  1. آیا راه سوم برای مدیریت JWT است؟
  2. آیا هدر X-Auth برای هر درخواست بعدی به سرور مانند کوکی ها به صورت خودکار تنظیم می شود یا شما باید آن را دستی (به عنوان مثال در مورد localStorage) تنظیم کنید؟
  3. آیا نشانه ها در هدر X-Auth توسط JS قابل دسترسی نیستند و مانند کوکی ها قابل دسترسی هستند؟
  4. تفاوت بین انجام این کار res.header ('X-auth') و res.cookie (token) چیست؟

  5. سرانجام بهترین راه برای انجام این کار این است که اگر API من توسط برنامه ReactJS وب و برنامه تلفن همراه واکنش دهنده بکار برده شود؟

با تشکر

نوشته‌شده در

کوکی ها – حفاظت 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، این آسیب پذیری را کاهش می دهد.

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

نوشته‌شده در

آیا ممکن است کوکی ها را بدون XSS سرقت کنم؟

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

نوشته‌شده در

TLS – جلسات اجرا شده از طریق کوکی ها بر روی HTTPS

من در مورد جلسات اجرا شده از طریق کوکی ها سوال دارم. من تازه شروع به یادگیری در مورد امنیت کرده ام و از این مسئله عذر خواهی می کنم اگر این سوال به عنوان چیزی ابتدایی به نظر برسد.

بگذارید بگویم از HTTPS استفاده می کنم، بنابراین تمام داده های کوکی رمزگذاری می شوند و تنها سرور می تواند با کلید خصوصی آن رمزگشایی کند. اما این هنوز کسی را از تکان دادن ترافیک من متوقف نمی کند و رشته دقیق همان در هدرهای هر درخواست را مشاهده می کند. بنابراین کسی که ترافیک را خراب می کند می تواند دریابد که این رشته ثابت در هر هدر درخواست ممکن است کوکی جلسه باشد. اگر مهاجم تلاش می کند هر علامت را در داخل بدن درخواست یا کوکی تغییر دهد، در هنگام رمزگشایی آن به عنوان ناخواسته در سرور ظاهر می شود. با این حال، حتی اگر رمزگذاری شده باشد، مهاجم می تواند درخواست را دوباره ارسال کند و حملات را انجام دهد، درست است؟

آیا می توانم بگویم که SSL / TLS مانع از دستکاری کوکی ها می شود، اما در واقع نمی تواند از سرقت و یا پخش مجدد جلوگیری کند؟

نوشته‌شده در

خط مشی رازداری (ها). آیا کوکی "جمع آوری" داده های مرورگر یا "درخواست" اطلاعات مرورگر است؟

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

سوال: آیا کوکی ها "جمع آوری" داده ها از مرورگرهای کاربر یا انجام کوکی ها "درخواست" و سپس دریافت داده ها از مرورگرهای کاربر

این به نظر می رسد یک تمایز بسیار مهم است. آیا من به سیاست حفظ حریم خصوصی خود که سایت خود را "جمع آوری" داده ها از کاربران من و یا من "درخواست" داده ها از کاربران من قرار داده است.

درک من از عملکرد اصلی این است که کوکی ها درخواست داده ها از مرورگر کاربر و یا فعالیت مرورگر. کاربران کنترل مرورگرهای خود را (یا دسته کوکی ها) را در تنظیمات مرورگر خود کنترل می کنند. اگر کاربران کنترل نهایی مربوط به «پاسخ» به کوکی ها را داشته باشند، آیا برای سیاست های حفظ حریم خصوصی وبسایت مناسب است که از کوکی ها برای جمع آوری اطلاعات مرورگر استفاده کنند؟ آیا دقیق تر است که چنین چیزی را بیان کنیم: "ما از کوکی ها برای درخواست داده ها از مرورگر خود استفاده می کنیم. بسته به اینکه شما تنظیمات خود را دارید، پاسخ شما به درخواست ما، تجربه شما را تحت تاثیر قرار می دهد." یا چیزی در امتداد این خطوط.

سالهاست که من فهمیدم که «کوکیها اطلاعات مرورگر را جمعآوری میکنند» اینست که ما (وبسایتها) کد را (کوکی) را به مرورگر خود اعمال میکنیم که برای تمام فعالیتهای شما باز میگردد به ما. اما این طور نیست. کوکی ها در ابتدا درخواست "درخواست" (به عنوان مثال، می پرسد) برای کاربر اجازه می دهند و بسته به اینکه چگونه کاربر تنظیمات مرورگر خود را تنظیم کرده است، درخواست کوکی honored یا رد می شود.

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

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