Pdf.js: Микрооптимизация стиля текстового слоя привела к требованию style-src 'unsafe-inline' в политике безопасности контента

... или, возможно, пересмотреть подход.

PR # 7632 был необходим для повышения производительности, в частности, режима enhanceTextSelection , который является частью проблемы № 7584, поэтому, на мой взгляд, я не думаю, что следует даже рассматривать возможность возврата к нему.

Я только предлагаю использовать другие способы его оптимизации. Например, зачем использовать 4 атрибута заполнения, а затем применять их с помощью style вместо их объединения?

Можно также использовать подход статического массива для установки индивидуальных свойств стиля вместо того, чтобы делать все это через style . Свойства font-family и font-size можно объединить как padding .

Я только предлагаю использовать другие способы его оптимизации. Например, зачем использовать 4 атрибута заполнения, а затем применять их со стилем вместо их объединения?

В общем, нет никакой гарантии, что для конкретного textDiv все четыре значения заполнения будут обновлены с помощью enhanceTextSelection , и текущий код предоставляет простой способ справиться с этим (очень распространенным) случаем.

Можно также по-прежнему использовать подход статического массива для настройки отдельных свойств стиля вместо того, чтобы делать все через стиль.

Общая аргументация обновления всего сразу с помощью style заключалась в том, чтобы попытаться избежать излишнего недействительности DOM при создании / обновлении textDiv s, поскольку это, по-видимому, было одним из основных участников плохая работа режима enhanceTextSelection .

В общем, нет гарантии, что конкретному textDiv нужно обновить все четыре значения заполнения с помощьюhanceTextSelection, и текущий код предоставляет простой способ справиться с этим (очень распространенным) случаем.

Это не означает, что padding нельзя использовать эффективно. Нет необходимости создавать новые строки для частей, которые он не обновляет, и конечный результат будет меньше. Он может заменить один набор атрибутов style одним набором style.padding и "0" можно использовать повторно.

Основной аргумент в пользу обновления всего сразу с использованием стиля заключался в том, чтобы попытаться избежать излишней недействительности DOM при создании / обновлении textDivs, поскольку это, по-видимому, было одним из основных факторов плохой производительности режимаhanceTextSelection.

Разве это не происходит во фрагменте, а не в самой DOM?

Это не означает, что заполнение нельзя использовать эффективно.

@thestinger согласен, это поможет решить проблему, если будут доступны тесты с некоторыми данными о производительности.

Я не могу здесь измерить разницу между разными подходами. Однако различные подходы можно тестировать вне контекста.

Я думаю, что конфликт с unsafe-inline можно уменьшить без потери производительности, настроив это, а затем оптимизацию можно сделать условной, если ее сохранение важно.

Мне легко просто отменить эту фиксацию, так что это не является для меня приоритетом, но я постараюсь найти кого-нибудь, кто над этим поработает. Было бы здорово иметь тесты для материала CSP, чтобы он не сломался в будущем (такие оптимизации все еще могут происходить, если они важны, они просто должны быть условными).

Возможно, существует решение, позволяющее проводить оптимизацию как есть при поддержке веб-сайтов с использованием CSP.

Есть три способа установить встроенный стиль как строку:

• element.setAttribute('style', someStyle) , который не работает, когда есть CSP, который не допускает небезопасное встраивание
• element.style = someStyle , который не поддерживается в IE (тестировался в IE 11, я не тестировал это в Edge, поэтому он может быть сломан и там)
• element.style.cssText = someStyle , который поддерживается на уровне DOM 2, поэтому даже IE поддерживает его (проверено в IE 11)

Plunker для отображения трех методов: https://plnkr.co/edit/T8xrUmR5eSuqDukSEVuw?p=preview

Я был бы более чем готов сделать запрос на вытягивание, изменив element.setAttribute('style', ...) на element.style.cssText = ... если вы согласитесь с этим решением.

Это похоже на ошибку браузера, если element.style.cssText = someStyle работает без 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

Если кто-то еще сталкивается с этим и хочет найти решение, это мой текущий патч, откатывающий его к старому способу, поэтому style-src: 'unsafe-inline' можно избежать:

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

Его определенно можно немного оптимизировать, но, поскольку это не имеет значения для моего использования, я стараюсь минимизировать количество патчей для простоты обслуживания. Я думаю, что ожидать от кого-то, кто хочет, чтобы эта проблема безопасности была исправлена, заботиться об оптимизации производительности, было немного назад. Оптимизация производительности должна быть ограничена тем, что может быть сделано без нарушения элементарной гигиены безопасности. Возможно, будет даже быстрее подойти к этому по-другому, как я упоминал выше. В сообщении фиксации для оптимизации упоминается, насколько сложно было даже измерить разницу, но регресс безопасности довольно легко измерить.

Причина, по которой я использую pdf.js в первую очередь, - это безопасность. Он позволяет повторно использовать усиленный / изолированный рендеринг браузера со всей рендерингом, специфичным для PDF, на безопасном для памяти языке (JavaScript). В рамках этого я использую CSP для смягчения динамического внедрения кода / стиля, что может значительно увеличить поверхность атаки до уровня веб-страницы, что очень противоречит поставленным целям. Я думаю, что у многих других людей есть аналогичный вариант использования pdf.js, чтобы избежать опасных собственных библиотек для рендеринга PDF. Избегание стилей unsafe-inline - это часть гарантии, что ошибка не может привести к случайному внедрению произвольных стилей, открывая большую поверхность для атаки средства визуализации. Для случая использования, когда он встроен в реальный веб-сайт, это имеет еще большее значение, поскольку с помощью CSS можно сделать много зла.

Я считаю это на том же уровне, что и ожидание, что собственные двоичные файлы / библиотеки будут иметь SSP, ASLR (PIE), _FORTIFY_SOURCE=2 , -fstack-clash-protection и другие базовые меры по снижению рисков. Это базовая гигиена безопасности по сравнению с более продвинутыми вещами, такими как CFI на основе типов, захват целочисленных дезинфицирующих средств, ShadowCallStack и т. Д., Где я действительно ожидаю, что более крупные проекты будут думать об этом и, возможно, уже работают над этим, но это не является частью минимума. Я считаю, что базовая политика CSP со статическим JavaScript / CSS квалифицируется как базовая гигиена безопасности.

Исправлено запросом на перенос выше.