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

David Dworken

Birçok web uygulaması, kullanıcı tarafından kontrol edilen içeriği göstermelidir. Bu, kullanıcı tarafından yüklenen resimleri (ör. profil fotoğrafları) sunmak kadar basit veya kullanıcı tarafından kontrol edilen HTML'yi (ör. web geliştirme eğitimi) oluşturmak kadar karmaşık olabilir. Bu işlem her zaman güvenli bir şekilde yapılamadığından, çoğu web uygulaması türünde uygulanabilecek kolay ancak güvenli çözümler bulmak için çalıştık.

Güvenilmeyen içeriği yalıtmaya yönelik klasik çözümler

Kullanıcı tarafından kontrol edilen içeriği güvenli bir şekilde yayınlamak için klasik çözüm, korumalı alan adları olarak bilinen adları kullanmaktır. Temel fikir, uygulamanızın ana alanı example.com ise güvenilmeyen tüm içerikleri exampleusercontent.com üzerinde sunabileceğinizdir. Bu iki alan siteler arası olduğundan exampleusercontent.com alanındaki kötü amaçlı içerikler example.com alanını etkileyemez. Bu yaklaşım, resimler, indirmeler ve HTML dahil olmak üzere her türlü güvenilmeyen içeriği güvenli bir şekilde sunmak için kullanılabilir. Bunu resimler veya indirmeler için kullanmak gerekli görünmese de özellikle eski tarayıcılarda içerik koklama risklerinden kaçınmaya yardımcı olur. Sandbox alanları sektörde yaygın olarak kullanılır ve uzun süredir iyi sonuçlar verir. Ancak iki önemli dezavantajı vardır:

• Uygulamaların genellikle içerik erişimini tek bir kullanıcıyla kısıtlaması gerekir. Bu da kimlik doğrulama ve yetkilendirme işlemlerinin uygulanmasını gerektirir. Korumalı alanlar, çerezleri ana uygulama alanıyla paylaşmadığı için bu işlemi güvenli bir şekilde yapmak çok zordur. Siteler, kimlik doğrulamayı desteklemek için yeterlilik URL'lerini kullanmalı veya sandbox alanı için ayrı kimlik doğrulama çerezleri ayarlamalıdır. Bu ikinci yöntem, birçok tarayıcının varsayılan olarak siteler arası çerezleri kısıtladığı modern web'de özellikle sorunludur.
• Kullanıcı içeriği ana siteden ayrı tutulsa da diğer kullanıcı içeriklerinden ayrı tutulmaz. Bu durum, kötü amaçlı kullanıcı içeriğinin korumalı alan alanındaki diğer verilere (ör. aynı kaynak verilerini okuyarak) saldırma riskini oluşturur.

Ayrıca, kaynaklar izole edilmiş bir alanda net bir şekilde segmentlere ayrıldığından sandbox alanlarının kimlik avı risklerini azaltmaya yardımcı olduğunu da belirtmek gerekir.

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

Web zaman içinde gelişti ve artık güvenilmeyen içerikleri sunmanın daha kolay ve güvenli yolları var. Bu konuda birçok farklı yaklaşım vardır. Bu nedenle, Google'da kullandığımız 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 (ör. resimler ve indirmeler gibi HTML veya JavaScript olmayan içerik) sunması gerekiyorsa bu işlem artık yalıtılmış bir sanal alan olmadan güvenli bir şekilde yapılabilir. Bu işlemde iki temel adım vardır:

• Content-Type üstbilgisini her zaman tüm tarayıcılar tarafından desteklenen ve etkin içerik barındırmayan iyi bilinen bir MIME türüne ayarlayın. Emin olmadığınızda application/octet-stream güvenli bir seçimdir.
• Ayrıca, tarayıcının yanıtı tamamen yalıtmasını sağlamak için yanıt üstbilgilerini her zaman 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 başlık kombinasyonu, yanıtın yalnızca uygulamanız tarafından alt kaynak olarak yüklenebilmesini veya kullanıcı tarafından dosya olarak indirilebilmesini sağlar. Ayrıca, başlıklar CSP sandbox başlığı ve default-src kısıtlaması aracılığıyla tarayıcı hatalarına karşı birden fazla koruma katmanı sağlar. Genel olarak, belirtilen kurulum, bu şekilde sunulan yanıtların ekleme veya izolasyon güvenlik açıklarına yol açamayacağı konusunda yüksek düzeyde güven sağlar.

Derinlemesine savunma

Önerilen çözüm, XSS'ye karşı genellikle yeterli bir savunma olsa da 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 X-Content-Security-Policy: sandbox üstbilgisi ayarlayın.
• Uç noktanın yerleştirilmesini engellemek için Content-Security-Policy: frame-ancestors 'none' üstbilgisi ayarlayın.
• Aşağıdaki yöntemlerle kullanıcı içeriklerini yalıtılmış bir alt alanda korumalı alana alın:
  • Kullanıcı içeriğini yalıtılmış bir alt alan adında sunma (ör. Google, product.usercontent.google.com gibi alanlar kullanır).
  • Çapraz kaynak izolasyonunu etkinleştirmek için Cross-Origin-Opener-Policy: same-origin ve Cross-Origin-Embedder-Policy: require-corp değerlerini ayarlayın.

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

Etkin içeriğin (ör. HTML veya SVG resimler) güvenli bir şekilde sunulması, klasik korumalı alan yaklaşımının zayıf yönleri olmadan da yapılabilir.

En basit seçenek, tarayıcıya yanıtı yalıtmasını söylemek için Content-Security-Policy: sandbox üstbilgisinden yararlanmaktır. Tüm web tarayıcıları, korumalı alan belgeleri için işlem izolasyonu uygulamasa da tarayıcı işlem modellerinde devam eden iyileştirmeler, korumalı alan içeriğinin yerleştirme uygulamalarından ayrılmasını iyileştirebilir. SpectreJS ve oluşturucu güvenliğinin ihlali saldırıları tehdit modelinizin dışında kalıyorsa CSP sandbox'ı kullanmak muhtemelen yeterli bir çözümdür. Google olarak, sandbox alanları kavramını modernize ederek güvenilmeyen etkin içeriği tamamen izole edebilen bir çözüm geliştirdik. Temel fikir şudur:

• Herkese açık sonek listesine eklenen yeni bir test alanı oluşturun. Örneğin, PSL'ye exampleusercontent.com ekleyerek foo.exampleusercontent.com ve bar.exampleusercontent.com'nin siteler arası olmasını ve dolayısıyla birbirinden tamamen izole edilmesini sağlayabilirsiniz.
• *.exampleusercontent.com/shim ile eşleşen tüm URL'ler statik bir ara dosyaya yönlendirilir. Bu shim dosyası, message etkinlik işleyicisini dinleyen ve aldığı tüm içerikleri oluşturan kısa bir HTML ve JavaScript snippet'i içerir.
• Ürün, bunu kullanmak için $RANDOM_VALUE.exampleusercontent.com/shim ile iletişim kurmak üzere bir iFrame veya iletişim kutusu oluşturur ve güvenilmeyen içeriği oluşturma için ara katmana göndermek üzere postMessage kullanır.
• Oluşturulan içerik, Blob'a dönüştürülür ve korumalı alana alınmış bir iframe içinde oluşturulur.

Bu yaklaşım, klasik sandbox alanı yaklaşımına kıyasla tüm içeriğin benzersiz bir sitede tamamen izole edilmesini sağlar. Ayrıca, oluşturulacak verilerin alınmasıyla ana uygulamanın ilgilenmesi sayesinde artık yetenek URL'lerinin kullanılması gerekmez.

Sonuç

Bu iki çözüm birlikte, googleusercontent.com gibi klasik özel korumalı alan alanlarından üçüncü taraf çerezlerinin engellenmesiyle uyumlu daha güvenli çözümlere geçiş yapmayı mümkün kılar. Google olarak, birçok ürünü bu çözümleri kullanacak şekilde taşıdık ve önümüzdeki yıl için daha fazla taşıma planlıyoruz.