Mengimplementasikan proses debug CSP dan Jenis Tepercaya di Chrome DevTools

Kateryna Prokopenko
Kateryna Prokopenko
GitHub
Alfonso Castaño
Alfonso Castaño

Postingan blog ini membahas penerapan dukungan DevTools untuk men-debug masalah Kebijakan Keamanan Konten (CSP) dengan bantuan tab Masalah yang baru diperkenalkan.

Pekerjaan implementasi dilakukan selama 2 magang: 1. Selama tahap pertama, kami membangun framework pelaporan umum dan merancang pesan masalah untuk 3 masalah pelanggaran CSP. 2. Selama tahap kedua, kami menambahkan masalah Jenis Tepercaya bersama beberapa fitur DevTools khusus untuk proses debug Jenis Tepercaya.

Apa yang dimaksud dengan Kebijakan Keamanan Konten?

Kebijakan Keamanan Konten (CSP) memungkinkan pembatasan perilaku tertentu di situs untuk meningkatkan keamanan. Misalnya, CSP dapat digunakan untuk melarang skrip inline atau melarang eval, yang keduanya mengurangi permukaan serangan untuk serangan Pembuatan Skrip Lintas Situs (XSS). Untuk pengantar mendetail tentang CSP, baca di sini.

CSP yang sangat baru adalah kebijakan Trusted Types(TT), yang memungkinkan analisis dinamis yang dapat mencegah berbagai jenis serangan injeksi di situs secara sistematis. Untuk mencapai hal ini, TT mendukung situs dalam mengawasi kode JavaScript-nya agar hanya mengizinkan jenis hal tertentu ditetapkan ke sink DOM seperti innerHTML.

Situs dapat mengaktifkan kebijakan keamanan konten dengan menyertakan header HTTP tertentu. Misalnya, header content-security-policy: require-trusted-types-for 'script'; trusted-types default mengaktifkan kebijakan TT untuk halaman.

Setiap kebijakan dapat beroperasi dalam salah satu mode berikut:

  • mode diterapkan - setiap pelanggaran kebijakan adalah error,
  • mode hanya laporan - yang melaporkan pesan error sebagai peringatan, tetapi tidak menyebabkan kegagalan di halaman web.

Menerapkan Masalah Kebijakan Keamanan Konten di tab Issues

Tujuan dari pekerjaan ini adalah untuk meningkatkan pengalaman proses debug untuk masalah CSP. Saat mempertimbangkan masalah baru, tim DevTools secara garis besar mengikuti proses berikut:

  1. Menentukan cerita pengguna. Mengidentifikasi serangkaian cerita pengguna di front-end DevTools yang mencakup cara developer web perlu menyelidiki masalah.
  2. Penerapan front-end. Berdasarkan cerita pengguna, identifikasi informasi yang diperlukan untuk menyelidiki masalah di front-end (misalnya, permintaan terkait, nama cookie, baris dalam skrip atau file HTML, dll.).
  3. Deteksi masalah. Identifikasi tempat di browser tempat masalah dapat dideteksi di Chrome dan lengkapi tempat tersebut untuk melaporkan masalah, termasuk informasi yang relevan dari langkah (2).
  4. Simpan dan tampilkan masalah. Menyimpan masalah di tempat yang sesuai dan menyediakannya untuk DevTools setelah dibuka
  5. Mendesain teks masalah. Come up with an explanatory text that helps the web developer understand, and more importantly fix the problem

Langkah 1: menentukan cerita pengguna untuk Masalah CSP

Sebelum memulai pekerjaan implementasi, kami membuat dokumen desain dengan cerita pengguna untuk lebih memahami hal yang perlu kami lakukan. Misalnya, kami menulis cerita pengguna berikut:

Sebagai developer yang baru menyadari bahwa beberapa bagian situs saya diblokir, saya ingin:- - ...mengetahui apakah CSP adalah alasan iframe / gambar diblokir di situs saya - ...mempelajari perintah CSP yang menyebabkan pemblokiran resource tertentu - ...mengetahui cara mengubah CSP situs saya untuk mengizinkan tampilan resource yang saat ini diblokir / eksekusi js yang saat ini diblokir.

Untuk mempelajari cerita pengguna ini, kami membuat beberapa contoh halaman web sederhana yang menunjukkan pelanggaran CSP yang kami minati, dan mempelajari halaman contoh tersebut untuk memahami prosesnya sendiri. Berikut beberapa contoh halaman web (buka demo dengan tab Issues terbuka):

Dengan menggunakan proses ini, kami mengetahui bahwa lokasi sumber adalah informasi yang paling penting untuk men-debug masalah CSP. Kami juga merasa berguna untuk menemukan iframe dan permintaan terkait dengan cepat jika resource diblokir, dan link langsung ke elemen HTML di panel Elemen DevTools juga dapat berguna.

Langkah 2: implementasi front-end

Kami mengubah insight ini menjadi draf pertama informasi yang ingin kami sediakan untuk DevTools melalui Chrome DevTools Protocol (CDP):

Berikut adalah kutipan dari third_party/blink/public/devtools_protocol/browser_protocol.pdl

 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

Definisi di atas pada dasarnya mengenkode struktur data JSON. Protokol ini ditulis dalam bahasa sederhana yang disebut PDL (protocol data language). PDL digunakan untuk dua tujuan. Pertama, kita menggunakan PDL untuk membuat definisi TypeScript yang diandalkan oleh front-end DevTools. Misalnya, definisi PDL di atas menghasilkan antarmuka TypeScript berikut:

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;
}

Kedua, dan mungkin yang lebih penting, kami membuat library C++ dari definisi yang menangani pembuatan dan pengiriman struktur data ini dari backend Chromium C++ ke frontend DevTools. Dengan library tersebut, objek ContentSecurityPolicyIssueDetails dapat dibuat menggunakan potongan kode C++ berikut:

protocol::Audits::ContentSecurityPolicyIssueDetails::create()
  .setViolatedDirective(d->violated_directive)
  .setIsReportOnly(d->is_report_only)
  .setContentSecurityPolicyViolationType(BuildViolationType(
      d->content_security_policy_violation_type)))
  .build();

Setelah memutuskan informasi yang ingin kami sediakan, kami perlu mencari tahu dari mana kami bisa mendapatkan informasi ini dari Chromium.

Langkah 3: deteksi masalah

Agar informasi tersedia untuk Chrome DevTools Protocol (CDP) dalam format yang dijelaskan di bagian terakhir, kami perlu menemukan tempat informasi tersebut benar-benar tersedia di backend. Untungnya, kode CSP sudah memiliki bottleneck yang digunakan untuk mode hanya laporan, yang dapat kita kaitkan: ContentSecurityPolicy::ReportViolation melaporkan masalah ke endpoint pelaporan (opsional) yang dapat dikonfigurasi di header HTTP CSP. Sebagian besar informasi yang ingin kami laporkan sudah tersedia, sehingga tidak diperlukan perubahan besar di backend agar instrumentasi kami berfungsi.

Langkah 4: simpan dan tampilkan masalah

Sedikit kerumitan adalah fakta bahwa kami juga ingin melaporkan masalah yang terjadi sebelum DevTools dibuka, mirip dengan cara penanganan pesan konsol. Artinya, kami tidak langsung melaporkan masalah ke front-end, tetapi menggunakan penyimpanan yang diisi dengan masalah, terlepas dari apakah DevTools terbuka atau tidak. Setelah DevTools dibuka (atau, klien CDP lainnya terpasang), semua masalah yang dicatat sebelumnya dapat diputar ulang dari penyimpanan.

Hal ini mengakhiri pekerjaan back-end, dan kami sekarang perlu berfokus pada cara menampilkan masalah di front-end.

Langkah 5: mendesain teks masalah

Mendesain teks masalah adalah proses yang melibatkan beberapa tim selain tim kami sendiri. Misalnya, kami sering mengandalkan insight dari tim yang menerapkan fitur (dalam hal ini adalah tim CSP) dan tentu saja tim DevRel, yang mendesain cara developer web menangani jenis masalah tertentu. Teks masalah biasanya melalui beberapa penyempurnaan hingga selesai.

Biasanya, tim DevTools akan memulai dengan draf kasar dari apa yang mereka bayangkan:


## 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/

Setelah iterasi, kami kemudian sampai pada:

ALT_TEXT_HERE

Seperti yang Anda lihat, melibatkan tim fitur dan DevRel membuat deskripsi menjadi jauh lebih jelas dan akurat.

Masalah CSP di halaman Anda juga dapat ditemukan di tab yang khusus ditujukan untuk pelanggaran CSP.

Men-debug masalah Jenis Tepercaya

Bekerja dengan TT dalam skala besar dapat menjadi tantangan tanpa alat developer yang tepat.

Pencetakan konsol yang ditingkatkan

Saat bekerja dengan Objek Tepercaya, kami ingin menampilkan setidaknya jumlah informasi yang sama seperti untuk objek yang tidak tepercaya. Sayangnya, saat ini saat menampilkan Objek Tepercaya, tidak ada informasi tentang objek yang digabungkan yang ditampilkan.

Hal ini karena nilai yang ditampilkan di konsol diambil dari pemanggilan .valueOf() pada objek secara default. Namun, dalam kasus Jenis Tepercaya, nilai yang ditampilkan tidak terlalu berguna. Sebagai gantinya, kita ingin memiliki sesuatu yang mirip dengan yang Anda dapatkan saat memanggil .toString(). Untuk mencapai hal ini, kita perlu mengubah V8 dan Blink untuk memperkenalkan penanganan khusus untuk objek jenis tepercaya.

Meskipun karena alasan historis, penanganan kustom ini dilakukan di V8, pendekatan semacam ini memiliki kelemahan yang signifikan. Ada banyak objek yang memerlukan tampilan kustom, tetapi jenisnya sama di level JS. Karena V8 adalah JS murni, V8 tidak dapat membedakan konsep yang sesuai dengan Web API seperti Jenis Tepercaya. Oleh karena itu, V8 harus meminta bantuan embedder-nya (Blink) untuk membedakannya.

Oleh karena itu, memindahkan bagian kode tersebut ke Blink atau penyemat apa pun tampaknya merupakan pilihan yang logis. Selain masalah yang terekspos, ada banyak manfaat lainnya:

  • Setiap embedder dapat memiliki pembuatan deskripsinya sendiri
  • Jauh lebih mudah untuk membuat deskripsi melalui Blink API
  • Blink memiliki akses ke definisi asli objek. Jadi, jika kita menggunakan .toString() untuk membuat deskripsi, tidak ada risiko bahwa .toString() mungkin didefinisikan ulang.

Break-on-violation (dalam mode hanya laporan)

Saat ini, satu-satunya cara untuk men-debug pelanggaran TT adalah dengan menetapkan titik henti sementara pada pengecualian JS. Karena pelanggaran TT yang diterapkan akan memicu pengecualian, fitur ini dapat berguna. Namun, dalam skenario dunia nyata, Anda memerlukan kontrol yang lebih mendetail atas pelanggaran TT. Secara khusus, kami ingin menghentikan hanya pada pelanggaran TT (bukan pengecualian lainnya), menghentikan juga dalam mode hanya laporan, dan membedakan berbagai jenis pelanggaran TT.

DevTools sudah memiliki dukungan untuk berbagai titik henti sementara sehingga arsitekturnya cukup dapat diperluas. Menambahkan jenis titik henti sementara baru memerlukan perubahan di backend (Blink), CDP, dan frontend. Kita harus memperkenalkan perintah CDP baru, sebut saja setBreakOnTTViolation. Perintah ini akan digunakan oleh frontend untuk memberi tahu backend tentang jenis pelanggaran TT yang harus dihentikan. Backend, khususnya InspectorDOMDebuggerAgent, akan menyediakan "pemeriksaan", onTTViolation() yang akan dipanggil setiap kali terjadi pelanggaran TT. Kemudian, InspectorDOMDebuggerAgent akan memeriksa apakah pelanggaran tersebut harus memicu titik henti sementara, dan jika demikian, akan mengirim pesan ke frontend untuk menjeda eksekusi.

Apa yang sudah dilakukan dan apa langkah selanjutnya?

Sejak masalah yang dijelaskan di sini diperkenalkan, tab Masalah telah mengalami beberapa perubahan:

Ke depannya, kami berencana menggunakan tab Masalah untuk menampilkan lebih banyak masalah, sehingga Konsol dapat mengurangi beban alur pesan error yang tidak dapat dibaca dalam jangka panjang.

Mendownload saluran pratinjau

Pertimbangkan untuk menggunakan Chrome Canary, Dev, atau Beta sebagai browser pengembangan default Anda. Saluran pratinjau ini memberi Anda akses ke fitur DevTools terbaru, memungkinkan Anda menguji API platform web mutakhir, dan membantu Anda menemukan masalah di situs sebelum pengguna Anda menemukannya.

Hubungi tim Chrome DevTools

Gunakan opsi berikut untuk membahas fitur baru, update, atau hal lain yang terkait dengan DevTools.