Aynı Kök Politikası
Aynı kök politikası web uygulamaları güvenlik modelinde önemli bir unsurdur. Bu politikaya göre, bir web tarayıcısı, bir web sayfasında yer alan betiklerin ikinci bir web sayfası üzerindeki veriye erişimine sadece bu iki sayfa aynı köke sahipse izin vermektedir. Bir kök, URI şeması, hostname ve port numarasının bir kombinasyonu olarak tanımlanmaktadır. Bu politika, bir sayfada bulunan kötücül betiğin başka bir sayfada bulunan hassas verilere erişimini, o sayfanın Belge Nesnesi Modeli aracılığıyla engellemektedir.
Bu mekanizma, kimlik doğrulaması yapılmış kullanıcı oturumlarını yönetmek için yoğun bir şekilde HTTP çerezlerine[1] dayanan modern uygulamalar için özel bir önem taşımaktadır. Bunun nedeni, sunucuların hassas bilgileri göndermek ve durum değiştiren aktiviteleri yapmak için HTTP çerez bilgilerine dayanmasıdır. Birbiri ile bağlantısı olmayan sitelerin sağladığı içerikler arasında betik ayırımı, gizlilik ve bütünlük açısından herhangi bir kayba neden olunmaması için istemci tarafında yapılmalıdır.
Tarihi[değiştir | kaynağı değiştir]
Aynı kök politikası kavramı 1995 yılındaki Netscape Navigator 2'ye dayanmaktadır. Bu politika başlarda Belge Nesnesi Modeline (DOM) erişimi korumak için tasarlanmış olsa da, kök JavaScript nesnelerinin hassas kısımlarını koruyacak şekilde genişletilmiştir.[2]
Uygulama[değiştir | kaynağı değiştir]
Bütün modern tarayıcılar, güvenlik açısından önemli bir temel taşı olduğu için bir şekilde Aynı Kök Politikası'nı uygulamaktadır.[3] Bu politikalar kesin bir tanıma[4] uymak zorunda değildir, ancak genelde Microsoft Silverlight, Adobe Flash veya Adobe Acrobat gibi diğer web teknolojileri için veya XMLHttpRequest gibi doğrudan DOM değişimi için olmayan diğer mekanizmalar için, kabaca uyarlanabilir güvenlik sınırları tanımlayacak şekilde genişletilmiştir.
Kök belirleme kuralları[değiştir | kaynağı değiştir]
bir URI'ye ait "kök" belirlenirken kullanılan algoritma RFC 6454'ün 4. Kısmı'nda tanımlanmaktadır. Tam URI'ler için {protokol, host, port} üçlüsü köktür. Eğer URI bir isimlendirme otoritesi (RFC 3986 3.2. Kısma bakınız) olarak hiyerarşik bir yapı kullanmıyorsa veya URI bir tam URI değilse, genel benzersiz tanımlayıcı (GUID) kullanılır. İki kaynak sadece ve sadece tüm bu değerler birebir aynı ise aynı kökten sayılmaktadır.
Örnek olarak, aşağıdaki tablo "http://www.example.com/dir/page.html" URL'i için yapılan kontrollerin sonuçlarını göstermektedir.
| Karşılaştırılan URL | Sonuç |
Nedeni |
|---|---|---|
| http://www.example.com/dir/page2.html | Success | Aynı protokol, host ve port |
| http://www.example.com/dir2/other.html | Success | Aynı protokol, host ve port |
| http://username:password@www.example.com/dir2/other.html | Success | Aynı protokol, host ve port |
| http://www.example.com:81/dir/other.html | Failure | Aynı protokol ve host, ancak farklı port |
| https://www.example.com/dir/other.html[ölü/kırık bağlantı] | Failure | Farklı protokol |
| http://en.example.com/dir/other.html | Failure | Farklı host |
| http://example.com/dir/other.html | Failure | Farklı host (birebir eşleşmesi gerekmektedir) |
| http://v2.www.example.com/dir/other.html | Failure | Farklı host (birebir eşleşmesi gerekmektedir) |
| http://www.example.com:80/dir/other.html | Depends | Port açıkça yazılmış. Tarayıcı uygulamasına göre değişir. |
Diğer tarayıcıların aksine, Internet Explorer kök belirlemesinde port yerine Security Zone özelliğini kullanmaktadır.[5]
Güvenlik Uygulamaları[değiştir | kaynağı değiştir]
Aynı kök politikası, kimlik doğrulaması yapılmış oturumları kullanan sitelerin korunmasına yardım etmektedir. Bahsedilecek örnek, aynı kök politikası olmadığında oluşabilecek olası güvenlik riskini örneklemektedir. Bir kullanıcının bir bankacılık uygulamasını kullandığını ve sonrasında çıkış yapmadığını varsayalım. Sonrasında kullanıcı, bankacılık sitesinden veri isteyen ve arka planda çalışan kötücül JavaScript kodu çalıştıran başka bir siteye gitmiştir. Kullanıcı bankacılık uygulamasında oturumunu kapatmadığı için, kötücül kod kullanıcının bankacılık sitesi üzerinde yapabileceği her şeyi yapabilmektedir. Örneğin, kullanıcının son işlemlerini listeleyebilir, yeni bir işlem yapabilir, vb. Bunun nedeni, tarayıcının bankacılık sitesinin alan adına bağlı olarak bankacılık sitesine oturum çerezlerini gönderebilmesi ve oturum çerezleri alabilmesidir.
Kötücül siteyi ziyaret eden kullanıcı, ziyaret ettiği sitenin bankacılık oturum çerezlerine erişemeyeceğini beklemektedir. JavaScript kodunun doğrudan bankacılık uygulaması çerezlerine erişiminin olmadığı doğru olsa da, yine de bankacılık sitesinin oturum çerezleri ile bankacılık sitesine istek gönderebilmekte ve bu siteden cevap alabilmektedir. Betik temelde kullanıcının yapabileceği her şeyi yapabildiği için, bankacılık sitesi tarafından uygulanan CSRF koruma yöntemleri bile faydasız olmaktadır.
Aynı kök politikasının esnetilmesi[değiştir | kaynağı değiştir]
Bazı durumlarda aynı kaynak politikası, birden fazla alt alan adı kullanan büyük web siteleri için çok kısıtlayıcı olarak problem oluşturabilmektedir. Aşağıda bu politikayı esnetmek için kullanılan bazı teknikler verilmiştir:
document.domain özelliği[değiştir | kaynağı değiştir]
Eğer iki pencere (veya çerçeve) alan adını aynı değer olarak belirleyen betikler içeriyorsa, bu iki pencere için aynı kök politikası esnetilir ve pencereler birbirleriyle haberleşebilir. Örneğin, orders.example.com ve catalog.example.com üzerinden yüklenen dokümanlardaki betikler, document.domain özelliklerini "example.com" olarak belirleyebilir ve böylece dokümanların aynı kökü paylaşmasını ve her bir dokümanın diğerinin özelliklerini okuyabilmesini sağlayabilirler. Bu, iç tarafta saklanan port değerinin null olarak işaretlenebilmesinden dolayı her zaman çalışmayabilmektedir. Başka bir deyişle, example.com port 80, document.domain özelliği güncellendiği için example.com port null olarak değişebilmektedir. Port null 80 portu gibi muamele görmeyebilir (tarayıcıya bağlı olarak) ve böylece geçersiz olabilir veya tarayıcıya bağlı olarak başarılı olabilir.[6]
Kökler Arası Kaynak Paylaşımı[değiştir | kaynağı değiştir]
Aynı kök politikasının esnetilmesi için ikinci bir yöntem, Köklar Arası Kaynak Paylaşımı ismi ile standardize edilmiştir. Bu standart, HTTP protokolünü yeni Origin istek başlığı ve Access-Control-Allow-Origin cevap başlığı ile genişletmiştir.[7] Bu, sunucuların bir başlık kullanarak bir dosyaya erişebilecek kökleri listelemesine veya özel bir karakter (*) kullanarak bir dosyayı herhangi bir sitenin erişimine açmasına izin vermektedir. Firefox 3.5, Safari 4 ve Internet Explorer 10 gibi tarayıcılar, aksi takdirde aynı kök politikası tarafından engellenecek olan XMLHttpRequest ile kökler arası HTTP isteklerine izin vermek için bu başlığı kullanmaktadır.
Dokümanlar arası mesajlaşma[değiştir | kaynağı değiştir]
Başka bir teknik olan dokümanlar arası mesajlaşma, bir sayfadaki betiğin betik köklerinden bağımsız olarak başka bir sayfadaki betiğe metinsel mesajlar göndermesine izin vermektedir. Bir Window nesnesi üzerinden postMessage() metodunun çağrılması, eşzamansız olarak o window nesnesi üzerinde bir "onmessage" olayı oluşturur ve kullanıcının tanımladığı olay işleyicileri tetikler. Bir sayfadaki betik, başka bir sayfadaki metot ve değişkenlere doğrudan erişemez, ancak bu mesaj gönderme mekanizması üzerinden güvenli bir şekilde haberleşebilirler.
JSONP[değiştir | kaynağı değiştir]
JSONP bir sayfanın, başka bir alan adından bir JSON cevabı yükleyen sayfaya <script> elemanının eklenmesi ile farklı bir alan adından JSON verisi almasına izin vermektedir.
WebSockets[değiştir | kaynağı değiştir]
Modern tarayıcılar, aynı kök politikasını uygulamaksızın bir betiğin bir WebSocket adresine bağlanmasına izin vermektedir. Ancak, bir WebSocket URI'sinin kullanıldığını anlamakta ve isteğe, bağlantıyı isteyen betiğin kökünü belirten bir Origin: başlığı eklemektedir. Siteler arası güvenliği sağlamak için, WebSocket sunucusu başlık verisini cevap almasına izin verilen köklerden oluşan bir beyaz liste ile karşılaştırmalıdır.
Uç örnekler ve istisnalar[değiştir | kaynağı değiştir]
Aynı kök politikası kontrollerinin ve ilgili mekanizmaların davranışı, URL'leri (file:, data:, vb.) ile ilişkilendirilen açıkça tanımlanmış bir alan adı veya port bilgisine sahip olmayan sözde protokoller için olduğu gibi bazı uç örneklerde kesin bir şekilde tanımlanmamıştır. Bu durum, lokal olarak saklanan HTML dosyasının disk üzerindeki diğer dosyalara erişebilmesi veya İnternet üzerindeki herhangi bir site ile haberleşebilmesi gibi genellikle istenmeyen yetenekler gibi hatırı sayılır miktarda güvenlik problemlerine neden olmuştur.
İlave olarak, JavaScript'ten önce var olan pek çok siteler arası işlemler aynı kök kontrollerine tabii olmamaktadır; buna bir örnek alan adları arasında betiklerin dahil edilebilmesi veya POST formlarının gönderilebilmesi yeteneğidir.
Son olarak, DNS re binding saldırıları veya sunucu taraflı vekil sunucular gibi bazı saldırı türleri, alan adı kontrolünün kısmen atlatılabilmesine izin vermekte ve sahte web sayfalarının, "gerçek", canonical kökünden farklı başka adresler üzerinden doğrudan sitelerle etkileşimde bulunabilmesini mümkün kılmaktadır. Bu tür saldırıların etkisi, çok özel durumlarla sınırlıdır. Çünkü tarayıcı hala saldırganın sitesiyle haberleştiğine inanmaktadır ve bu yüzden üçüncü taraf çerezleri veya diğer hassas bilgileri saldırgana ifşa etmemektedir.
Geçici çözümler[değiştir | kaynağı değiştir]
Geliştiricilerin kontrollü bir şekilde aynı kök politikasını atlatabilmesini mümkün kılmak için, fragman tanımlayıcının veya window.name özelliğinin kullanılması gibi bir takım yöntemler, farklı alan adlarında bulunan dokümanlar arasında veri gönderiminde kullanılmaktadır. HTML5 standardıyla, yeni tarayıcılarda kullanılabilir olan bir yöntem postMessage arayüzü, resmileştirilmiştir. JSONP de diğer alan adlarına yapılan Ajax benzeri çağrıları aktif hale getirmek için kullanılabilmektedir.[8]
Ayrıca bakınız[değiştir | kaynağı değiştir]
- Kökler Arası Kaynak Paylaşımı
- Siteler Arası Betik Çalıştırma
- Siteler Arası İstek Sahteciliği
- Dokümanlar Arası Mesajlaşma
- İçerik Güvenlik Politikası
Kaynakça[değiştir | kaynağı değiştir]
- ^ "The Tangled Web". Network Security. 2012 (4). doi:10.1016/s1353-4858(12)70022-3.
- ^ "Browser Security Handbook, part 2". google.com. 19 Ağustos 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 31 Ocak 2014.
- ^ "Same Origin Policy". W3C. 27 Ocak 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 31 Ocak 2014.
- ^ Lawrence, Eric. "IEInternals - Same Origin Policy Part 1". 10 Şubat 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 22 Ekim 2013.
- ^ LePera, Scott. "Cross-domain security woes". The Strange Zen Of JavaScript. 30 Ekim 2016 tarihinde kaynağından arşivlendi. Erişim tarihi: 4 Nisan 2014.
- ^ "Creating WSGI Middleware". 4 Mayıs 2017 tarihinde kaynağından arşivlendi. Erişim tarihi: 26 Nisan 2017.
- ^ "Blog Post: Using CORS with all (modern) browsers". 13 Ocak 2014 tarihinde kaynağından arşivlendi. Erişim tarihi: 26 Nisan 2017.
Dış bağlantılar[değiştir | kaynağı değiştir]
- Aynı kök politikalarının farklı özelliklerinin detaylı bir kıyaslaması
- Satıcıların sağladığı örnek aynı kök politikası tanımları
- HTML5'in kök tanımı
- Aynı kök politikası ile ilgili W3C makalesi
- Web Kök kavramına dair RFC 6454
- Blog yazısı: Çerez Aynı Kök Politikası