1S1C: Cross Origin Resource Sharing (CORS), CSRF'e karşı bir tedbir olarak kullanılabilir mi?

Invicti Security Team - 08 Eylül 2017 -

Web güvenliğinde uyuyan dev olarak adlandırdığımız CSRF saldırılarının etkilerinden korunmak isteyen kişilerin sıkça sorduğu sorulardan bir tanesi "Cross Origin Resource Sharing mekanizmasını kullanarak bu saldırı tekniklerinden korunmak mümkün mü?" olmuştur. Bir çok güvenlik modelinin olması, konseptlere aşina olmayanlar için kafa karıştırıcı olabilmektedir

1S1C: Cross Origin Resource Sharing (CORS), CSRF'e karşı bir tedbir olarak kullanılabilir mi?

Öncelikle şunu not etmekte fayda var. Bu ve benzeri pek çok sorunun sebebi, temel olarak Same Origin Policy'nin doğru anlaşılmıyor oluşu. Hala pek çok yerde, üstelik Security Stack Exchange'de upvoted olmuş pek çok cevapta dahi şu iddiayı görebilirsiniz: "Same Origin Policy farklı origindeki sitelerin birbirlerine istek yapmasını engeller."

Oysa bu doğru bir iddia değil. SOP'un yönettiği, yalnızca farklı origine sahip iki sitenin, birbirlerinin kaynaklarına erişip erişemeyeceğidir.

Farklı origine sahip iki site birbirlerine istek yapabilir, ancak birbirlerinin DOM'larına erişemezler, başka bir deyişle, dönen yanıtı okuyamazlar.

Oysa CSRF'de ki durum farklıdır. Saldırganın CSRF ile ulaşmak istediği amaç, farklı origindeki bir sitenin yanıtını okumak değil, bizatihi o sitede bulunan kaynağa istek yapıp, state değişikliğine sebep olacak bir action tetiklemek. Bu yüzden CSRF'i blind ya da one-way attack olarak da anabiliriz.

Belki CSRF söz konusu olduğunda SOP'un kısıtlarından bahsedebileceğimiz tek yan, sitelerin CSRF ataklarına karşı token kullandıkları durumlardır.

Bu durumda bir A originindeki site B originindeki siteye yine istek yapabilir ancak, A originindeki site B originindeki sitenin DOM'una erişip, sayfa içeriğini dolayısıyla token bilgisini alamadığı için yapılan istek, eğer anti-CSRF mekanizması doğru bir biçimde implemente edildiyse, doğru token sağlanamadığı için saldırgan beklediği durum değişikliğine hedef sitede neden olamayacaktır.

Özetle CORS'un, güvenliği arttıran bir özellik olarak değil; SOP'un, farklı sitelerin birbirlerine istek yapmasına izin veren fakat yanıtlarını okumasına izin vermeyen kuralını esneten bir özellik olduğunu söyleyebiliriz.

CORS sayesinde farklı origindeki iki site birbirlerine istek yapıp, yapılan isteğin sonuçlarını görebilir. Eğer istek yapılacak sitenin konfigürasyonu izin veriyorsa, istek ile birlikte browserda saklanan cookie, basic authentication vb bilgiler gönderilebilir, istek yapan taraf -yine hedef site CORS konfigürasyonuna izin veriyorsa- custom headerlar set edebilir.

CORS'un yetkilendirme mekanizması, istek yapan sitenin set ettiği Origin headerı üzerinden yapılmaktadır. İstek yapan site kendini Origin headerı ile tanıtır. Hedef site ise CORS konfigürasyonunda hangi siteye izin veriyorsa, o sitenin originini Access-Control-Allow-Origin yanıt headerı ile birlikte whitelist eder. Konfigürasyon detayları için Same Origin Policy makalemize bakabilirsiniz.

Tüm erişim kontrollerinin Origin headerı üzerinden yapıldığını, yani browser’ın otomatik olarak istek yapan sitenin origin değerini istek headerındaki Origin alanına yazdığını ve yetki kontrolünün bununla yapıldığını belirttik. Soruda da belirtildiği üzere saldırgan bir HTTP isteği oluşturup, Origin değerini kendisi belirleyerek bunu aşamaz mı?

Evet aşabilir. Ama o durumda CSRF zafiyetini exploit etmiş sayılmayacaktır. CSRF zafiyeti, kurbanın browserı üzerinden, saldırgan tarafından hedef siteye isteklerin gönderilmesi ile gerçekleşmektedir. Çünkü sadece bu durumda kurbanın browserında -hali hazırda aktif olan- oturumuna dair bilgiler, istekle birlikte sunucuya gönderilir ve saldırgan bu açık olan oturumun istismarı vasıtası ile hedef sitede belirli sonuçları tetikletebilir.

Peki saldırgan kurbanı kendi sitesine girmeye ikna ederek, bu gezinim esnasında yine kurbanın tarayıcısı üzerinden arka planda hedef siteye istekler yollayıp bu isteklere de Origin headerını kendi belirleyeceği değerler ile ekleyemez mi? Hayır ekleyemez! Çünkü saldırgan kendi sitesi üzerinden farklı origindeki bir siteye istek yaptığında istek headerlarını kontrol edemez. XHR ile istek headerlarını değiştirebilmek mümkün fakat, Origin headerının XHR nesnesi ile değiştrilmesi modern browserlarda engellenen bir davranış. Örneğin aşağıdaki ekran görüntüsü Chrome web browserdan alındı:

Security Stack Exchange - CSRF

Dolayısıyla CORS 'un CSRF için bir güvenlik mekanizması olarak kullanılabileceğini söylemeyeceğiz.

Kaynak:

https://security.stackexchange.com/questions/97825/is-cors-helping-in-anyway-against-cross-site-forgery