DOMPurifyに勧告3件 IN_PLACEなどの設定は3.4.17へ

Webのアプリで、利用者が入れたHTMLから危ないスクリプトを取り除く(無害化する)ために広く使われるJavaScriptの部品「DOMPurify」で、勧告が3件出ました。GitHubの勧告のデータベースに載ったのは10月22日(協定世界時)です。深刻度はCritical、High、Lowが1件ずつで、どれも10月12日に出た3.4.17で直っています。

どの勧告も、DOMPurifyの特定の設定や使い方のときに起きるものです。社内で作ったWebのアプリでDOMPurifyを使っているなら、版と設定を確かめます。

3件の中身

3.4.17のリリースノートも、IN_PLACEとSAFE_FOR_TEMPLATESとシャドウルートの問題、IN_PLACEでフックなどが触れた要素の扱い、XHTMLのときのSMILの属性の確かめを直したとしています。あわせて、READMEでIN_PLACEの使い方の危険をはっきり書いたとしています。

IN_PLACEの勧告は続いている

GitHubの勧告のデータベースでは、IN_PLACEの使い方に関わるDOMPurifyの勧告が、8月7日、9月30日、10月5日、そして今回と続いています。どれも、フックで要素を外したときなどに、無害化しきれない部分が残る種類です。

IN_PLACEは、文字列ではなく、すでに作ったDOMの要素をその場で無害化する使い方です。便利な反面、無害化している間に画像の読み込みなどが進んでいると、取りこぼしが起きやすくなります。新しく作るアプリでは、文字列を渡して文字列を受け取る、ふつうの使い方を選ぶほうが安全です(当社の見立て)。

影響する会社・しない会社

• 影響する: 社内で作ったWebのアプリや、委託して作ったアプリでDOMPurifyを使っている会社です。とくに、SAFE_FOR_TEMPLATESと、RETURN_DOM・RETURN_DOM_FRAGMENT・IN_PLACEのどれかを組み合わせているもの、IN_PLACEでフックを使っているものです。
• 影響する: 利用者が書いたHTML(問い合わせの本文、掲示板、メールの表示など)を、Webの画面に出す仕組みを持つ会社です。
• 影響しない: DOMPurifyを使っていない会社と、文字列を渡して文字列を受け取るふつうの使い方だけをしている場合は、CriticalとHighの2件の条件に当たりません。ただし、3.4.17に上げておくのが確実です。

情シスが今日やること

1. 社内のアプリや委託先のアプリで、DOMPurifyを使っているかを確かめます。開発の担当に、npm ls dompurify などで版を見てもらいます。部品の一覧(SBOM)があれば、そこで探します。
2. 3.4.17より前の版なら、3.4.17以降に上げる計画を立てます。2系を使っている場合は、3系へ移る計画が要ります。
3. 使い方を確かめます。SAFE_FOR_TEMPLATES、RETURN_DOM、RETURN_DOM_FRAGMENT、IN_PLACE、フック(addHook)を使っていれば、優先して上げます。
4. 委託して作ったアプリは、保守の会社に、DOMPurifyの版と、今回の3件への対応の予定を問い合わせます。