Kullanıcı verilerini modern web uygulamalarında güvenli bir şekilde barındırma

David Dworken

Birçok web uygulamasının kullanıcı tarafından denetlenen içerik görüntülemesi gerekir. Bu işlem, kullanıcı tarafından yüklenen resimleri (ör. profil fotoğrafları) sunmak kadar basit olabileceği gibi, kullanıcı tarafından kontrol edilen HTML oluşturmak (ör. web geliştirme eğitimi) kadar karmaşık da olabilir. Bu işlemi güvenli bir şekilde gerçekleştirmek her zaman zor olmuştur. Bu nedenle, birçok web uygulaması türüne uygulanabilecek kolay ancak güvenli çözümler bulmak için çalışmalar yaptık.

Güvenilmeyen içerikleri izole etmeye yönelik klasik çözümler

Kullanıcı tarafından kontrol edilen içerikleri güvenli bir şekilde sunmanın klasik çözümü, korumalı alan alanları olarak bilinen alanları kullanmaktır. Temel düşünce, uygulamanızın ana alan adı example.com ise güvenilmeyen tüm içerikleri exampleusercontent.com sağlayıcısında sunabilmenizdir. Bu iki alan adı siteler arası olduğundan, exampleusercontent.com sitesindeki kötü amaçlı içerikler example.com ürününü etkileyemez.
Bu yaklaşım; resimler, indirmeler ve HTML dahil olmak üzere her tür güvenilir olmayan içeriği güvenli bir şekilde sunmak için kullanılabilir. Bunu resimler veya indirme işlemleri için kullanmak gerekli görünmese de, özellikle eski tarayıcılarda içerik algılama kaynaklı riskleri önlemeye yardımcı olur.
Korumalı alan alanları, sektörde yaygın olarak kullanılır ve uzun zamandır işe yaramıştır. Ancak, başlıca iki dezavantajı vardır:

• Uygulamaların genellikle içerik erişimini tek bir kullanıcıyla sınırlaması, kimlik doğrulama ve yetkilendirme uygulaması gerekir. Korumalı alan alanları, çerezleri kasıtlı olarak ana uygulama alanıyla paylaşmadığından, bunu güvenli bir şekilde yapmak çok zordur. Kimlik doğrulamayı desteklemek için sitelerin ya özellik URL'lerini kullanması ya da korumalı alan alanı için ayrı kimlik doğrulama çerezleri ayarlaması gerekir. Bu ikinci yöntem özellikle, birçok tarayıcının siteler arası çerezleri varsayılan olarak kısıtladığı modern web'de sorunludur.
• Kullanıcı içeriği ana siteden izole olsa da diğer kullanıcı içeriğinden yalıtılmaz. Bu durum, kötü amaçlı kullanıcı içeriğinin korumalı alan alanındaki diğer verilere saldırma riskini oluşturur (örneğin, aynı kaynaktan gelen verileri okuyarak).

Ayrıca, kaynaklar izole bir alanda açıkça segmentlere ayrıldığından korumalı alan alanlarının kimlik avı risklerinin azaltılmasına yardımcı olduğunu da belirtmek isteriz.

Kullanıcı içeriği sunmaya yönelik modern çözümler

Web zamanla değişti ve artık güvenilir olmayan içerik sunmanın daha kolay ve daha güvenli yolları var. Bu konuda pek çok farklı yaklaşım olduğundan, şu anda Google'da yaygın olarak kullanılan iki çözümü özetleyeceğiz.

1. Yaklaşım: Etkin olmayan kullanıcılara içerik sunma

Bir sitenin yalnızca etkin olmayan kullanıcı içeriği (örneğin, resimler ve indirmeler gibi HTML veya JavaScript olmayan içerik) sunması gerekiyorsa bu işlem artık izole bir korumalı alan alanı olmadan güvenli bir şekilde yapılabilir. İki önemli adım vardır:

• Content-Type üstbilgisini her zaman tüm tarayıcılar tarafından desteklenen ve etkin içerik barındırmayacağı garanti edilen iyi bilinen bir MIME türüne ayarlayın (şüpheye düştüğünüzde application/octet-stream güvenli bir seçimdir).
• Ayrıca, tarayıcının yanıtı tamamen izole ettiğinden emin olmak için her zaman aşağıdaki yanıt üstbilgilerini ayarlayın.

X-Content-Type-Options: nosniff

Content-Disposition: attachment; filename="download"

Content-Security-Policy: sandbox

Content-Security-Policy: default-src ‘none'

Cross-Origin-Resource-Policy: same-site

Bu üstbilgi kombinasyonu, yanıtın uygulamanız tarafından yalnızca bir alt kaynak olarak veya kullanıcı tarafından dosya olarak indirilebilmesini sağlar. Ayrıca başlıklar, CSP korumalı alan başlığı ve default-src kısıtlaması aracılığıyla tarayıcı hatalarına karşı birden çok koruma katmanı sağlar. Genel olarak yukarıda özetlenen kurulum, bu şekilde sunulan yanıtların ekleme veya yalıtım güvenlik açıklarına yol açamayacağına dair yüksek derecede güven sağlar.

Derinlemesine savunma

Yukarıdaki çözüm, XSS'e karşı genel olarak yeterli bir savunmayı temsil etse de, ek güvenlik katmanları sağlamak için uygulayabileceğiniz bir dizi ek sağlamlaştırma önlemi vardır:

• IE11 ile uyumluluk için bir X-Content-Security-Policy: sandbox üst bilgisi ayarlayın.
• Uç noktanın yerleştirilmesini engellemek için bir Content-Security-Policy: frame-ancestors 'none' üst bilgisi ayarlayın.
• Aşağıdakileri yaparak izole bir alt alan adında korumalı alan kullanıcı içeriği oluşturabilirsiniz:
  • Yalıtılmış bir alt alan adında kullanıcı içeriği sunma (ör. Google, product.usercontent.google.com gibi alan adları kullanır).
  • Çapraz kaynak izolasyonunu etkinleştirmek için Cross-Origin-Opener-Policy: same-origin ve Cross-Origin-Embedder-Policy: require-corp ayarlarını yapın.

2. Yaklaşım: Etkin kullanıcı içeriği sunma

Etkin içeriklerin (örneğin HTML veya SVG resimleri) güvenli bir şekilde sunulması da klasik korumalı alan adı yaklaşımının zayıf yanları olmadan gerçekleştirilebilir.
En basit seçenek, tarayıcıya yanıtı ayırmasını bildirmek için Content-Security-Policy: sandbox üstbilgisinden yararlanmaktır. Şu anda tüm web tarayıcıları korumalı alan dokümanları için işlem yalıtımı uygulamasa da, tarayıcı işlem modellerinde devam eden ayrıntılandırmalar korumalı alana alınmış içeriğin yerleştirme uygulamalarından ayrılmasını büyük olasılıkla geliştirecektir. SpectreJS ve oluşturucu güvenlik ihlali saldırıları tehdit modelinizin dışındaysa CSP korumalı alanını kullanmak muhtemelen yeterli bir çözümdür.
Google olarak, korumalı alan alanları kavramını modernleştirerek güvenilmeyen etkin içeriği tamamen izole edebilen bir çözüm geliştirdik. Temel fikir şudur:

• Genel son ek listesine eklenen yeni bir korumalı alan alanı oluşturun. Örneğin, PSL'ye exampleusercontent.com ekleyerek foo.exampleusercontent.com ve bar.exampleusercontent.com öğelerinin siteler arası olmasını ve böylece birbirinden tamamen izole edilmesini sağlayabilirsiniz.
• *.exampleusercontent.com/shim ile eşleşen URL'lerin tümü statik bir dolgu dosyasına yönlendirilir. Bu dolgu dosyası, message etkinlik işleyicisini dinleyen ve alınan içeriği oluşturan kısa bir HTML ve JavaScript snippet'i içerir.
• Ürün, bunu kullanmak için bir iframe veya $RANDOM_VALUE.exampleusercontent.com/shim pop-up'ı oluşturur ve güvenilmeyen içeriği oluşturma işlemi için dolguya göndermek üzere postMessage özelliğini kullanır.
• Oluşturulan içerik bir Blob'a dönüştürülür ve korumalı alana alınmış bir iframe'de oluşturulur.

Klasik korumalı alan adı yaklaşımına kıyasla bu yaklaşım, tüm içeriğin benzersiz bir sitede tamamen izole edilmesini sağlar. Ayrıca, ana uygulamanın oluşturulacak verileri almayla ilgilenmesi nedeniyle özellik URL'lerinin kullanılması artık gerekli değildir.

Sonuç

Bu iki çözüm birlikte kullanıldığında googleusercontent.com gibi klasik korumalı alan alanlarından, üçüncü taraf çerezlerini engellemeyle uyumlu olan daha güvenli çözümlere taşımayı mümkün kılar. Google olarak, bu çözümleri kullanmak için birçok ürünü taşıdık ve önümüzdeki yıl için başka taşıma işlemleri planladık.