Soru CSRF: Bir çerez kullanabilir miyim?


Bir çerezde CSRF belirtecini koymak uygun mu? (ve her formda, gizli bir giriş olarak, yani eşleşip eşleşmediklerini kontrol edebilirim, tabii ki) Birinin bunu yaptıklarını söylediğini duydum, ama nedenini anlamıyorum. Bana güvenli görünüyor.

Ve eğer güvenli ise, URL'lerde belirteci koymaktan daha az güvenli midir?

Başka bir yöntem var mı?

Konu hakkında daha fazla bilgiyi nerede okuyabilirim?

GÜNCELLEŞTİRME: Şimdiye kadar kimsenin bana nasıl bir kodlama yöntemi güvensiz olduğunu söyleyemem, eğer hala formun belirteci ile eşleşmesi gerekiyorsa, saldırganın elde edememesi gereken, XSS gibi başka bir hack kullanmıyorsa, bu farklı bir durumdur. Sorun, çerez ve url belirtecini kullanma arasında hala fark yaratmıyor.

GÜNCELLEME 2: Tamam, bazı ünlü çerçeveler bu yöntemi kullanıyor gibi görünüyor, bu yüzden iyi olmalı. Teşekkürler


20
2017-12-16 17:07


Menşei


Çift gönderimli çerezler yaklaşımı çalışır, ancak güvenlik sonuçları böyle bir yaklaşımın - Gili


Cevaplar:


Çerezlerin kullanımı çalışır ve yaygın bir uygulamadır (ör. G. Django kullanıyor). Saldırgan aynı başlangıçtaki ilke nedeniyle cookie değerini okuyamaz veya değiştiremez ve bu nedenle doğru GET / POST parametresini tahmin edemez.


18
2017-12-16 22:32



ÖNEMLİ: Sunucu her zaman form tarafından sunulan CSRF değerinin ve çerez aracılığıyla alınan değerin eşleştiğini kontrol etmelidir. Sunucu, POST (veya GET) verileriyle çerezden veriyi kontrol etmedikçe CSRF koruması çalışmaz. - Mikko Rantalainen
@MikkoRantalainen bu önemli değil. onun çok önemli- aksi halde, devils, çerezleri gönderilecek ve yetkilendirilecek olan "hesap bağlantılarımı sil" gönderebilir. Yani bir eşleşme yapılmalı. - Royi Namir
Anlamadığım: Kötü amaçlı bir web sitesine sahip bir saldırgan, çerezi okumak için JavaScript kullanamaz mı? Tarayıcı varsayılan olarak diğer web siteleri için çerezleri okumaya izin vermiyor mu? - Zelphir
@Zelphir yep, dediğim gibi aynı menşe politikası. - Tgr


Kontrol et Şifreli Jeton Modelisunucuda jeton saklamak zorunda kalmadan vatansız CSRF korumasına izin verir.


1
2017-09-23 09:37





"CSRF çalışır çünkü birçok site komutları yürütmek için GET isteklerini kullanır."Bu nedenle, birçok site beklendiği gibi GET yöntemini kullanmaz, çünkü bu istek idempotent olmalıdır: rfc2616'ya bakın.

"CSRF parametresi çerezde zaten var ve oturumla birlikte gönderiliyor.", nasıl?

Çerez, yalnızca gizli bir giriş alanında jetonu belirlediğimizde DOM olarak bir simge saklama alanına sahiptir. Bir javascript parçası, bu çerezden belirteç değerini almalı ve URL'de, istek gövdesinde veya istek başlığında bir parametre olarak ayarlamalıdır. Sunucuda oturumda saklanan değerle kontrol edilecektir. Bu, CSRF belirtecini işlemek için Django yoludur.

Javascript, etki alanı tarayıcı koruması nedeniyle başka bir alan adından çereze erişemez. Bu nedenle, kötü niyetli bir kullanıcının bir kullanıcıyı bir dövme isteği boyunca doğru simgeyi göndermesine nasıl zorlayacağını bilmiyorum. Bir XSS ile, evet, ancak XSS, ortak CSRF karşı önlemlerini yener.

Bu açıklamayı vermeyi tercih ediyorum, çünkü bunun önemli bir soru olduğunu ve işlemek kolay olmadığını düşünüyorum.


GET isteği şart Bir kaynağı almak ve / veya verilerini görüntülemek için kullanılır. Yapmamalısın durumunu değiştirmek için kullanılır (silme, özellik artışı veya herhangi bir değişiklik).

CSRF doğrulama şart sunucu tarafında yapılacak, açık gibi görünüyor, ama bir hatırlatma olarak koydum. Bu yönteme uyuyorsanız, bu yöntem bir saldırı vektörü olamaz.


0
2018-02-25 21:17



Bunu not et idempotent != safe. Örneğin GET http://example.com/api/item/123/delete idempotent uygulanabilir (yani, GET 1,2,3, ... veya N kez gönderilirse, sonuç aynıdır). - Mikko Rantalainen
"idempotent uygulanmış olabilir", ancak şunları yapmamalı: bu silme son noktasına bir çağrıdan sonra durum değişti ve HTTP 202 Kabul edildi (kaynak silinmediyse / değiştirilmediyse), 200 Tamam değil başarılı bir şekilde silindi). En iyi uygulamalar vardır ve bu nedenle, bir GET, bir kaynağın mevcut temsilini çıkaran hiçbir şey için asla kullanılmamalıdır. - Dinacel
Buna katılıyorum GET  meli Sadece görünen yan etkilere sahip olmayan istekler için kullanılır, ancak HTTP spekülatörünü okuyan biri, daha fazla efekt sağlayan "idempotent" parçasını takip ediyor olabilir. - Mikko Rantalainen
@David: Bu idempotentin anlamı değil. Çıkış yapmak HTTP yöntem tanımlama belirtimi. Spesifikasyona göre PUT ve DELETE idempotenttir ancak güvenli yöntem değildir. - Lie Ryan


CSRF jetonunu bir çerez içine koymaya karar verirseniz, o çerezi şu şekilde işaretlemeyi unutmayın. HttpOnly. Sitenizde siteler arası bir komut dosyası güvenlik açığı varsa, bilgisayar korsanı CSRF belirtecini okuyamayacaktır. JavaScript ile okunabilen çerezleri kontrol ederek kontrol edebilirsiniz. console.log(document.cookie)herhangi bir modern tarayıcı konsolunda. Oturum çerezleriniz veya başka hassas çerezleriniz varsa, bunlar da şu şekilde işaretlenmelidir: HttpOnly.

Daha fazla okuma:

https://www.owasp.org/index.php/HttpOnly


0
2017-11-17 08:27



Jetonu daha sonra istemci tarafında üstbilgi (= Double Submit) ile birlikte göndermek için nasıl okurdunuz? CSRF Jetonunu korumalı bir tanımlama bilgisine koymak, yalnızca sunucu aynı zamanda gizli bir giriş alanına sahip bir form da belirdiğinde mümkündür. Birçok API, form sağlamaz. Bu nedenle, CSRF jetonunu Javascript ile okuyabilmeniz gerekir. Sanırım bir kişi daha iyi bir XSS güvenlik açığı içermediğinden emin oluyor. - Christian Benke
@ChristianBenke Neden sunucuyu bilmek zorunda olduğu belirteç de dahil olmak üzere sunucu tarafında formu oluşturmadı? Yoksa, bir şablonun artık işe yaramayacağı yüksek düzey çerçeveler mi kastediyorsunuz, bu da formdaki belirteç değerini içerecek şekilde işlevsellik sağlamıyor mu? - Zelphir
@Zelphir "istemci tarafı" yazdım. Yani örneğin bir REST-API'niz varsa, sunucu tarafından hiçbir şablon ve form sağlanmaz. - Christian Benke
HttpOnly, XSS saldırılarını önlemek için oturum kimliklerini saklayan çerezler için mutlak bir zorunluluktur, ancak CSRF başka bir sorundur. CSRF'yi önlemek için istemci, CSRF belirtecini, bir formdaki gizli bir alanda olup olmadığını veya JavaScript aracılığıyla bir ajax çağrısının üstbilgisi olarak eklenmiş olduğunu bilmelidir. - tybro0103


Bir çerez kullanmak CSRF'nin amacını ortadan kaldırır. İşte nedeni:

CSRF çalışır çünkü birçok site komutları yürütmek için GET isteklerini kullanır. Öyleyse Bob'un bir çeşit yönetici web hesabı var ve o da giriş yaptı. Bazı talepler şöyle yapılabilir:

http://somesite.com/admin/whatever.php?request=delete_record&id=4

Yani şimdi Bob bir saldırı yerine bağlıyor (birisi veriyle uğraşmaya çalışıyor). Saldırgan daha sonra yukarıdaki URL'yi bir görüntüde, muhtemelen başka bir ID ile yükler ve başka bir kaydı siler. Tarayıcı, Bob zaten yönetici sitesine girdiği için geçerli bir oturum açtığı için onu yükler.

CSRF, işlem için güvenli bir parametre ekleyerek bunu ortadan kaldırmayı amaçlamaktadır. Bu parametre her istekte dönmeli ve tarayıcı tarafından yeniden gönderilmelidir. URL'nin yapılması şöyle bir şeye benziyor:

http://somesite.com/admin/whatever.php?request=delete_record&id=4&csrf=<some long checksum>

Buradaki fikir şu ki, saldırganın bir saldırı oluşturmak için "bazı uzun sağlama toplamı" olduğunu tahmin etmesi gerekiyor. Ve eğer bu sağlama toplamı her istekte iyi dönerse, neredeyse imkansız olmalıdır.

AMAÇ Bu sağlama toplamını bir çerezde depolarsanız kare 1'e geri dönersiniz. Saldırganın artık bunu tahmin etmesi gerekmiyor. Sadece orijinal URL'yi hazırlıyor. CSRF parametresi çerezde zaten var ve oturumla birlikte gönderiliyor. Güvensiz davranışların gerçekleşmesini engellemez.


-2
2017-12-16 17:17



Bunun mükemmel bir cevap olduğunu görmüyorum, eğer saldırganın sadece orijinal URL'ye ihtiyacı olduğunu söylüyorsa: Yine, saldırganın form jetonu ve çerez jetonu eşleşmesi nasıl olacak? Sitem XSS'e karşı hassassa, tamamen farklı bir şey ve hala URL'lerde belirtecin kullanılmasından daha az güvenli olacağını görmüyorum. Saldırgan, belirteci XSS aracılığıyla formdan alabilirse, URL’den de alabilir. Yanlış mıyım? - HappyDeveloper
@HappyDeveloper - Evet CSRF POST ile de olabilir. GET daha yaygın çünkü daha kolay. Form belirteci, çerezde gösterilecek herşeyle eşleşmelidir. Yani saldırganın hiçbir şey yapması gerekmiyor. Sadece isteği geri gönderir ve çerez sunucunuz tarafından okur. - Cfreak
@HappyDeveloper neler olup bittiğine dair hiçbir fikriniz yok. Lütfen CSRF'nin en temel tanıtımını ve OWASP CSRF önleme hile sayfasını okuyun. - rook
@Cfreak Ayrıca POST tabanlı CSRF istismarlar eşit olarak eşittir ve GET olarak istismar etmek kadar kolaydır. Sen sadece ara document.getElementById(1).submit() formu görüntülendiğinde otomatik olarak göndermek için - rook
HappyDeveloper'ın ALSO'nun bir HTTP parametresi (gizli form alanı aracılığıyla) yoluyla jetonu iletmeyi ve ardından çereze karşı çapraz kontrol etmeyi amaçladığı (sorunun en azından güncel versiyonundan) açıktır. Bu, CSRF saldırılarını önlemek için tamamen kabul edilebilir bir yoldur. Ayrıca, çerezden kod çalmak için XSS kullanarak hackerlar hakkında endişelenmeyin. Bir saldırgan sitenize XSS yerleştirebilirse, CSRF'nin daha önce XSS sorununu ele alması gerektiği konusunda daha büyük endişeleriniz vardır. - Eadwacer