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 kontrol edilen içeriği görüntülemesi gerekir. Bu işlem, kullanıcı tarafından yüklenen resimler (örneğin, profil fotoğrafları) sunmak kadar basit veya kullanıcı tarafından kontrol edilen HTML oluşturmak kadar karmaşık (örneğin bir web geliştirme eğitimi) olabilir. Bunu güvenli bir şekilde yapmak her zaman zor olmuştur. Bu nedenle, çoğu web uygulaması türüne uygulanabilecek kolay ancak güvenli çözümler bulmaya çalıştık.

Güvenilir olmayan içerikleri izole etmek için klasik çözümler

Kullanıcı tarafından denetlenen içeriklerin güvenli bir şekilde sunulması için klasik çözüm, korumalı alan alanları olarak bilinen alanları kullanmaktır. Temel fikir, uygulamanızın ana alanı example.com ise güvenilmeyen tüm içeriği exampleusercontent.com üzerinden sunabileceğinizdir. Bu iki alan siteler arası olduğundan, exampleusercontent.com üzerindeki kötü amaçlı içerikler example.com üzerinde etkili olamaz.
. Bu yaklaşım; resimler, indirmeler ve HTML de dahil olmak üzere güvenilmeyen her türlü içeriği güvenli bir şekilde sunmak için kullanılabilir. Bunu resimler veya indirmeler için kullanmak gerekli gibi görünmese de, özellikle eski tarayıcılarda içerik algılama risklerinin önlenmesine yardımcı olur.
. Korumalı alan alanları, sektörde yaygın olarak kullanılmakta ve uzun süredir iyi performans göstermektedir. Ancak, bunların iki önemli dezavantajı vardır:

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

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

Kullanıcı içeriği sunmak için modern çözümler

Web zaman içinde gelişti ve artık güvenilmeyen içerikler sunmanın daha kolay ve daha güvenli yolları var. Burada 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ı içeriği sunma

Bir sitenin yalnızca etkin olmayan kullanıcı içeriği (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. Burada iki ö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 (şüphelendiği durumlarda application/octet-stream güvenli bir seçimdir).
• Ayrıca, tarayıcının yanıtı tam olarak izole ettiğinden emin olmak için her zaman aşağıdaki yanıt başlıklarını 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 alt kaynak olarak yüklenmesini 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 fazla 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çmayacağı konusunda yüksek derecede güven sağlar.

Derinlemesine savunma

Yukarıdaki çözüm XSS'e karşı genel olarak yeterli bir savunma sağlar, ancak ek güvenlik katmanları sağlamak üzere uygulayabileceğiniz çeşitli ek önlemler 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' üstbilgisi ayarlayın.
• Yalıtılmış bir alt alan adında kullanıcı içeriğini korumalı alana almak için:
  • Yalıtılmış bir alt alan adında kullanıcı içeriği sunma (ör. Google, product.usercontent.google.com gibi alanları kullanır).
  • Kaynaklar arası izolasyonu 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

Klasik korumalı alan alan adı yaklaşımının zayıf yönlerine bakılmaksızın, etkin içeriğin (örneğin, HTML veya SVG resimleri) güvenli bir şekilde sunulması da mümkündür.
. En basit seçenek, tarayıcıya yanıtı izole etmesini bildirmek için Content-Security-Policy: sandbox başlığından 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 sürekli yapılan geliştirmeler, korumalı alana alınan içeriğin yerleştirme uygulamalardan ayrılmasını daha iyi hale getirecektir. SpectreJS ve oluşturucu güvenlik ihlali saldırıları, tehdit modelinizin dışındaysa CSP korumalı alanının kullanılması muhtemelen yeterli bir çözümdür.
. Google olarak, korumalı alan alan adları kavramını modernleştirerek güvenilir olmayan etkin içeriği tamamen izole edebilen bir çözüm geliştirdik. Temel düşüncemiz şudur:

• Herkese açık 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ı olduğundan ve böylece birbirinden tamamen izole edildiğinden emin olabilirsiniz.
• *.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 aldığı içeriği oluşturan kısa bir HTML ve JavaScript snippet'i içerir.
• Ürün bunu kullanmak için $RANDOM_VALUE.exampleusercontent.com/shim öğesine bir iframe ya da pop-up oluşturur ve güvenilmeyen içeriği oluşturmak üzere dolguya göndermek için postMessage yöntemini kullanır.
• Oluşturulan içerik Blob'a dönüştürülür ve korumalı alana alınmış iframe içinde oluşturulur.

Klasik korumalı alan alan adı yaklaşımına kıyasla bu, tüm içeriğin benzersiz bir sitede tamamen izole edilmesini sağlar. Ayrıca ana uygulamanın işlenecek verilerin alınmasıyla özellik URL'lerinin kullanılmasına gerek kalmaz.

Sonuç

Bu iki çözüm birlikte googleusercontent.com gibi klasik korumalı alan alanlarından, üçüncü taraf çerezlerini engellemeyle uyumlu daha güvenli çözümlere geçmeyi mümkün kılar. Google'da, bu çözümleri kullanmak için birçok ürünü halihazırda taşıdık ve önümüzdeki yıl için daha fazla taşıma işlemi planlıyoruz.