6 Soru: Google neden bir süre önce hazırlıyor? JSON yanıtlarına?

tarafından oluşturulan soru Mon, Oct 30, 2017 12:00 AM

Google neden while(1);'u (özel) JSON yanıtlarına hazırlar?

Örneğin, Google Takvim 'de bir takvimi açıp kapatırken yanıt:

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

Bunun insanların eval() yapmasını engellemek olduğunu varsayardım, ancak tek yapmanız gereken while'u değiştirmek ve sonra kurulur. Değerlendirmeyi önlemenin, insanların güvenli bir JSON ayrıştırma kodu yazdığından emin olmak olduğunu varsayardım.

Bunun birkaç başka yerde de kullanıldığını gördüm, ancak Google’da (Posta, Takvim, Kişiler, vb.) Garip bir şekilde, Google Dokümanlar , bunun yerine &&&START&&& ile başlar ve Google Rehber, while(1); &&&START&&& ile başlıyor gibi görünüyor.

Burada neler oluyor?

    
3852
  1. İlk izleniminizin doğru olduğuna inanıyorum. Kodu aramaya başlar ve kaynağa bağlı olarak giriş akışını kesmeyi denerseniz, tekrar düşünür ve güvenli (ve Google'ın eylemleri nedeniyle) kolay bir şekilde yaparsınız.
    2010-04-19 18: 04: 25Z
  2. muhtemelen bir takip sorusu: google neden )]}' yerine while(1);'u hazırlıyor? Cevaplar aynı mı olurdu?
    2017-02-16 18: 51: 29Z
  3. eval'ü engeller, ancak sonsuz bir döngü olmaz.
    2017-05-06 20: 27: 42Z
  4. Bu )]}', baytları kurtarmak için de olabilir, facebook'ta kullanılan for(;;);, bir bayttan tasarruf eder :)
    2017-07-08 20: 55: 20Z
  5. json'un açıklanmasının engellenmesi, yani JSON hijacking
    2017-08-08 08: 05: 59Z
6 Yanıtlar                              6                         

Başlıca bir JSON güvenlik sorunu olan JSON kaçırılmasını önler resmi olarak düzeltildi ECMAScript 5 ile tüm büyük tarayıcılarda 2011 yılından beri

Anlaşmalı örnek: Google’ın, gelen kutunuzun ilk 50 mesajını JSON biçiminde döndüren, mail.google.com/json?action=inbox gibi bir URL’si olduğunu söyleyin. Diğer etki alanlarındaki kötü web siteleri, aynı köken politikası nedeniyle bu verileri almak için AJAX istekleri yapamaz, ancak URL’yi <script> etiketiyle ekleyebilirler. URL, çerezlerinizle ve genel dizi kurucusunu geçersiz kılarak ziyaret edilir. veya erişimci yöntemleri , bir nesne (dizi veya karma) özelliği ayarlandığında, JSON içeriğini okumalarını sağlayan bir yönteme sahip olabilirler.

while(1); veya &&&BLAH&&& bunu önler: mail.google.com'daki bir AJAX isteği metin içeriğine tam erişime sahip olacak ve onu kaldırabilir. Ancak, <script> etiket eklemesi JavaScript'i kör bir şekilde işlemden geçirmeden yürütür; bu da sonsuz bir döngü veya sözdizimi hatasıyla sonuçlanır.

Bu, siteler arası istek sahteciliği sahteciliği sorununu ele almamaktadır.

    
4108
2019-03-10 18: 30: 03Z
  1. Bu verileri alma isteği neden bunun yerine CSRF belirteci gerektirmiyor?
    2013-02-03 01: 43: 47Z
  2. for(;;); aynı işi yapar mı? Bunu facebook'un ajax yanıtlarında gördüm.
    2013-02-04 08: 27: 14Z
  3. @ JakubP. CSRF belirteçlerini Google ölçeğinde depolamak ve korumak, büyük miktarda altyapı ve maliyet gerektirir.
    2013-02-05 05: 12: 13Z
  4. @ JakubP. CSRF karşıtı belirteçler önbellekle uğraşır ve sunucu tarafında bir miktar kriptografik değerlendirme gerektirir. Google ölçeğinde çok fazla CPU gerektirir. Bu tür istemciye deşarj ediyor.
    2013-02-05 06: 10: 02Z
  5. Bana daha doğru bir yol ayarlanmışsa, sunucunun sadece JSON göndermesini sağlamak daha iyi bir yol gibi görünüyor. Bunu bir AJAX çağrısında yapabilirsiniz, ancak script etiketleriyle yapamazsınız. Bu şekilde, hassas bilgiler hiçbir zaman gönderilmez ve tarayıcı tarafı güvenliğine güvenmeniz gerekmez.
    2013-12-30 15: 06: 44Z

JSON kaçırma yoluyla yanıtın açıklanmasını önler.

Teoride, HTTP yanıtlarının içeriği Aynı Köken İlkesi tarafından korunmaktadır: bir etki alanındaki sayfalar diğer etki alanındaki sayfalardan hiçbir bilgi alamaz (açıkça izin verilmedikçe).

Bir saldırgan, sizin adınıza diğer alan adlarında sayfalar isteyebilir, ör. <script src=...> veya <img> etiketi kullanarak, ancak sonuç hakkında herhangi bir bilgi alamıyor (başlıklar, içerikler).

Dolayısıyla, bir saldırganın sayfasını ziyaret ederseniz, e-postanızı gmail.com adresinden okuyamadı.

JSON içeriği istemek için bir komut dosyası etiketi kullanıldığında, JSON'un saldırganın kontrol ettiği bir ortamda Javascript olarak yürütülmesi dışında. Saldırgan, Dizi veya Nesne yapıcısını veya nesne oluşturma sırasında kullanılan başka bir yöntemi değiştirebilirse, JSON'daki herhangi bir şey saldırganın kodundan geçer ve açıklanır.

Bunun, JSON'un ayrıştırıldığı zaman değil, Javascript olarak çalıştırıldığı sırada gerçekleştiğini unutmayın.

Birden fazla önlem var:

JSON'un asla çalışmadığından emin olma

Google, JSON verilerinden önce bir while(1); ifadesi koyarak, JSON verilerinin hiçbir zaman Javascript olarak çalıştırılmadığından emin olur.

Yalnızca meşru bir sayfa tüm içeriği alabilir, while(1);’u sorabilir ve geri kalanı JSON olarak ayrıştırır.

Örneğin, for(;;); gibi şeyler Facebook'ta da aynı sonuçlarla görüldü.

JSON'un geçerli olmadığından emin olma Javascript

Benzer şekilde, JSON'dan önce &&&START&&& gibi geçersiz belirteçler eklemek, asla yürütülmemesini sağlar.

JSON'u her zaman dışarıda bir Nesne ile geri döndürün

Bu, OWASP 'u korumanın tavsiye ettiği şekildedir JSON kaçırma ve daha az müdahaleci olanıdır.

Önceki karşı önlemlere benzer şekilde, JSON'un asla Javascript olarak çalıştırılmamasını sağlar.

Geçerli bir JSON nesnesi, hiçbir şey içine alınmadığında Javascript'te geçerli değildir:

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

Ancak bu geçerli JSON:

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

Dolayısıyla, her zaman cevabın en üstünde bir Nesne döndürdüğünüzden emin olmak JSON'un geçerli bir Javascript olmadığından ve hala geçerli JSON olduğundan emin olmanızı sağlar.

Yorumlarda @hvd tarafından belirtildiği gibi, boş nesne {} geçerli Javascript'tir ve nesnenin boş olduğunu bilmek değerli bilgiler olabilir.

Yukarıdaki yöntemlerin karşılaştırılması

OWASP yolu, istemci kütüphanesi değişikliği gerektirmediğinden ve geçerli JSON aktarımı gerektirdiğinden daha az müdahalecidir. Bununla birlikte, geçmiş veya gelecekteki tarayıcı hatalarının bunu yenebileceği kesin değildir. @Oriadam tarafından belirtildiği gibi, bir hata işleme sırasında bir ayrıştırma hatası durumunda verilerin (örneğin, window.onerror) sızdırılmış olup olmadığı açık değildir.

Google’ın yöntemi, otomatik seri hale getirmeyi desteklemesi için istemci kitaplığını gerektirir ve tarayıcı hataları konusunda daha güvenli olduğu düşünülür.

Her iki yöntem de, geliştiricilerin yanlışlıkla savunmasız JSON göndermelerini önlemek için sunucu tarafı değişiklikleri gerektirir.

    
522
2018-11-19 15: 44: 16Z
  1. OWASP önerisi sadeliği nedeniyle ilginç. Google’ın yolunun daha güvenli olmasının bir nedenini bilen var mı?
    2014-03-15 01: 47: 22Z
  2. Sanırım hiç bir şekilde daha güvenli olmadı . Burada OWASP sağlamak, +1 için yeterince iyi bir neden gibi görünüyor.
    2014-04-12 15: 54: 40Z
  3. Neden bir nesnenin değişmezini döndürmek script etiketini veya eval işlevini başarısız olduğunu belirtmekte fayda olabilir. Parantezler {}, bir kod bloğu veya bir nesne değişmezi olarak yorumlanabilir ve JavaScript kendi başına bir öncekini tercih eder. Bir kod bloğu olarak, elbette geçersiz. Bu mantıkla, gelecekteki tarayıcı davranışında öngörülen herhangi bir değişiklik göremiyorum.
    2015-11-08 10: 59: 26Z
  4. Hatalı kod yeterli değil, saldırganın tarayıcının komut dosyası-hata kodunu da kaçırmasına neden olabilir (window.onerror) onerror'un sözdizimi ile davranışının ne olduğundan emin değilim hatalar. Sanırım Google da emin değildi.
    2015-12-06 23: 06: 28Z
  5. "Geçerli bir JSON nesnesi, hiçbir şey içine alınmadığında Javascript'te geçerli değil:" - Boş bir nesnenin önemsiz durumu ({}) hariç geçerli bir boş bloktur. Nesnenin boş olduğunu bilmek, kendisinin değerli bilgileri olabilir, bu istismar edilebilir.
    2017-05-06 20: 50: 44Z

Bu, diğer bazı sitelerin verilerinizi çalmaya çalışmak için kötü hileler yapamamasını sağlamak içindir. Örneğin, dizi oluşturucuyu değiştirerek , ardından <script> etiketiyle bu JSON URL’sini dahil ederek Kötü niyetli bir üçüncü taraf sitesi, JSON yanıtındaki verileri çalabilir. Başlangıçta bir while(1); koyarak, komut dosyası yerine asılır.

Diğer yandan, XHR ve ayrı bir JSON ayrıştırıcısı kullanan aynı site isteği, while(1); önekini kolayca görmezden gelebilir.

    
356
2014-01-31 23: 43: 13Z
  1. Teknik olarak, bir ön ekiniz varsa "normal" bir JSON çözümleyici hata vermelidir.
    2009-05-16 03: 31: 20Z
  2. Saldırganlar XHR yerine yalnızca eski <script> öğelerini kullanırlar.
    2009-05-16 04: 22: 09Z
  3. @ Matthew, elbette, ancak verileri JSON ayrıştırıcısına aktarmadan önce kaldırabilirsiniz. Bunu <script> etiketiyle yapamazsınız
    2011-02-24 12: 54: 22Z
  4. Bunun bir örneği var mı? Dizi yapıcısını değiştirmek için tekrar başvuru yapılır, ancak bu uzun süren bir hatadır. Komut etiketi ile alınan verilere nasıl erişileceğini anlamıyorum. Son tarayıcıda çalışan sahte bir uygulama görmeyi çok isterim.
    2013-02-05 13: 37: 18Z
  5. @ joeltine, hayır, öyle değil. stackoverflow.com/questions/16289894/… .
    2013-06-03 19: 44: 04Z

Bu, üçüncü tarafın JSON yanıtını <script> etiketli bir HTML belgesine eklemesini zorlaştırır. <script> etiketinin Aynı Köken Politikasından muaf olduğunu unutmayın.

    
105
2013-12-30 03: 10: 45Z
  1. Bu yalnızca bir cevabın yarısıdır. Object ve Array kurucularını geçersiz kılma hilesi olmasaydı, sanki JavaScriptmiş gibi geçerli bir JSON yanıtı uygulamak her koşulda tamamen zararsız olurdu. Evet, while(1);, <script> etiketiyle hedeflendiğinde yanıtın JavaScript olarak yürütülmesini engelliyor, ancak yanıtınız bunun neden gerekli olduğunu açıklamıyor.
    2014-01-17 09: 37: 33Z
  2. ancak iframe'leri nasıl önleyecektir
    2016-08-03 16: 24: 25Z
  3. @ RavinderPayal <iframe> etiketleri aynı Köken Politikasından muaf değil ...
    2017-09-06 16: 28: 14Z
  4. Script etiketi hiçbir zaman aynı köken politikasından muaf değildir. Bunu benim için temizler misin?
    2018-06-03 14: 59: 17Z

Not : 2019 itibariyle, bu soruda tartışılan önleyici önlemlere yol açan eski güvenlik açıklarının çoğu, artık modern tarayıcılarda bir sorun değildir. Aşağıdaki cevabı tarihsel bir merak olarak bırakacağım, ancak gerçekten sorulduğunda 2010'un (!!) başından beri tüm konu köklü bir şekilde değişti.


Basit bir <script> etiketinin hedefi olarak kullanılmasını önler. (Eh, onu engellemez, ancak onu rahatsız edici kılar.) Bu şekilde kötü çocuklar bu komut dosyasını kendi sitelerine koyamazlar ve içeriğinizi getirmeyi mümkün kılmak için aktif bir oturuma güvenirler. p>

düzenle - yorumu (ve diğer yanıtları) not alın. Meselenin, özellikle Object ve Array inşaatçıları olan yıkık yerleşik tesislerle ilgisi var. Bunlar, aksi takdirde zararsız JSON'un ayrıştırıldığında saldırgan kodunu tetikleyebileceği şekilde değiştirilebilir.

    
77
2019-03-18 02: 52: 45Z
  1. Bu yalnızca bir cevabın yarısıdır. Object ve Array kurucularını geçersiz kılma hilesi olmasaydı, sanki JavaScriptmiş gibi geçerli bir JSON yanıtı uygulamak her koşulda tamamen zararsız olurdu. Evet, while(1);, <script> etiketiyle hedeflendiğinde yanıtın JavaScript olarak yürütülmesini engelliyor, ancak yanıtınız bunun neden gerekli olduğunu açıklamıyor.
    2014-01-17 09: 39: 17Z

<script> etiketi, web dünyasında bir güvenlik gereksinimi olan Aynı Kaynak İlkesi'nden muaf tutulduğundan, JSON yanıtına eklendiğinde while(1), <script> etiketinde kötüye kullanılmasını önler.

    
11
2018-08-28 09: 45: 57Z
kaynak yerleştirildi İşte