it-swarm.asia

لماذا جوجل prepend بينما (1) ؛ على ردودهم JSON؟

لماذا تعلق Google while(1); على ردود JSON (خاصة)؟

على سبيل المثال ، إليك استجابة أثناء تشغيل التقويم وإيقافه في تقويم Google :

while(1);[['u',[['smsSentFlag','false'],['hideInvitations','false'],
  ['remindOnRespondedEventsOnly','true'],
  ['hideInvitations_remindOnRespondedEventsOnly','false_true'],
  ['Calendar ID stripped for privacy','false'],['smsVerifiedFlag','true']]]]

أفترض أن هذا لمنع الناس من القيام بـ eval() ، ولكن كل ما عليك فعله فعلاً هو استبدال while ومن ثم سيتم تعيينك. أفترض أن منع eval هو التأكد من أن الناس يكتبون كود JSON الآمن للتحليل.

لقد رأيت هذا مستخدمًا في مكانين آخرين ، أيضًا ، ولكن أكثر من ذلك بكثير مع Google (البريد ، التقويم ، جهات الاتصال ، إلخ.) الغريب في الأمر ، مُحرر مستندات Google يبدأ بـ &&&START&&& بدلاً من ذلك ، ويبدو أن جهات اتصال Google لتبدأ while(1); &&&START&&&.

ماذا يجري هنا؟

3824
Jess

يمنع JSON hijacking ، مشكلة أمان JSON رئيسية غير رسمية ثابت في جميع المتصفحات الرئيسية منذ 2011 مع ECMAScript 5.

مثال مفترض: قل أن لدى Google عنوان URL مثل mail.google.com/json?action=inbox والذي يعرض أول 50 رسالة من بريدك الوارد بتنسيق JSON. لا يمكن لمواقع الويب الشريرة على المجالات الأخرى تقديم AJAX طلبات للحصول على هذه البيانات بسبب سياسة الأصل نفسه ، لكن يمكنها تضمين عنوان URL عبر علامة <script>. تتم زيارة عنوان URL باستخدام your ملفات تعريف الارتباط ، وبواسطة تجاوز مُنشئ الصفيف العمومي أو طرق الوصول) يمكن أن يكون لديهم طريقة تسمى كلما تم تعيين سمة كائن (صفيف أو تجزئة) ، مما يسمح لهم بقراءة محتوى JSON.

يمنع while(1); أو &&&BLAH&&& هذا: سيكون للطلب AJAX في mail.google.com الوصول الكامل إلى المحتوى النصي ، ويمكنه تجريده بعيدًا. لكن إدراج علامة <script> ينفذ JavaScript بشكل عمياء دون أي معالجة ، مما ينتج عنه حلقة لا نهائية أو خطأ في بناء الجملة.

هذا لا يعالج مشكلة طلب التزوير عبر المواقع .

4079
rjh

يمنع الكشف عن الرد من خلال اختطاف JSON.

من الناحية النظرية ، فإن محتوى ردود HTTP محمي بواسطة "سياسة الأصل نفسه": لا يمكن لصفحات من مجال ما الحصول على أي أجزاء من المعلومات من الصفحات على المجال الآخر (ما لم يسمح بذلك صراحة).

يمكن للمهاجم طلب صفحات على نطاقات أخرى نيابة عنك ، على سبيل المثال باستخدام علامة <script src=...> أو <img> ، لكن لا يمكن الحصول على أي معلومات حول النتيجة (الرؤوس ، المحتويات).

وبالتالي ، إذا قمت بزيارة صفحة أحد المهاجمين ، فلن تتمكن من قراءة بريدك الإلكتروني من gmail.com.

إلا أنه عند استخدام علامة البرنامج النصي لطلب محتوى JSON ، يتم تنفيذ JSON كـ Javascript في بيئة مسيطر عليها للمهاجمين. إذا كان بإمكان المهاجم استبدال مُنشئ Array أو Object أو أي طريقة أخرى مستخدمة أثناء بناء الكائن ، فإن أي شيء في JSON يمر عبر رمز المهاجم ، وسيتم الكشف عنه.

لاحظ أن هذا يحدث في الوقت الذي يتم فيه تنفيذ JSON كـ Javascript ، وليس في الوقت الذي يتم فيه تحليله.

هناك العديد من الإجراءات المضادة:

التأكد من عدم تنفيذ JSON أبدًا

عن طريق وضع عبارة while(1); قبل بيانات JSON ، تتأكد Google من عدم تنفيذ بيانات JSON على أنها Javascript.

فقط صفحة شرعية يمكنها فعلاً الحصول على المحتوى بالكامل ، وتجريد while(1); ، وتحليل الباقي كـ JSON.

تمت مشاهدة أشياء مثل for(;;); في Facebook على سبيل المثال ، مع نفس النتائج.

التأكد من أن JSON غير صالح Javascript

وبالمثل ، فإن إضافة رموز غير صالحة قبل JSON ، مثل &&&START&&& ، تتأكد من عدم تنفيذها مطلقًا.

دائما العودة JSON مع كائن من الخارج

هذا هو OWASPالطريقة الموصى بها للحماية من اختطاف JSON وهو الأقل تدخلاً.

على نحو مشابه للتدابير المضادة السابقة ، فإنه يتأكد من عدم تنفيذ JSON على أنها Javascript.

كائن JSON صالح ، عندما لا يحاط بأي شيء ، غير صالح في Javascript:

eval('{"foo":"bar"}')
// SyntaxError: Unexpected token :

هذا صحيح JSON:

JSON.parse('{"foo":"bar"}')
// Object {foo: "bar"}

لذلك ، التأكد من إرجاع كائن دائمًا في المستوى العلوي من الاستجابة يضمن أن JSON غير صالح لجافا سكريبت ، في حين لا يزال صالحًا JSON.

كما لاحظhvd في التعليقات ، فإن الكائن الفارغ {} صالح لجافا سكريبت ، ومعرفة أن الكائن فارغ ، فقد تكون هي نفسها معلومات قيمة.

مقارنة بين الأساليب المذكورة أعلاه

طريقة OWASP أقل تدخلاً ، حيث إنها لا تحتاج إلى أي تغييرات في مكتبة العميل ، وتنقل JSON صالح. ليس من المؤكد ما إذا كانت أخطاء المتصفح السابقة أو المستقبلية قد تهزم هذا الأمر. كما لاحظoriadam ، من غير الواضح ما إذا كان يمكن تسريب البيانات في خطأ تحليل من خلال معالجة خطأ أم لا (مثل window.onerror).

تتطلب طريقة Google من مكتبة العميل أن تدعم إلغاء التسلسل التلقائي ويمكن اعتبارها أكثر أمانًا فيما يتعلق بأخطاء المتصفح.

تتطلب كلتا الطريقتين تغييرات من جانب الخادم من أجل تجنب المطورين من إرسال JSON الضعيف عن طريق الخطأ.

513
Arnaud Le Blanc

هذا للتأكد من أن بعض المواقع الأخرى لا تستطيع القيام بحيل سيئة لمحاولة سرقة بياناتك. على سبيل المثال ، من خلال استبدال مُنشئ الصفيف ، ثم تضمين عنوان URL JSON هذا عبر علامة <script> ، يمكن أن يسرق موقع طرف ثالث ضار البيانات من استجابة JSON. بوضع while(1); في البداية ، سيتم تعليق البرنامج النصي بدلاً من ذلك.

طلب موقع واحد باستخدام XHR ومحلل JSON منفصل ، من ناحية أخرى ، يمكن بسهولة تجاهل بادئة while(1);.

354
bdonlan

قد يكون ذلك من الصعب على جهة خارجية إدراج استجابة JSON في مستند HTML بعلامة <script>. تذكر أن علامة <script> معفاة من نفس سياسة الأصل .

104
Daniel Vassallo

ملاحظة : اعتبارًا من عام 2019 ، لم تعد العديد من نقاط الضعف القديمة التي تؤدي إلى التدابير الوقائية التي تمت مناقشتها في هذا السؤال مشكلة في المتصفحات الحديثة. سأترك الإجابة أدناه باعتبارها فضولًا تاريخيًا ، ولكن الموضوع كله تغير فعليًا بشكل جذري منذ عام 2010 (!!) عندما تم طرح هذا السؤال.


يمنع استخدامه كهدف لعلامة <script> بسيطة. (حسنًا ، لا يمنع ذلك ، ولكنه يجعله غير سار.) وبهذه الطريقة لا يمكن للأشرار وضع علامة النص في موقعهم والاعتماد على جلسة نشطة لجعل المحتوى الخاص بك ممكنًا.

تحرير - لاحظ التعليق (وإجابات أخرى). تتعلق المشكلة بالتسهيلات المدمجة المضمّنة ، وتحديداً منشئي Object و Array. يمكن تغيير هذه بحيث JSON غير ضارة على خلاف ذلك ، عند تحليل ، يمكن أن تؤدي إلى رمز المهاجم.

72
Pointy

نظرًا لأن علامة <script> معفاة من "سياسة الأصل نفسه" التي تعد ضرورة أمنية في عالم الويب ، فإن while(1) عند إضافتها إلى استجابة JSON تمنع إساءة استخدامها في علامة <script>.

9
kg11