CORS ile XSS ve CSRF Engellenebilir mi?

Cross-Origin Resource Sharing önlemleri ile XSS ve CSRF zafiyetlerinin giderilebileceği düşünülmektedir fakat konu tarayıcı olunca bunun ne kadar mümkün olabileceğini SOP, CORS ve XSS’i inceleyerek ele alacağız.

CORS’u anlamak için öncesinde SOP’a (Same Origin Policy) bakmak gerekir çünkü  herhangi bir domainin yine kendi servislerine erişimi için bir dizi kurallar SOP ile belindi. Bunları anlamak CORS yapısını anlamak için oldukça önemlidir. Ardından CSRF ve XSS inceleyerek CORS tarafındaki bağlantılarını göreceğiz.

CORS’u Anlamak için SOP’u Anlamak

Bilindiği gibi DOM (Document Object Model) sayesinde JavaScript ile tarayıcıya yüklenmiş HTML, Cookie, Session, URL gibi bilgilere erişilebilmektedir. Konu erişim olunca bazı kısıtlamalara ihtiyaç duyulmuştur. Bununla ilgili tarayıcılar hangi durumlarda erişime izin verilip verilmeyeceğini belirlemek için SOP politikalarını belirlerler. Kurallar belirlenirken subdomain, domain, port kontrol edilir ve erişime izin verilip verilmeyeceği belirlenir. Burada özellikle belirtmedik ama http/https 80 ve 443 gibi farklı portlar kullandığından port kurallarına dahil edilebilir.

Örneğin;
http://www.websitem.com/index.html üzerinden erişebileceğiniz kaynaklardan bazıları şunlardır:

http://www.websitem.com/test.html
http://www.websitem.com/dizin/test.html

Fakat aşağıdaki kaynaklara erişemezler (IE’de özel durumlar var):

http://websitem.com/index.html
https://www.websitem.com/index.html
http://www.websitem.com:88/index.html

Erişilemeyen Kaynaklara Erişmek için CORS

Peki bu kaynaklara erişmeniz gerekseydi bu durumda ne yapmak gerekirdi? İşte bu sorunun yanıtı olarak CORS devreye girer ve farklı origin’lerdeki kaynaklara erişmemizi sağlamak için belirli “header” değerleri sunar. Bu header’lar vasıtası ile sitenizin kaynaklarına hangi origin’lerden erişilebileceğini belirleyebilirsiniz.

http://websitem.com/index.html sitesine http://edu.websitem.com/index.htmlsitesinden erişmelerine izin vermek için eklenmesi gereken header’lar şunlardır:

Access-Control-Allow-Origin: edu.websitem.com
veya
Access-Control-Allow-Origin: *.websitem.com

Herhangi bir siteden erişime izin vermek için de “*” şeklinde kullanabilirsiniz:

Access-Control-Allow-Origin: *

Aynı zamanda izin verilen istek türleri olan get, post, head vb., ekstra header tagları ve geçerlilik süresi de belirtilebilir.

Access-Control-Allow-Origin: *.websitem.com
Access-Control-Allow-Methods: POST, GET, OPTIONS
Access-Control-Allow-Headers: X-PINGARUNER
Access-Control-Max-Age: 1728000

İstek yapan tarafta ise aşağıda belirtilenlere özel durumlar için kullanılan ekstra header’lar da (ekstra header’lar için yukarıdaki örnekte “X-PINGARUNER” olduğu gibi izin verilmiş olmalıdır) eklenerek istek gönderebilir:

Accept
Accept-Language
Content-Language
Content-Type

CORS ve SOP ile ilgili detaylı bilgiye Netsparker tarafından hazırlanan Same Origin Policy yazısından bakabilirsiniz.

CSRF (Cross-site Request Forgery)

CSRF anlamı itibari ile siteler arası istek sahteciliğidir. Ziyaret ettiğiniz site oturumunuzun açık olduğu diğer bir sitedeki alanı değiştirmeye çalışır. Bunun için sadece bir url çağırması bazen yeterli olacaktır. Eğer başarılı olur ise oturumunuzun açık olduğu sitede işlem gerçekleşir ama CORS nedeniyle işlemin sonucu size bildirilmez. Amaç zaten ilgili işlemi yapmak olduğundan işlem cevabının size dönüp dönmemesinin de bir anlam yoktur.

Bu durumu bir örnek ile açıklayalım. Saldırganın A sitesinde bulunan üyenin mail adresini değiştirmeye çalıştığını ve oturumunuzun açık olduğunu varsayalım. Oturumunuz açık olduğu için site sizden kullanıcı adı ve parola gibi bilgiler istemeyecek ve istek bilgisayarınızdan gittiği için de işlemi gerçekleştirecektir.

Örnek senaryomuz da A sitesine (https://edu.sekuri.net/csrf/) oturumunuz açık ve siz B sitesini (https://sekuri.gitlab.io/csrf/) ziyaret ettiniz.

B sitesinde yer alan kod ile CSRF atak yapılmış ve sizin bilginiz olmadan hesaba giriş  için kullanılan mail adresi değiştirilmiş ve hesap ele geçirilmiş olacaktır:

<img src="https://edu.sekuri.net/csrf/?page=changemail&[email protected]" />

İşlem <img>tagı ile yapıldığından siteden dönen değer hata mesajı dahi olsa kurban tarafından görüntülenemeyecektir. Durumun daha iyi anlaşılması için atağın yapıldığı sayfaya (B sitesi) mesaj ekledik.

CSRF Atak öncesi durum: https://edu.sekuri.net/csrf/ (mail adresine dikkat ediniz)

Atağı başlatmak için: https://sekuri.gitlab.io/csrf/

NOT: CSRF ataklarının önlenmesi için alınabilecek en temel önlem “csrf token” ile her formun oluşturulması sırasında benzersiz bir değer oluşturarak formun gönderilmesinden sonra bu değerin kontrol edilmesidir. Detaylı bilgi için OWASP’ın CSRF Prevention Cheat Sheet sayfasını ziyaret edebilirsiniz.

XSS Türleri ve Çalışma Şekli

Bilindiği üzere Cross-site Scripting DOM tarafında ve JavaScript engine kullanarak çalışan bir script enjeksiyon işlemidir ve Stored XSS, Reflected XSS  ve DOM Based olmak üzere üçe ikiye ayrılır.

Stored ve Reflected arasındaki en belirgin özellik Stored adından da anlaşılacağı üzere sitenin herhangi bir kayıt formundan girilen XSS Payload’ının kaydedilmesidir. Böylelikle ilgili sayfayı / profili ziyaret eden kullanıcılar bu zafiyetten etkilenirler.

Reflected ise girilen XSS Payload’ın herhangi bir filtresinden geçirilmeden tekrar kullanıcıya gönderilmesi ile anlık olarak veya hash-bang (http://websites.com/profile.php?test#http://attacker.com/xss.php) ile sunucuya istek gönderilmeden de gerçekleşir. Reflected XSS’de hazırlanan url kullanıcıya gönderildikten sonra tıklamasını beklenmektedir.

DOM Based XSS payload DOM’da gerçekleşir ve kaynak koda baktığınızda oluşan işlemi göremezsiniz. Stored ile birleştirilir ise bu durumda ilgili javascript  kodlarını göremeniz mümkün olacaktır.

Örneğin:
http://www.some.site/page.html#default=<script>alert(document.cookie)</script>

XSS ile yapılan atakların önlenmesi ile ilgili OWASP’ın XSS Prevention Cheat Sheet sayfasını ziyaret edebilirsiniz.

Sonuç

Anlatılanlardan da görüleceği üzere CSRF ve XSS saldırgan tarafından hazırlandığından ikinci bir siteye isteğin gönderilmesini gerektirse bile ilgili sitede gerekli izinler verileceğinden CORS cevaplarına uygun yanıtlar dönecektir. Bu nedenle CORS politikalarının CSRF ve XSS ataklarını engelleyemeyeceği sonucunu çıkarabiliriz.

 

Bir cevap yazın

E-posta hesabınız yayımlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir

This site uses Akismet to reduce spam. Learn how your comment data is processed.