HttpOnly çerezleri AJAX istekleriyle nasıl çalışır?


195

AJAX çerezlere dayalı erişim kısıtlamaları olan bir sitede kullanılıyorsa JavaScript'in çerezlere erişmesi gerekir. HttpOnly çerezleri AJAX sitesinde çalışır mı?

Düzenleme: Microsoft, HttpOnly belirtilmişse, çerezlere JavaScript erişimine izin vermeyerek XSS saldırılarını önlemenin bir yolunu oluşturmuştur. FireFox daha sonra bunu benimsedi. Yani sorum şu: AJAX'ı StackOverflow gibi bir sitede kullanıyorsanız, Http-Only çerezleri bir seçenek midir?

Düzenleme 2: Soru 2. HttpOnly'nin amacı JavaScript'e çerezlere erişimi engellemekse ve yine de XmlHttpRequest Nesnesi aracılığıyla çerezleri JavaScript aracılığıyla alabilirsiniz, HttpOnly'nin amacı nedir?

Edit 3: İşte Wikipedia'dan bir alıntı:

Tarayıcı böyle bir çerez aldığında, aşağıdaki HTTP değişimlerinde her zamanki gibi kullanması, ancak istemci tarafı komut dosyalarına görünür kılmaması gerekir. [32] HttpOnlyBayrak herhangi bir standardın parçası değildir ve tüm tarayıcılarda uygulanmadı. Şu anda oturum çerezini bir XMLHTTPRequest yoluyla okumayı veya yazmayı engellemediğini unutmayın. [33].

document.cookieHttpOnly kullandığınızda bunun engellendiğini anlıyorum . Ancak, XMLHttpRequest nesnesindeki çerez değerlerini yine de okuyabileceğiniz ve XSS'ye izin verdiğiniz görülüyor. HttpOnly sizi nasıl daha güvenli hale getirir? Çerezleri temel olarak salt okunur yaparak?

Örneğinizde, size yazamıyorum document.cookie, ancak yine de çerezinizi çalabilir ve XMLHttpRequest nesnesini kullanarak alanımın içine gönderebilirim.

<script type="text/javascript">
    var req = null;
    try { req = new XMLHttpRequest(); } catch(e) {}
    if (!req) try { req = new ActiveXObject("Msxml2.XMLHTTP"); } catch(e) {}
    if (!req) try { req = new ActiveXObject("Microsoft.XMLHTTP"); } catch(e) {}
    req.open('GET', 'http://stackoverflow.com/', false);
    req.send(null);
    alert(req.getAllResponseHeaders());
</script>

Düzenleme 4: Maalesef, XMLHttpRequest öğesini StackOverflow etki alanına gönderebilir ve getAllResponseHeaders () sonucunu bir dizeye kaydedebilir, çerezi yeniden düzenleyebilir ve daha sonra bunu harici bir etki alanına gönderebilirsiniz. Görünüşe göre Wikipedia ve ha.ckers bu konuda benimle aynı fikirde, ancak yeniden eğitilmeyi çok isterim ...

Son Düzenleme: Ahh, görünüşe göre her iki site de yanlış, bu aslında FireFox'ta bir hata . IE6 ve 7 aslında şu anda HttpOnly'yi tam olarak destekleyen tek tarayıcıdır.

Öğrendiğim her şeyi tekrarlamak için:

  • HttpOnly IE7 ve FireFox'ta document.cookie'ye tüm erişimi kısıtlar (diğer tarayıcılardan emin değilim)
  • HttpOnly, IE7'deki XMLHttpObject.getAllResponseHeaders () öğesindeki yanıt başlıklarından çerez bilgilerini kaldırır.
  • XMLHttpObjects yalnızca kaynaklandıkları etki alanına gönderilebilir, bu nedenle çerezlerin etki alanları arası gönderimi yoktur.

edit: Bu bilgiler artık güncel değil.


Bir greasemonkey betiğinde örneğinizi attım ve FF artık çerez göstermiyor gibi görünüyor. Mükemmel araştırma ve örnek.

Belki Aynı Köken Politikası ile kodun çalıştığı ile aynı olmayan bir alana http isteği gönderemezsiniz; Ancak, kolayca kullanıcı window.location kullanarak bir sayfaya yönlendirerek çerezleri iletmek ve sorgu dizesi parametreleri aracılığıyla tüm bilgileri geçirmek inanıyorum.
Luca Marzi

@LucaMarzi "betiğin çalıştığı alanla http talep edemezsiniz " X sitesi Y sunucusundan bir görüntü içeremez mi diyorsunuz? (
Mosaic'ten

Yanıtlar:


64

Evet, Bu işlev için Yalnızca HTTP çerezleri kullanılabilir. Yine de XmlHttpRequest'in sunucuya isteği sağlanacaktır.

Yığın Taşması durumunda, çerezler otomatik olarak XmlHttpRequest isteğinin bir parçası olarak sağlanır. Stack Overflow kimlik doğrulama sağlayıcısının uygulama ayrıntılarını bilmiyorum, ancak bu çerez verileri muhtemelen kimliğinizi "oy" denetleyici yönteminden daha düşük bir seviyede doğrulamak için otomatik olarak kullanılır.

Daha genel, çerezler edilir değil AJAX için gerekli. XmlHttpRequest desteği (veya eski tarayıcılarda iframe uzaktan kumandası bile) teknik olarak gerekli olan tek şeydir.

Ancak, AJAX özellikli işlevsellik için güvenlik sağlamak istiyorsanız, geleneksel sitelerde olduğu gibi aynı kurallar geçerlidir. Her isteğin arkasındaki kullanıcıyı tanımlamak için bir yönteme ihtiyacınız vardır ve çerezler neredeyse her zaman bu amaçla kullanılabilir.

Örneğinizde, document.cookie'nize yazamıyorum, ancak yine de çerezinizi çalabilir ve XMLHttpRequest nesnesini kullanarak alan adımda gönderebilirim.

XmlHttpRequest alanlar arası istekte bulunmaz (tam olarak dokunduğunuz nedenlerden dolayı).

Normalde, çerezi iframe uzaktan kumandası veya JSONP kullanarak alan adınıza göndermek için komut dosyası enjekte edebilirsiniz, ancak daha sonra yalnızca HTTP erişilemediğinden çerezi tekrar korur.

Sunucu tarafında StackOverflow.com'u ele geçirmediyseniz, çerezimi çalamazsınız.

Düzenleme 2: Soru 2. Http-Only'nin amacı, çerezlere JavaScript erişimini önlemekse ve XmlHttpRequest Nesnesi aracılığıyla çerezleri JavaScript aracılığıyla almaya devam ediyorsanız, Http-Only'nin amacı nedir?

Şu senaryoyu inceleyin:

  • Sayfaya JavaScript kodu enjekte etmek için bir yol buluyorum.
  • Jeff sayfayı yükler ve kötü amaçlı JavaScript'im çerezini benimkine uyacak şekilde değiştirir.
  • Jeff, sorunuza mükemmel bir cevap verir.
  • Onun yerine çerez verilerimle gönderdiğinden, cevap benim olacak.
  • "Benim" yıldız cevabını oylarsın.
  • Asıl hesabım bunu anlıyor.

Yalnızca HTTP çerezleriyle ikinci adım mümkün olmaz, bu nedenle XSS girişimimi yenerim.

Düzenleme 4: Maalesef, XMLHttpRequest öğesini StackOverflow etki alanına gönderebilir ve ardından getAllResponseHeaders () sonucunu bir dizeye kaydedebilir, çerezi yeniden düzenleyebilir ve ardından bunu harici bir etki alanına gönderebilirsiniz. Görünüşe göre Wikipedia ve ha.ckers bu konuda benimle aynı fikirde, ancak yeniden eğitilmeyi çok isterim ...

Bu doğru. Yine de bu şekilde kaçırma oturumu yapabilirsiniz. Yine de, XSS'in size karşı saldırı yapmasını bile başarılı bir şekilde gerçekleştirebilen insan sürüsünü önemli ölçüde inceltir.

Benim örnek senaryo dönersem Ancak, nereye HTTP Okunur görebilirsiniz gelmez başarıyla müşterinin çerezleri (nadir değildir) modifiye itimat XSS saldırıları kesti.

Bu bir) tek gelişme çözecek gerçeğine aşağı kaynar bütün açıkları ve b) hiçbir sistem olacak zamankinden tamamen güvenli olması. HTTP Sadece bir XSS karşı payanda yararlı bir araç.

Benzer şekilde, XmlHttpRequest'teki web alanları arası kısıtlama, tüm XSS istismarlarını önlemede% 100 başarılı olmasa da, yine de kısıtlamayı kaldırmayı asla hayal edemezsiniz.


Birçok çerçeve csrf çerezlere simge koydu . Ben bir csrfçek ihtiyacı AJAX çağrı JS almak için gizli bir HTML öğesinde csrf belirteci koymak sürece işe yaramazsa varsayalım .
kullanıcı

4

Mutlaka değil, ne yapmak istediğinize bağlıdır. Biraz ayrıntı verebilir misiniz? AJAX'ın çalışmak için çerezlere erişmesi gerekmez, bilgi ayıklamak için kendi başına istekte bulunabilir, AJAX çağrısının yaptığı sayfa isteği çerez verilerine erişebilir ve Javascript'e doğrudan erişmek zorunda kalmadan arama komut dosyasına geri gönderebilir kurabiye


4

Evet, bunlar Ajax tabanlı bir site için uygun bir seçenektir. Kimlik doğrulama çerezleri komut dosyaları tarafından manipülasyon için değildir, ancak sunucuya yapılan tüm HTTP isteklerine tarayıcı tarafından eklenir.

Komut dosyalarının oturum çerezi ne söylediğinden endişe etmesine gerek yoktur - kimlik doğrulaması yaptığınız sürece, bir kullanıcı veya komut dosyası tarafından başlatılan sunucuya yapılan tüm istekler uygun çerezleri içerecektir. Komut dosyalarının çerezlerin içeriğini bilememesi önemli değildir.

Kimlik doğrulaması dışındaki amaçlar için kullanılan çerezler için, komut dosyasının bunları değiştirmesini veya okuyabilmesini istiyorsanız, bunlar yalnızca HTTP bayrağı olmadan ayarlanabilir. Hangi çerezlerin yalnızca HTTP olması gerektiğini seçebilir ve seçebilirsiniz, bu nedenle örneğin UI tercihleri ​​(sıralama düzeni, sol bölmeyi daralt veya küçültme) gibi hassas olmayan herhangi bir şey komut dosyalarıyla çerezlerde paylaşılabilir.

Sadece HTTP çerezlerini gerçekten seviyorum - bu gerçekten temiz bir fikir olan tescilli tarayıcı uzantılarından biridir.


3

Biraz daha var.

Ajax kesinlikle çerez gerektirmez, ancak diğer posterlerin de belirttiği gibi yararlı olabilir. Bir çerezi HTTPOnly, komut dosyalarından gizlemek için işaretlemek sadece kısmen çalışır, çünkü tüm tarayıcılar bunu desteklemez, aynı zamanda ortak geçici çözümler de vardır.

XMLHTTPresponse başlıklarının çerezi vermesi tuhaftır, teknik olarak sunucunun yanıtla çerezi döndürmesi gerekmez. İstemciye ayarlandıktan sonra, süresi dolana kadar ayarlanmış olarak kalır. Yine de, yeniden kullanımı önlemek için her istekte çerezin değiştirildiği şemalar vardır. Bu nedenle, sunucuyu XMLHTTP yanıtlarında çerez sağlamayacak şekilde değiştirerek bu geçici çözümü önleyebilirsiniz.

Genel olarak olsa da, HTTPOnly'nin dikkatle kullanılması gerektiğini düşünüyorum. Saldırganın bir kullanıcının XMLHTTP kullanmadan basit posta formları kullanarak başka bir siteden gelen ajax benzeri bir istek göndermesi için ayarladığı siteler arası komut dosyası saldırıları vardır ve tarayıcınızın hala etkin olan çerezi isteği doğrular.

Bir AJAX isteğinin doğrulandığından emin olmak istiyorsanız, isteğin kendisinin VE HTTP üstbilgilerinin çerezi içermesi gerekir. Örneğin, komut dosyaları veya benzersiz gizli girişler kullanarak. HTTPOnly bunu engelleyecektir.

Genellikle HTTPOnly'ı istemenin ilginç nedeni, web sayfanızdaki üçüncü taraf içeriğinin çerezleri çalmasını önlemektir. Ancak, üçüncü taraf içeriği dahil etme ve agresif bir şekilde filtreleme konusunda çok dikkatli olmanın birçok ilginç nedeni vardır.


1

AJAX araması yaptığınızda çerezler tarayıcı tarafından otomatik olarak ele alınır, bu nedenle Javascript'inizin çerezlerle uğraşmasına gerek yoktur.


1

Bu nedenle JavaScript'in çerezlerinize erişmesi gerektiğini varsayıyorum.

Tarayıcınızdan gelen tüm HTTP istekleri, söz konusu site için çerez bilgilerinizi iletir. JavaScript çerezleri ayarlayabilir ve okuyabilir. Tanımlama bilgileri, Ajax uygulamaları için tanım gereği zorunlu değildir, ancak çoğu web uygulamasının kullanıcı durumunu koruması için gereklidir.

Sorunuza ifade olarak verilen resmi yanıt - "AJAX kullanılıyorsa JavaScript'in çerezlere erişmesi gerekiyor mu?" - bu nedenle "hayır" dır. Örneğin, otomatik öneri seçenekleri sunmak için Ajax isteklerini kullanan gelişmiş arama alanlarını düşünün. Bu durumda çerez bilgisine gerek yoktur.


XmlHttpRequest çerezlere ihtiyaç duyar. Bahsettiğiniz gelişmiş arama bir giriş sayfasının arkasında olabilir. Ancak Javascript'in çerez değerini VM'ye göstermesi gerekip gerekmediği farklı bir sorudur.
Bay Parlak ve Yeni 宇 宇

1

Açıklama olarak - sunucunun bakış açısından, bir AJAX isteği tarafından istenen sayfa aslında bir bağlantıyı tıklatarak kullanıcı tarafından yapılan standart bir HTTP alma isteğinden farklı değildir. Tüm normal istek özellikleri: user-agent, ip, session, cookies, vb. Sunucuya iletilir.


"Oturum" bir HTTP konsepti değildir. Bir çerçeveyle HTTP kavramlarının üzerine inşa edilmiş üst düzey bir kavramdır.
curiousguy

0

Hayır, AJAX çağrısının istediği sayfa çerezlere de erişebiliyor ve oturum açıp açmadığınızı kontrol eden de bu.

Javascript ile başka kimlik doğrulaması yapabilirsiniz, ancak buna güvenmezdim, her zaman arka uçta herhangi bir kimlik denetimi kontrolü yapmayı tercih ederim.


0

Evet, çerezler Ajax için çok kullanışlıdır.

Kimlik doğrulamasını istek URL'sine koymak kötü bir uygulamadır. Geçen hafta, URL'lerde kimlik doğrulama jetonlarını google önbelleğinden almakla ilgili bir haber vardı.

Hayır, saldırıları önlemenin bir yolu yok. Eski tarayıcılar, javascript yoluyla çerezlere önemsiz erişime hala izin verir. Sadece http, vb. Atlayabilirsiniz. Ne olursa olsun size yeterli çaba verilen etrafında elde edilebilir. İşin püf noktası, değerli olmak için çok fazla çaba sarf etmektir.

Sitenizi daha güvenli hale getirmek istiyorsanız (mükemmel bir güvenlik yoktur) süresi dolan bir kimlik doğrulama çerezi kullanabilirsiniz. Ardından, çerez çalınırsa, saldırganın süresi dolmadan onu kullanması gerekir. Eğer iyi bir göstergeniz yoksa, o hesapta şüpheli bir etkinlik vardır. Zaman penceresi ne kadar kısa olursa güvenlik için o kadar iyi olur ancak sunucunuzda anahtar üretme ve bakımını yapma yükü artar.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.