localStorage
أنواع التوكنات
- عادةً ما تكون رموز الوصول عبارة عن JWTs قصيرة العمر موقعة من الخادم. يتم تضمينها في كل طلب HTTP يقدمه العميل إلى الخادم. تستخدم الرموز لتفويض الطلبات.
- عادةً ما تكون رموز التحديث عبارة عن رموز مميزة طويلة العمر مخزنة في قاعدة بيانات وتستخدم للحصول على رمز وصول جديد عند انتهاء صلاحية الرمز المميز السابق.
أين يجب أن يتم تخزين الرموز المميزة على العميل بالضبط؟
هناك طريقتان شائعتان لتخزين الرموز على العميل: تخزين المتصفح المحلي وملفات تعريف الارتباط. هناك الكثير من الجدل حول الطريقة الأفضل. يميل معظم الناس إلى ملفات تعريف الارتباط بسبب أمانهم الأفضل.
دعونا نقارن التخزين المحلي وملفات تعريف الارتباط. تستند مقارنتنا في المقام الأول على هذه المادة وعلى التعليقات عليها.
التخزين المحلي
المزايا
الميزة الرئيسية للتخزين المحلي هي سهولة الاستخدام.
- العمل مع التخزين المحلي مريح للغاية ، يتم استخدام JavaScript خالص هنا. إذا كان تطبيقك لا يحتوي على واجهة خلفية وكنت تعتمد على واجهات برمجة تطبيقات تابعة لجهات خارجية ، فقد لا تتمكن دائمًا من طلب واجهات برمجة التطبيقات هذه لتعيين ملفات تعريف ارتباط معينة لموقعك.
- باستخدام التخزين المحلي ، من الملائم العمل مع واجهات برمجة التطبيقات التي تتطلب وضع رمز وصول في رأس الطلب. على سبيل المثال - على النحو التالي:
Authorization Bearer ${access_token}.
▍ العيوب
العيب الرئيسي للتخزين المحلي هو قابليته للتأثر بهجمات XSS.
- عند تنفيذ هجوم XSS ، يمكن للمهاجم تشغيل كود JavaScript الخاص به على موقعك. هذا يعني أنه يمكن للمهاجم الوصول إلى رمز الوصول المخزن في
localStorage. - يمكن أن يكون مصدر هجوم XSS عبارة عن شفرة جافا سكريبت تابعة لجهة خارجية مضمنة في موقعك. قد يكون شيئًا مثل React و Vue و jQuery و Google Analytics script وما إلى ذلك. في الظروف الحديثة ، يكاد يكون من المستحيل تطوير موقع لا يتضمن مكتبات الجهات الخارجية.
بسكويت
المزايا
الميزة الرئيسية لملفات تعريف الارتباط هي أنه لا يمكن الوصول إليها من JavaScript. نتيجة لذلك ، فهي ليست عرضة لهجمات XSS مثل التخزين المحلي.
- إذا كنت تستخدم علامة
HttpOnlyوملفات تعريف ارتباط آمنة ، فهذا يعني أن JavaScript لا يمكنه الوصول إلى هذه الملفات. أي أنه حتى إذا تمكن المهاجم من تشغيل التعليمات البرمجية الخاصة به على صفحتك ، فلن يتمكن من قراءة رمز الوصول من ملف تعريف الارتباط. - يتم إرسال ملفات تعريف الارتباط تلقائيًا في كل طلب HTTP إلى الخادم.
▍ العيوب
اعتمادًا على الظروف المحددة ، قد لا يمكن تخزين الرموز المميزة في ملفات تعريف الارتباط.
- يقتصر حجم ملفات تعريف الارتباط على 4 كيلوبايت. لذلك ، إذا كنت تستخدم JWTs كبيرة الحجم ، فلن يعمل تخزينها في ملفات تعريف الارتباط.
- هناك سيناريوهات حيث لا يمكنك تمرير ملفات تعريف الارتباط إلى خادم API الخاص بك. من الممكن أيضًا أن تتطلب بعض واجهات برمجة التطبيقات وضع رمز مميز في الرأس
Authorization. في هذه الحالة ، لن تتمكن من تخزين الرموز المميزة في ملفات تعريف الارتباط.
هجمات XSS
التخزين المحلي عرضة لهجمات XSS لأنه من السهل جدًا التعامل معه باستخدام JavaScript. لذلك ، يمكن للمهاجم الوصول إلى الرمز المميز واستخدامه لصالحه. ومع ذلك ، على الرغم من أن ملفات تعريف الارتباط HttpOnly لا يمكن الوصول إليها من JavaScript ، فإن هذا لا يعني أنك محمي من هجمات XSS باستخدام ملفات تعريف الارتباط لسرقة رمز وصول.
إذا تمكن المهاجم من تشغيل كود JS الخاص به في تطبيقك ، فهذا يعني أنه يمكنه ببساطة إرسال طلب إلى الخادم الخاص بك ، وسيتم تضمين الرمز المميز في هذا الطلب تلقائيًا. مخطط العمل هذا ببساطة لا يناسب المهاجم ، لأنه لا يستطيع قراءة محتويات الرمز المميز. لكن المهاجمين نادرا ما يحتاجون إلى هذا. بالإضافة إلى ذلك ، مع مخطط العمل هذا ، قد يكون من المربح للمهاجم مهاجمة الخادم باستخدام كمبيوتر الضحية ، بدلاً من جهازه الخاص.
هجمات ملفات تعريف الارتباط و CSRF
هجمات CSRF هي هجمات يتم فيها إجبار المستخدم بطريقة ما على تقديم طلب خاص. على سبيل المثال ، يقبل الموقع طلبات تغيير عنوان البريد الإلكتروني:
POST /email/change HTTP/1.1
Host: site.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 50
Cookie: session=abcdefghijklmnopqrstu
email=myemail.example.com
في مثل هذه الحالة ، يمكن للمهاجم إنشاء نموذج بحقل مخفي لإدخال عنوان بريد إلكتروني يرسل طلب POST إلى
https://site.com/email/change. في هذه الحالة ، سيتم تضمين ملفات تعريف الارتباط للجلسة تلقائيًا في مثل هذا الطلب.
ومع ذلك ، يمكن حماية هذا التهديد بسهولة باستخدام السمة
SameSiteالموجودة في رأس الاستجابة والرموز المميزة المضادة لـ CSRF .
المجاميع الجزئية
على الرغم من أن ملفات تعريف الارتباط ليست محصنة تمامًا ضد الهجمات ، فإن أفضل طريقة لتخزين الرموز هي ، كلما أمكن ذلك ، اختيارهم بدلاً من ذلك
localStorage. لماذا ا؟
- كل من التخزين المحلي وملفات تعريف الارتباط عرضة لهجمات XSS ، ولكن سيكون من الصعب على المهاجم الهجوم إذا تم استخدام ملفات تعريف الارتباط HttpOnly.
- الكوكيز هي عرضة لهجمات CSRF، ولكن خطر هذه الهجمات يمكن تخفيفها باستخدام السمة
SameSiteو مكافحة CSRF الرموز.
يمكن استخدام ملفات تعريف الارتباط حتى عندما تحتاج إلى استخدام رأس
Authorization: Bearerأو عندما يكون JWT أكبر من 4 كيلوبايت. يتوافق هذا أيضًا مع إرشادات OWASP: "لا تقم بتخزين معرفات الجلسات في التخزين المحلي ، حيث أن البيانات المقابلة متاحة دائمًا من JavaScript. يمكن أن تساعد ملفات تعريف الارتباط في التخفيف من المخاطر باستخدام HttpOnly. "
استخدام ملفات تعريف الارتباط لتخزين رموز OAuth 2.0 المميزة
دعنا نسرد بإيجاز طرق تخزين الرموز:
- الطريقة الأولى: تخزين الرموز المميزة في التخزين المحلي. هذه الطريقة عرضة لهجمات XSS.
- الطريقة الثانية: تخزين الرموز المميزة في ملفات تعريف الارتباط HttpOnly. هذه الطريقة عرضة لهجمات CSRF ، ولكن يمكن التخفيف من مخاطر مثل هذه الهجمات. يعد خيار تخزين الرمز المميز محميًا بشكل أفضل قليلاً من هجمات XSS من الأول.
- الطريقة الثالثة: تخزين رموز التحديث المميزة في ملفات تعريف الارتباط HttpOnly ورموز الوصول في الذاكرة. تعد طريقة تخزين الرموز المميزة أكثر أمانًا من حيث هجمات CSRF وهي محمية بشكل أفضل قليلاً من هجمات XSS.
فيما يلي سوف نلقي نظرة فاحصة على الطريقة الثالثة لتخزين الرموز ، حيث أنها تبدو الأكثر إثارة للاهتمام من بين الثلاثة المدرجة.
لماذا يعد تخزين رمز التحديث في ملف تعريف ارتباط HttpOnly أكثر أمانًا من حيث هجمات CSRF؟
يمكن للمهاجم إنشاء نموذج يمكن الوصول إليه
/refresh_token. تم إرجاع رمز وصول جديد استجابة لهذا الطلب. لكن المهاجم لا يمكنه قراءة الرد إذا كان يستخدم نموذج HTML. من أجل منع المهاجم من تنفيذ طلبات الجلب أو AJAX وقراءة الردود بنجاح ، يجب تكوين سياسة CORS الخاصة بخادم التفويض بشكل صحيح ، أي بحيث لا يستجيب الخادم للطلبات الواردة من مواقع الويب غير المصرح بها.
كيف يمكنك إعداده؟
الخطوة 1: إعادة رمز الوصول وتحديث الرمز المميز عند مصادقة المستخدم
بعد أن يقوم المستخدم بالمصادقة ، يعود خادم المصادقة
access_token(رمز الوصول) و refresh_token(رمز التحديث). سيتم تضمين رمز الوصول في نص الاستجابة ورمز التحديث في ملف تعريف الارتباط.
إليك ما تحتاج إلى استخدامه لإعداد ملفات تعريف الارتباط لتخزين رموز التحديث المميزة:
- العلم
HttpOnly- لمنع JavaScript من قراءة رمزية. - علامة
secure=trueتتسبب في إرسال البيانات عبر HTTPS فقط. SameSite=strictيجب استخدام العلم كلما أمكن ذلك للحماية من هجمات CSRF. لا يمكن استخدام هذا الأسلوب إلا إذا كان خادم الترخيص ينتمي إلى نفس الموقع مثل الواجهة الأمامية للنظام. إذا لم يكن الأمر كذلك ، فيجب على خادم التفويض تعيين رؤوس CORS على الواجهة الخلفية ، أو استخدام طرق أخرى للتأكد من أنه لا يمكن تقديم طلب برمز تحديث إلا عن طريق موقع ويب معتمد.
الخطوة 2: قم بتخزين رمز الوصول في الذاكرة
يعني تخزين رمز الوصول في الذاكرة أن الرمز المميز في كود الواجهة الأمامية مكتوب إلى متغير. هذا ، بالطبع ، يعني أنه سيتم فقد الرمز المميز إذا قام المستخدم بإغلاق علامة التبويب حيث يكون الموقع مفتوحًا أو قام بتحديث الصفحة. هذا هو السبب في أن لدينا رمز التحديث.
الخطوة 3: الحصول على رمز وصول جديد باستخدام رمز التحديث
إذا تبين أن رمز الوصول مفقود أو غير صالح ، فأنت بحاجة إلى الاتصال بنقطة النهاية
/refresh_token. في هذه الحالة ، سيتم تضمين رمز التحديث ، الذي تم حفظه في ملف تعريف الارتباط في الخطوة 1 ، في الطلب. ستتلقى بعد ذلك رمز وصول جديدًا يمكنك استخدامه لتقديم طلبات API.
كل هذا يعني أن JWTs يمكن أن تكون أكبر من 4 كيلوبايت ، ويمكن وضعها في الرأس
Authorization.
النتيجة
يجب أن يوفر لك ما قمنا بتغطيته هنا بعض المعلومات الأساسية حول تخزين JWTs على العميل ، وكيفية جعل مشروعك أكثر أمانًا.
كيف تخزن JWT على العميل؟
