Pdf.js: optimasi mikro gaya lapisan teks mengakibatkan membutuhkan style-src 'tidak aman-inline' dalam Kebijakan Keamanan Konten

... atau mungkin mempertimbangkan kembali pendekatannya.

PR #7632 diperlukan untuk meningkatkan kinerja mode enhanceTextSelection khususnya, yang merupakan bagian dari masalah #7584, jadi menurut pendapat saya, pengembalian ini tidak perlu dipertimbangkan.

Saya hanya menyarankan mengambil rute lain untuk mengoptimalkannya. Misalnya, mengapa menggunakan 4 atribut padding dan kemudian menerapkannya dengan style alih-alih menggabungkannya?

Masih bisa menggunakan pendekatan array statis untuk mengatur properti gaya individual alih-alih melakukan semuanya melalui style . Properti font-family dan font-size dapat digabungkan seperti padding .

Saya hanya menyarankan mengambil rute lain untuk mengoptimalkannya. Misalnya, mengapa menggunakan 4 atribut padding dan kemudian menerapkannya dengan gaya alih-alih menggabungkannya?

Secara umum tidak ada jaminan bahwa textDiv membutuhkan keempat nilai padding yang diperbarui dengan enhanceTextSelection , dan kode saat ini menyediakan cara sederhana untuk menangani kasus (sangat umum) itu.

Bisa juga masih menggunakan pendekatan array statis untuk mengatur properti gaya individu alih-alih melakukan semuanya melalui gaya.

Garis alasan umum di balik memperbarui semuanya sekaligus menggunakan style , adalah untuk mencoba dan menghindari pembatalan DOM yang tidak perlu saat membuat/memperbarui textDiv s karena itu tampaknya menjadi salah satu kontributor utama untuk kinerja buruk dari mode enhanceTextSelection .

Secara umum tidak ada jaminan bahwa textDiv tertentu memerlukan keempat nilai padding yang diperbarui dengan enhanceTextSelection, dan kode saat ini menyediakan cara sederhana untuk menangani kasus (sangat umum) itu.

Itu tidak berarti padding tidak dapat digunakan secara efisien. Tidak perlu membuat string baru untuk bagian yang tidak diperbarui dan hasil akhirnya akan lebih kecil. Itu dapat menggantikan satu set atribut style dengan satu set style.padding dan " 0 " dapat digunakan kembali.

Garis alasan umum di balik memperbarui semuanya sekaligus menggunakan gaya, adalah untuk mencoba dan menghindari pembatalan DOM yang tidak perlu saat membuat/memperbarui textDivs karena itu tampaknya menjadi salah satu kontributor utama kinerja buruk mode EnhanceTextSelection.

Bukankah itu terjadi dalam sebuah fragmen, bukan DOM yang sebenarnya?

Itu tidak berarti padding tidak dapat digunakan secara efisien.

@thestinger setuju, ini akan membantu mengatasi masalah jika tolok ukur dengan beberapa data kinerja tersedia.

Saya tidak benar-benar dapat mengukur perbedaan antara pendekatan yang berbeda di sini. Pendekatan yang berbeda dapat menjadi microbenchmark di luar konteks.

Saya pikir konflik dengan unsafe-inline dapat dikurangi tanpa kehilangan kinerja dengan mengutak-atik ini dan kemudian optimasi dapat dibuat bersyarat jika menjaganya penting.

Sangat mudah bagi saya untuk mengembalikan komit ini sehingga itu bukan prioritas tinggi bagi saya, tetapi saya akan mencoba menemukan seseorang untuk mengerjakannya. Akan sangat bagus untuk memiliki tes untuk hal-hal CSP sehingga tidak dapat rusak di masa depan (pengoptimalan seperti ini masih bisa terjadi jika penting, mereka hanya perlu bersyarat).

Mungkin ada solusi yang memungkinkan pengoptimalan apa adanya sambil mendukung situs web menggunakan CSP.

Ada tiga cara untuk mengatur gaya sebaris sebagai string:

• element.setAttribute('style', someStyle) , yang tidak berfungsi ketika ada CSP yang tidak mengizinkan unsafe-inline
• element.style = someStyle , yang tidak didukung di IE (diuji pada IE 11, saya belum menguji ini di Edge sehingga mungkin juga rusak di sana)
• element.style.cssText = someStyle , yang didukung pada DOM level 2, jadi bahkan IE mendukungnya (diverifikasi pada IE 11)

Plunker untuk menunjukkan tiga metode: https://plnkr.co/edit/T8xrUmR5eSuqDukSEVuw?p=preview

Saya akan lebih dari bersedia untuk membuat permintaan tarik mengubah element.setAttribute('style', ...) menjadi element.style.cssText = ... jika Anda setuju dengan solusi ini.

Sepertinya bug browser jika element.style.cssText = someStyle berfungsi tanpa unsafe-eval :

• https://w3c.github.io/webappsec-csp/2/#directive -style-src
• https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/style-src#Unsafe_style_expressions

Jika ada orang lain yang menemukan ini dan menginginkan solusi, ini adalah tambalan saya saat ini yang mengembalikan ini ke cara lama sehingga style-src: 'unsafe-inline' dapat dihindari:

https://github.com/GrapheneOS/pdf.js/commit/021d2fddb03883054ef4399d1d3df87e0c6ab9ca

Itu pasti dapat dioptimalkan sedikit, tetapi karena itu tidak masalah untuk penggunaan saya, saya menjaga tambalan seminimal mungkin untuk kemudahan perawatan. Saya pikir mengharapkan seseorang yang menginginkan masalah keamanan ini diperbaiki untuk peduli tentang mengoptimalkan kinerja agak mundur. Optimalisasi kinerja seharusnya dibatasi pada apa yang dapat dilakukan tanpa melanggar kebersihan keamanan dasar. Bahkan mungkin lebih cepat untuk mendekati ini dengan cara yang berbeda seperti yang saya sebutkan di atas. Pesan komit untuk pengoptimalan menyebutkan betapa sulitnya mengukur perbedaan, tetapi regresi keamanan cukup mudah diukur.

Alasan saya menggunakan pdf.js adalah keamanan. Ini memungkinkan penggunaan kembali perenderan peramban yang diperkeras/kotak pasir dengan semua perenderan khusus PDF dalam bahasa yang aman untuk memori (JavaScript). Sebagai bagian dari melakukan ini, saya menggunakan CSP untuk mengurangi injeksi kode / gaya dinamis yang secara besar-besaran dapat meningkatkan permukaan serangan menjadi seperti halaman web, yang sangat bertentangan dengan tujuan. Saya pikir banyak orang lain memiliki kasus penggunaan serupa untuk pdf.js untuk menghindari perpustakaan rendering PDF asli yang berbahaya. Menghindari gaya unsafe-inline adalah bagian dari memastikan bahwa bug tidak dapat mengakibatkan secara tidak sengaja menyuntikkan gaya arbitrer, membuka banyak permukaan serangan penyaji. Untuk kasus penggunaan di mana itu tertanam di situs web yang sebenarnya, itu lebih penting, karena banyak hal jahat dapat dilakukan dengan CSS.

Saya menganggap ini pada tingkat yang sama dengan mengharapkan binari/perpustakaan asli memiliki SSP, ASLR (PIE), _FORTIFY_SOURCE=2 , -fstack-clash-protection dan mitigasi dasar lainnya. Ini adalah kebersihan keamanan dasar vs. hal-hal yang lebih maju seperti CFI berbasis tipe, pembersih integer trap, ShadowCallStack, dll. di mana saya mengharapkan proyek yang lebih besar untuk memikirkannya dan mungkin sudah mengerjakannya tetapi itu bukan bagian dari minimal. Kebijakan CSP dasar dengan JavaScript/CSS statis memenuhi syarat sebagai kebersihan keamanan dasar menurut saya.

Diperbaiki oleh permintaan tarik di atas.