JSON ile CSRF POST
JSON isteklerini kabul eden bir test uygulaması ile oynuyorum ve yanıt da JSON. Ben sadece = POST yöntemi istek ile JSON veri kabul eden bir işlem için bir CSRF yapmaya çalışıyorum. URL get yöntemi (örn. <script src=).
Ayrıca saldırının anlamlı olması, yani işlemin gerçekleşmesi için, verileri istekte göndermem gerekiyor. Kendi sayfamı oluşturup JSON isteklerini gönderirsem, çerezler seyahat etmez ve bu nedenle sunucu kimliği doğrulanmamış bir hata iletisi döndürür.
Sunucu tarafından yapılan orijinal istekte rastgele belirteçler yoktur.
Bu senaryoda başarılı bir CSRF saldırısı gerçekleştirmenin herhangi bir yolu olduğunu merak ediyordum.
En azından istekte Content-Type: application/json olup olmadığını kontrol etmelisiniz.
<form> ile bir istek göndermek için POSTed Content-Type: application/json almak mümkün değildir. Ancak, gövde içinde geçerli bir JSON yapısına sahip bir formu enctype="text/plain" olarak gönderebilirsiniz.
Çapraz olmayana karşı Content-Type: application/json ile çapraz Kökeni ( CORS ) XMLHttpRequest POST yapmak mümkün değildir -Origin-farkında sunucu, çünkü bu bir 'uçuş öncesi' HTTP SEÇENEKLERİ isteğini önce onaylamak neden olur. Ancak, eğer text/plain ise, Kaynaklar Arası XMLHttpRequest POST withCredentials gönderebilirsiniz.
Yani application/json kontrolünde bile, tamamen orada değilse, XSRF'ye oldukça yaklaşabilirsiniz. Bunu güvence altına almak için güvendiğiniz davranışlar biraz belirsiz ve hala Çalışma Taslağı aşamasında; web'in geleceği için zor ve hızlı garantiler değildir.
Bunlar, örneğin gelecekteki bir HTML sürümündeki formlara yeni bir JSON enctype eklenirse kırılabilir. (WHATWG, HTML5'e text/plain şifrelerini ekledi ve başlangıçta text/xml eklemeye çalıştı, bu yüzden bunun gerçekleşmesi söz konusu değil.) Daha küçüklerinden ödün verme riskini artırıyorsunuz. , incelikli tarayıcı ve CORS uygulamasında eklenti hataları.
Şimdilik muhtemelen bundan kaçabilirken, uygun bir anti-XSRF token sistemi olmadan ilerlemenizi kesinlikle tavsiye etmem.
Bu, Flash kullanarak kullanılabilir ( https://code.google.com/p/browsersec/wiki/Part2#Same-Origin_policy_for_Flash
Çerez taşıyan web alanları arası HTTP GET ve POST tarayıcı yığını üzerinden istekte bulunma yeteneği, tarayıcılarda normalde başka bir yerde göründüğünden daha az kısıtlama ile gerçekleşir. en önemlisi, keyfi İçerik Türü değerlerini belirleme ve ikili yükleri gönderme yeteneğini içerir.
Kendim test etmedim ama kulağa mantıklı geliyor.
Güncelleme: Görünüşe göre en son Flash sürümleri artık varsayılan olarak herhangi bir web alanları arası isteklere izin vermiyor ve bu da kullanılamaz hale geliyor.
Güncelleme # 2: Bununla birlikte, flaşın 307 yönlendirmelerini ele almasında uzun süredir devam eden bir güvenlik açığı var, bu da bunun hala kullanılabilir olduğu anlamına geliyor