نوشته‌شده در

تأیید اعتبار – تفاوت بین 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 وب و برنامه تلفن همراه واکنش دهنده بکار برده شود؟

با تشکر

نوشته‌شده در

برنامه وب – اگر کاربر نیاز به ارسال مجوزهای خود را یکبار به هر کدام از مزایای JWT چیست؟

نشانه های JWT به نظر می رسد یک ایده بسیار خوب است. شما می توانید یک درخواست برای برخی از API ارسال کنید بدون استفاده از نام کاربری / رمز عبور خود را مخفی کنید.

با این حال، من به طور کامل مزایای آن را درک نمی کنم. من دو سوال دارم:

  1. برای دریافت نشانه، کاربر همچنان نیاز به ارسال اعتبار خود را به برخی از سرور که مسائل مربوط به این نشانه ها را صادر می کند. آیا نقطه ضعفی در این مورد نیست؟
  2. اگر حمله کننده در هنگام نقل انتقال علامت را دزدی می کند، می تواند از آن استفاده کند تا وانمود کند که شخص دیگری است. تفاوت تنها بین این و استفاده از رمز عبور کاربر / رمز عبور این است که برچسب JWT پس از یک دوره زمانی از بین می رود، بنابراین مهاجم زمان زیادی برای انجام کاری ندارد.

آیا فهم من درست است؟ چه چیزی از دستم رفته؟ مزایای واقعی استفاده از JWT vs user / password چیست؟

نوشته‌شده در

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

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

نوشته‌شده در

رمزنگاری – آمازون AWS KMS – مفهوم ورود به سیستم به طور کلی و با JWT

به Amazon AWS KMS (سیستم مدیریت کلیدی) نگاه کنید.

اشتباه گرفته شده است زیرا روش های موجود در معرض Amazon AWS API فقط برای رمزگذاری و رمزگشایی هستند. با این حال، من می خواهم امضای اطلاعات (به خصوص JWT).

سوالات من:

1) آیا تقریبا رمزنگاری هش محتوا را امضا می کند؟

2) در مورد JWT، اگر من محتوای هش JWT و رمزگذاری آن و قرار دادن آن در زمینه امضا، آن را به درستی امضا خواهد شد؟

با تشکر،

نوشته‌شده در

تأیید اعتبار – آیا یک مکانیزم مجوز ثروتمند که در آن رمز عبور روشن در keychain ذخیره می شود امن است؟

آیا استفاده از مکانیزم مجوز استقرار زیر بین مشتری (iOS & Android) و سرور امن است؟

ثبت نام

  1. مشتری یک ایمیل و رمز عبور را فراهم می کند و رمز عبور پاک می کند در Keychain در iOS و با استفاده از یک جایگزین برای آندروید.

  2. سرور قدرت رمز عبور را بررسی می کند، اگر آن را به اندازه کافی قوی که کاربر در DB ایجاد شده است.

  3. سرور یک Token JWT را تولید می کند و آن را به مشتری می فرستد. Token زمان انقضا 15 دقیقه است.

  4. مشتری نشانه را (شاید در Keychain خود ذخیره می کند و شامل آن برای هر درخواست زیر در header Authorization می باشد. 19659004] برای هر درخواست، سرور نشانگر ارائه شده را بررسی می کند (امضا و زمان انقضا را بررسی می کند). اگر درست باشد، درخواست پردازش می شود، در غیر این صورت، HTTP 401 بازگشت می شود.

ورود

  1. هنگامی که مشتری یک HTTP 401 از سرور دریافت می کند، به این معنی ورود به سیستم مورد نیاز است. بنابراین برنامه به Keychain دسترسی پیدا می کند و ایمیل و رمز عبور را دریافت می کند (بدون مداخله کاربر لازم است).

  2. سرور معتبر ارائه شده است و اگر معتبر باشد، آن را تکرار خواهد کرد ثبت نام مراحل از 3 تا 5.

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

اگر یک کاربر وارد سیستم شده باشد چندین دستگاه و رمز عبور خود را از یک دستگاه تغییر می دهد، دستگاه های دیگر فقط برای یک دوره زمانی کوتاه وارد سیستم می شوند، اما رمز عبور روشن ذخیره شده در Keychain [19459009طولانیترنخواهدبود

کدام نقص را می بینید؟

من فکر کرده ام در مورد استفاده از روش نشانه بازنویسی برای جلوگیری از ذخیره رمز عبور پاک، اما این پیچیدگی را اضافه می کند و اشکالات دیگر (برای مثال: چگونگی تضمین refresh token فقط یک بار استفاده می شود). و تا آنجا که من دیده ام، ذخیره رمز عبور روشن در کلید KeyChain به اندازه کافی امن است:

Documentation Services KeyChain

بهترین روش برای حفظ اعتبار ورود به سیستم در iOS چیست؟ [19659012] اما من همچنین سؤالات دیگری را مشاهده کردم که توصیه نمیکنند رمزهای عبور را بر روی دستگاه ذخیره کنند.

بنابراین من می خواهم که نظرات دیگران را در این مورد بشنوم.

</p> <pre>تأیید اعتبار - آیا یک مکانیزم مجوز ثروتمند که در آن رمز عبور روشن در keychain ذخیره می شود امن است؟<br />