Pdf.js: 텍스트 레이어 스타일 미세 최적화로 인해 콘텐츠 보안 정책에 style-src 'unsafe-inline'이 필요함

... 또는 접근 방식을 재고할 수도 있습니다.

PR #7632는 특히 이슈 #7584의 일부인 enhanceTextSelection 모드의 성능을 향상시키기 위해 필요했습니다. 그래서 제 생각에는 이것을 되돌리는 것도 고려되어야 한다고 생각하지 않습니다.

나는 그것을 최적화하기 위해 다른 경로를 택할 것을 제안하고 있습니다. 예를 들어, 4개의 패딩 속성을 사용한 다음 병합하는 대신 style 로 적용하는 이유는 무엇입니까?

style 를 통해 모든 작업을 수행하는 대신 개별 스타일 속성을 설정하기 위해 정적 배열 접근 방식을 계속 사용할 수도 있습니다. font-family 및 font-size 속성은 padding 처럼 병합될 수 있습니다.

나는 그것을 최적화하기 위해 다른 경로를 택할 것을 제안하고 있습니다. 예를 들어, 4개의 패딩 속성을 사용한 다음 병합하는 대신 스타일로 적용하는 이유는 무엇입니까?

일반적으로 특정 textDiv 에 enhanceTextSelection 업데이트된 4개의 패딩 값이 모두 필요하다는 보장은 없으며 현재 코드는 그 (매우 일반적인) 경우를 처리하는 간단한 방법을 제공했습니다.

스타일을 통해 모든 작업을 수행하는 대신 개별 스타일 속성을 설정하기 위해 여전히 정적 배열 접근 방식을 사용할 수도 있습니다.

style 사용하여 모든 것을 한 번에 업데이트하는 일반적인 이유는 textDiv 생성/업데이트할 때 DOM을 불필요하게 무효화하는 것을 방지하기 위한 것입니다. enhanceTextSelection 모드의 성능이 좋지 않습니다.

일반적으로 특정 textDiv가 EnhancedTextSelection으로 업데이트된 4개의 패딩 값을 모두 필요로 한다는 보장은 없으며 현재 코드는 그 (매우 일반적인) 경우를 처리하는 간단한 방법을 제공했습니다.

그렇다고 padding 를 효율적으로 사용할 수 없다는 의미는 아닙니다. 업데이트하지 않는 부분에 대해 새 문자열을 작성할 필요가 없으며 최종 결과는 더 작아집니다. 단일 style 속성 세트를 단일 style.padding 세트로 대체할 수 있으며 " 0 "을 재사용할 수 있습니다.

스타일을 사용하여 한 번에 모든 것을 업데이트하는 일반적인 이유는 textDivs를 생성/업데이트할 때 DOM을 불필요하게 무효화하지 않으려고 하는 것이었습니다. 왜냐하면 이것이 향상텍스트 선택 모드의 나쁜 성능에 대한 주요 기여자 중 하나인 것 같았기 때문입니다.

실제 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를 사용하는 이유는 애초에 보안 때문입니다. 메모리 안전 언어(JavaScript)에서 모든 PDF 관련 렌더링과 함께 강화/샌드박스 브라우저 렌더링을 재사용할 수 있습니다. 이 작업의 일부로 CSP를 사용하여 공격 표면을 웹 페이지와 같이 크게 증가시킬 수 있는 동적 코드/스타일 주입을 완화합니다. 이는 목표에 매우 반대입니다. 다른 많은 사람들이 위험한 기본 PDF 렌더링 라이브러리를 피하기 위해 pdf.js에 대한 유사한 사용 사례를 가지고 있다고 생각합니다. unsafe-inline 스타일을 피하는 것은 버그가 실수로 임의의 스타일을 주입하여 많은 렌더러 공격 표면을 열어주는 결과를 초래하지 않도록 하는 일부입니다. 실제 웹 사이트에 포함된 사용 사례의 경우 CSS로 많은 나쁜 일을 할 수 있기 때문에 훨씬 더 중요합니다.

네이티브 바이너리/라이브러리에 SSP, ASLR(PIE), _FORTIFY_SOURCE=2 , -fstack-clash-protection 및 기타 기본 완화 기능이 있을 것으로 예상하는 것과 동일한 수준에서 이를 고려합니다. 기본 보안 위생 대 유형 기반 CFI, 정수 새니타이저 트래핑, ShadowCallStack 등과 같은 고급 기능입니다. 더 큰 프로젝트에서 이에 대해 생각하고 이미 작업 중일 것으로 예상하지만 최소한의 부분은 아닙니다. 정적 JavaScript/CSS를 사용한 기본 CSP 정책은 내 생각에 기본 보안 위생에 해당합니다.

위의 pull 요청에 의해 수정되었습니다.