Bu blog yayını, kısa süre önce kullanıma sunulan Sorunlar sekmesinin yardımıyla İçerik Güvenliği Politikası (İGP) sorunlarını gidermeyle ilgili Geliştirici Araçları desteğinin uygulanmasıyla ilgilidir.
Uygulama çalışması 2 staj sırasında yapılmıştır: 1. İlkinde genel raporlama çerçevesini oluşturduk ve sorun mesajlarını 3 CSP ihlali sorunu için tasarladık. 2. İkincisi, Güvenilir Türlerde hata ayıklama için bazı özel Geliştirici Araçları özelliklerinin yanı sıra Güvenilir Tür sorunlarını da ekledik.
İçerik Güvenliği Politikası nedir?
İçerik Güvenliği Politikası (İGP), güvenliği artırmak amacıyla web sitesindeki belirli davranışların kısıtlanmasına olanak tanır. Örneğin, CSP, satır içi komut dosyalarına veya eval'e izin vermemek için kullanılabilir. Bunların ikisi de Siteler Arası Komut Dosyası Çalıştırma (XSS) saldırılarının saldırı yüzeyini azaltır. CSP hakkında ayrıntılı bilgi için burayı okuyun.
Bu özellikle yeni bir CSP olan Trusted Types(TT) politikasıdır. Bu politika, web sitelerine yapılan büyük bir ekleme saldırısı sınıfını sistematik olarak önleyebilen dinamik bir analiz sağlar. Bunun için TT, bir web sitesinin DOM havuzlarına yalnızca belirli türdeki şeylerin (ör. innerHTML) atanmasına izin vermek için JavaScript kodunu denetlemesini destekler.
Bir web sitesi, belirli bir HTTP üstbilgisi ekleyerek içerik güvenliği politikasını etkinleştirebilir. Örneğin, content-security-policy: require-trusted-types-for 'script'; trusted-types default başlığı bir sayfa için TT politikasını etkinleştirir.
Her politika aşağıdaki modlardan birinde çalışabilir:
- zorunlu mod: Her politika ihlalinin bir hata olduğu durumda
- salt rapor modu - Hata mesajını uyarı olarak bildirir ancak web sayfasında hataya neden olmaz.
Sorunlar sekmesinde İçerik Güvenliği Politikası Sorunlarını uygulama
Bu çalışmanın amacı, CSP sorunlarıyla ilgili hata ayıklama deneyimini iyileştirmekti. Geliştirici Araçları ekibi, yeni sorunları değerlendirirken kabaca şu süreci izler:
- Kullanıcı hikayelerini tanımlama. DevTools kullanıcı arabiriminde, web geliştiricilerinin sorunu nasıl araştırmaları gerektiğini ele alan bir dizi kullanıcı hikayesi tanımlayın.
- Kullanıcı arabirimi uygulaması. Kullanıcı hikayelerine dayanarak, kullanıcı arabirimindeki sorunun araştırılması için hangi bilgilerin gerekli olduğunu belirleyin (ör.ilgili bir istek, çerez adı, komut dosyası veya html dosyasındaki bir satır vb.).
- Sorun algılama. Tarayıcıda sorunun Chrome'da algılanabileceği yerleri tanımlayın ve 2. adımda belirtilen alakalı bilgileri de ekleyerek sorunu bildirmek için yeri belirtin.
- Sorunları kaydedin ve görüntüleyin. Sorunları uygun bir yerde depolayın ve açıldıktan sonra Geliştirici Araçları'nın kullanımına sunun
- Sorunlar metnini tasarlama. Web geliştiricisinin sorunu anlamasına ve daha da önemlisi sorunu çözmesine yardımcı olacak açıklayıcı bir metin bulun
1. Adım: CSP Sorunları için kullanıcı hikayelerini tanımlama
Uygulama çalışmalarımıza başlamadan önce, ne yapmamız gerektiğini daha iyi anlamak için kullanıcı hikayelerinin yer aldığı bir tasarım belgesi oluşturduk. Örneğin, aşağıdaki kullanıcı hikayesini not ettik:
Web sitemin bir kısmının engellendiğini yeni fark eden bir geliştirici olarak şunları yapmak istiyorum:- - ...Web sitemdeki engellenen iframe'lerin / resimlerin CSP'ye neden olup olmadığını öğrenmek - ...Hangi CSP yönergesinin belirli bir kaynağın engellenmesine neden olduğunu öğrenmek - ...web sitemin CSP'sini, engellenmiş mevcut kaynakların görüntülenmesine / şu anda engellenmiş js'nin yürütülmesine izin verecek şekilde nasıl değiştireceğinizi öğrenin.
Bu kullanıcı hikayesini keşfetmek için, ilgilendiğimiz CSP ihlallerini gösteren birkaç basit örnek web sayfası oluşturduk ve süreci kendimiz kavramak için örnek sayfaları inceledik. Örnek web sayfalarından bazılarını aşağıda bulabilirsiniz (demoyu Sorunlar sekmesi açıkken açın):
Bu işlemi kullanarak İGP sorunlarının giderilmesi için kaynak konumunun en önemli bilgi olduğunu öğrendik. Ayrıca, bir kaynağın engellenmesi durumunda ilişkili iframe'i ve isteği hızlı bir şekilde bulmayı ve Geliştirici Araçları'nın Öğeler panelinde yer alan HTML öğesine doğrudan bağlantı vermeyi de yararlı bulduk.
2. Adım: kullanıcı arabirimi uygulaması
Bu analizi, Chrome DevTools Protocol (CDP) aracılığıyla DevTools'a sunmak istediğimiz bilgilerin ilk taslağına dönüştürdük:
Aşağıda third_party/blink/public/devtools_protocol/browser_protocol.pdl'den yapılan alıntıyı bulabilirsiniz
type ContentSecurityPolicyIssueDetails extends object
properties
# The url not included in allowed sources.
optional string blockedURL
# Specific directive that is violated, causing the CSP issue.
string violatedDirective
boolean isReportOnly
ContentSecurityPolicyViolationType contentSecurityPolicyViolationType
optional AffectedFrame frameAncestor
optional SourceCodeLocation sourceCodeLocation
optional DOM.BackendNodeId violatingNodeId
Yukarıdaki tanım, temel olarak bir JSON veri yapısını kodlar. PDL (protokol veri dili) olarak adlandırılan basit bir dilde yazılmıştır. PDL iki amaçla kullanılır. Öncelikle, PDL kullanılarak Geliştirici Araçları kullanıcı arabiriminin temel aldığı TypeScript tanımlarını oluştururuz. Örneğin, yukarıdaki PDL tanımı şu TypeScript arayüzünü oluşturur:
export interface ContentSecurityPolicyIssueDetails {
/**
* The url not included in allowed sources.
*/
blockedURL?: string;
/**
* Specific directive that is violated, causing the CSP issue.
*/
violatedDirective: string;
isReportOnly: boolean;
contentSecurityPolicyViolationType: ContentSecurityPolicyViolationType;
frameAncestor?: AffectedFrame;
sourceCodeLocation?: SourceCodeLocation;
violatingNodeId?: DOM.BackendNodeId;
}
İkinci ve muhtemelen daha da önemlisi, bu veri yapılarının üretilmesini ve C++ Chromium arka ucundan Geliştirici Araçları kullanıcı arabirimine gönderilmesini sağlayan tanımdan bir C++ kitaplığı oluştururuz. Bu kitaplık kullanılarak, aşağıdaki C++ kodu parçası kullanılarak bir ContentSecurityPolicyIssueDetails nesnesi oluşturulabilir:
protocol::Audits::ContentSecurityPolicyIssueDetails::create()
.setViolatedDirective(d->violated_directive)
.setIsReportOnly(d->is_report_only)
.setContentSecurityPolicyViolationType(BuildViolationType(
d->content_security_policy_violation_type)))
.build();
Hangi bilgileri kullanılabilir hale getirmek istediğimize karar verdikten sonra, bu bilgileri Chromium'dan nereden alacağımızı araştırmamız gerekiyordu.
3. Adım: Sorun tespiti
Bilgileri son bölümde açıklanan biçimde Chrome Geliştirici Araçları Protokolü'ne (CDP) sunmak için arka uçta bu bilgilerin gerçekten bulunduğu yeri bulmamız gerekiyordu. Neyse ki CSP kodunda zaten yalnızca rapor modu için kullanılan bir darboğaz kullanılıyordu. Bu bölümde şu bölüme bağlanabiliriz: ContentSecurityPolicy::ReportViolation, sorunları CSP HTTP başlığında yapılandırılabilen (isteğe bağlı) bir raporlama uç noktasına bildirir. Bildirmek istediğimiz bilgilerin çoğu zaten elimizde olduğundan, araçlarımızın çalışması için arka uçta büyük bir değişiklik gerekmedi.
4. Adım: Sorunları kaydedin ve görüntüleyin
Bunun küçük bir özelliği de konsol mesajlarının işlenme şekline benzer şekilde, Geliştirici Araçları açılmadan önce gerçekleşen sorunları da bildirmek istememizdir. Diğer bir deyişle, sorunları doğrudan kullanıcı arabirimine bildirmeyiz ancak Geliştirici Araçları'nın açık olup olmamasından bağımsız olarak sorunlarla dolu bir depolama alanı kullanırız. DevTools açıldıktan (veya başka bir CDP istemcisi eklendiğinde) daha önce kaydedilmiş sorunlar, depolama alanından yeniden oynatılabilir.
Arka uç çalışması bu şekilde sona erdi ve şimdi sorunu ön uçta nasıl ortaya çıkaracağımıza odaklanmamız gerekiyordu.
5. adım: Sorunlar metnini tasarlama
Sorunlar metnini tasarlamak, kendimizin yanı sıra birkaç ekibin de dahil olduğu bir süreçtir. Örneğin, genellikle bir özelliği uygulayan ekibin (bu durumda CSP ekibidir) ve tabii ki web geliştiricilerinin belirli bir sorunla nasıl başa çıkması gerektiğini tasarlayan DevRel ekibinin analizlerine güveniriz. Sorun metni genellikle tamamlanana kadar ayrıntılandırmadan geçer.
Geliştirici Araçları ekibi genellikle düşündüklerinin kaba bir taslağıyla başlar:
## Header
Content Security Policy: include all sources of your resources in content security policy header to improve the functioning of your site
## General information
Even though some sources are included in the content security policy header, some resources accessed by your site like images, stylesheets or scripts originate from sources not included in content security policy directives.
Usage of content from not included sources is restricted to strengthen the security of your entire site.
## Specific information
### VIOLATED DIRECTIVES
`img-src 'self'`
### BLOCKED URLs
https://imgur.com/JuXCo1p.jpg
## Specific information
https://web.dev/strict-csp/
Yinelemenin ardından şu noktaya vardık:
Gördüğünüz gibi, özellik ekibini ve DevRel'i sürece dahil etmek açıklamanın çok daha net ve kesin olmasını sağlıyor.
Sayfanızdaki İGP sorunları, özel olarak İGP ihlallerine ayrılmış sekmede de bulunabilir.
Trusted Types sorunlarını ayıklama
Doğru geliştirici araçları olmadan geniş ölçekte TT ile çalışmak zor olabilir.
İyileştirilmiş konsol yazdırma işlemi
Güvenilir Nesneler ile çalışırken, en az güvenilir olmayan nesneyle aynı miktarda bilgi görüntülemek isteriz. Maalesef şu anda bir Güvenilir Nesne gösterilirken sarmalanmış nesneyle ilgili herhangi bir bilgi görüntülenmiyor.
Bunun nedeni, konsolda görüntülenen değerin varsayılan olarak nesnede .valueOf() çağrısından alınmış olmasıdır. Ancak, Trusted Type olması durumunda, döndürülen değer çok yararlı değildir. Bunun yerine, .toString() numaralı telefonu aradığınızda sunduğunuz avantajlara benzer bir deneyim sunmak isteriz. Bunu başarabilmek için V8 ve Blink'i değiştirerek güvenilir tür nesneler için özel işlem uygulamamız gerekiyor.
Bu özel işleme, geçmişe dönük nedenlerden dolayı V8'de yapılmıştır. Ancak bu tür bir yaklaşımın önemli dezavantajları vardır. Özel görüntüleme gerektiren ancak türleri JS düzeyinde aynı olan birçok nesne vardır. V8 saf JS olduğundan, Trusted Type gibi bir Web API'sine karşılık gelen kavramları ayırt edemez. Bu nedenle, V8'in bunları ayırt edebilmesi için yerleştiriciden (Blink) yardım istemesi gerekir.
Dolayısıyla, kodun bu kısmını Blink'e veya herhangi bir yerleştirme aracına taşımak mantıklı bir seçim gibi görünür. Karşılaşılan sorunun dışında birçok başka faydası da vardır:
- Her yerleştiren kendi açıklama oluşturma işlemine sahip olabilir
- Açıklamayı Blink API üzerinden oluşturmak çok daha kolay.
- Blink'in nesnenin orijinal tanımına erişimi var. Dolayısıyla, açıklamayı oluşturmak için
.toString()kullanılırsa.toString()yeniden tanımlanma riski olmaz.
İhlale neden olan olay (yalnızca rapor modunda)
Şu anda TT ihlallerinde hata ayıklamanın tek yolu JS istisnalarında kesme noktaları ayarlamaktır. Zorunlu TT ihlalleri bir istisnayı tetikleyeceğinden bu özellik bir şekilde yararlı olabilir. Ancak, gerçek senaryolarda TT ihlalleri üzerinde daha hassas bir kontrole ihtiyacınız vardır. Özellikle, yalnızca TT ihlallerini (diğer istisnaları değil) kesmek, salt rapor modundan çıkarmak ve farklı TT ihlal türlerini birbirinden ayırmak istiyoruz.
DevTools zaten çok çeşitli ayrılma noktalarını desteklediğinden mimari oldukça genişletilebilir. Yeni bir ayrılma noktası türü eklemek için arka uç (Blink), CDP ve ön uçta değişiklik yapılması gerekir.
setBreakOnTTViolation olarak adlandırdığımız yeni bir CDP komutu kullanıma sunmalıyız. Bu komut, arka uca ne tür TT ihlallerini ortadan kaldırması gerektiğini bildirmek için ön uç tarafından kullanılacaktır. Arka uç (özellikle InspectorDOMDebuggerAgent), her TT ihlali gerçekleştiğinde çağrılacak bir "kontrol" (onTTViolation()) sağlar. Ardından InspectorDOMDebuggerAgent, bu ihlalin bir ayrılma noktası tetikleyip tetiklemediğini kontrol eder ve bu durumda, yürütmeyi duraklatmak için ön uca bir mesaj gönderir.
Neler yapıldı ve sonra ne yapılacak?
Burada açıklanan sorunlar ortaya çıktığından beri Sorunlar sekmesinde birçok değişiklik yapıldı:
- Bu özelliğin Geliştirici Araçları'ndaki diğer panellerle birbiriyle bağlantısı iyileştirildi.
- Daha fazla sorunla ilgili raporlar Sorunlar sekmesine taşındı: düşük kontrast, güvenilir web etkinliği, süslemeler modu, ilişkilendirme raporlama API'si ve CORS ile ilgili sorunlar.
- Sorunları gizleme fırsatı sunuldu
Bundan sonra daha fazla sorunu ortaya çıkarmak için Sorunlar sekmesini kullanmayı planlıyoruz. Böylece, uzun vadede okunamayan hata mesajı akışı Console'dan kaldırılabilir.
Önizleme kanallarını indirme
Varsayılan geliştirme tarayıcınız olarak Chrome Canary, Yeni geliştirilenler veya Beta'yı kullanmayı düşünün. Bu önizleme kanallarıyla Geliştirici Araçları'nın en yeni özelliklerine erişebilir, son teknoloji ürünü web platformu API'lerini test edebilir ve sitenizdeki sorunları kullanıcılarınızdan önce tespit edebilirsiniz!
Chrome Geliştirici Araçları ekibiyle iletişim kurma
Yayındaki yeni özellikler ve değişiklikler ya da Geliştirici Araçları ile ilgili diğer konular hakkında konuşmak için aşağıdaki seçenekleri kullanın.
- crbug.com adresinden öneri veya geri bildirim gönderin.
- Geliştirici Araçları'nda, Diğer seçenekler
> Yardım > Geliştirici Araçları sorunu bildir'i kullanarak Geliştirici Araçları sorunlarını bildirin. - @ChromeDevTools adresine tweet gönderin.
- Geliştirici Araçları'ndaki YouTube videoları veya Geliştirici Araçları İpuçları YouTube videolarındaki yenilikler hakkındaki görüşlerinizi bizimle paylaşın.