Category:
Web
はてなの提供する新しいブックマークレットが話題になっていたので、(ちょっと遅いけど)便乗して最近の懸念事項についてメモしておこうかな。
新はてなブックマークの登録ブックマークレットは使ってはいけない
最近のブックマークレットには「script 要素を作ってその src 属性に外部ファイルを指定する」というものが多いですね。
ブックマークレットの文字数の制限を回避するためや、仕様変更・バージョンアップが行いやすいといった理由によるものでしょう。
しかしながら、このスタイルのブックマークレットが、以下のようなシナリオで大きなセキュリティリスクになり得るこということはあまり指摘されていません:
1. ユーザが、あるブックマークレットを登録する。このブックマークレットは http://www.example.org/bookmarklet.js をインクルードする。
2. ユーザが Cookie による認証を行う SSL 下の Web サイト https://www.example.com/ を開き、このブックマークレットを起動する。
この場合、次のようなセキュリティリスクが想定可能です。
a) bookmarklet.js が、「大多数のサイトでは想定する機能を提供するが、ホスト名が www.example.com の場合のみ Cookie を外部に転送する」という機能を持っている可能性
b) man-in-the-middle(中間者)攻撃により bookmarklet.js が書き換えられ、Cookie が外部に転送される可能性
c) DNS 汚染によって www.example.org が攻撃者の Web サイトへポイントされ、攻撃者の設置した bookmarklet.js が実行される可能性
a) に関しては、そもそも bookmarklet の発行元を信頼するかどうかという問題ですが、外部ファイルをインクルードする Bookmarklet は任意のタイミングで更新が行われる可能性があるため、従来の bookmarklet のように登録時にコードの内容を検証するだけでは不十分です。
b), c) のリスクは信頼できないネットワークで bookmarklet を実行することが原因ですが、どの程度のネットワークであれば bookmarklet を実行してよいとするかをユーザに指示することは難しいでしょう。
上記記事で高木氏は
解決策としては、bookmarklet に code signing を... というのは難しいので、bookmarklet の配布ページとインクルードするスクリプトに SSL を使えばよいのでは?というのが提案です。
特に hatena のように多数のユーザを抱えているサービスや、パスワードを扱うサイトでは影響範囲が大きいですし、ぜひ採用してほしいものです。
(追記: ただし、これでも a) の問題は解決されません。そもそも一般ユーザにコードの内容を確認せよということ自体難しいので、発行元の信頼性についてドメイン名を確認せよという従来の方式を徹底する必要があります。)
*
非常に簡単ですが、デモとして Cookie を alert で表示する bookmarklet を作ってみました。当然、外部への Cookie の転送は行っていません(情報処理能力テスト: あなたはこれを信用しますか?)。
Show Cookies
ログイン管理を Cookie で行うサイトで試してみるとよいでしょう。
Bookmarklet を登録するという行為が、予想以上に大きな意味を持っていることが実感できると思います。
新はてなブックマークの登録ブックマークレットは使ってはいけない
最近のブックマークレットには「script 要素を作ってその src 属性に外部ファイルを指定する」というものが多いですね。
ブックマークレットの文字数の制限を回避するためや、仕様変更・バージョンアップが行いやすいといった理由によるものでしょう。
しかしながら、このスタイルのブックマークレットが、以下のようなシナリオで大きなセキュリティリスクになり得るこということはあまり指摘されていません:
1. ユーザが、あるブックマークレットを登録する。このブックマークレットは http://www.example.org/bookmarklet.js をインクルードする。
2. ユーザが Cookie による認証を行う SSL 下の Web サイト https://www.example.com/ を開き、このブックマークレットを起動する。
この場合、次のようなセキュリティリスクが想定可能です。
a) bookmarklet.js が、「大多数のサイトでは想定する機能を提供するが、ホスト名が www.example.com の場合のみ Cookie を外部に転送する」という機能を持っている可能性
b) man-in-the-middle(中間者)攻撃により bookmarklet.js が書き換えられ、Cookie が外部に転送される可能性
c) DNS 汚染によって www.example.org が攻撃者の Web サイトへポイントされ、攻撃者の設置した bookmarklet.js が実行される可能性
a) に関しては、そもそも bookmarklet の発行元を信頼するかどうかという問題ですが、外部ファイルをインクルードする Bookmarklet は任意のタイミングで更新が行われる可能性があるため、従来の bookmarklet のように登録時にコードの内容を検証するだけでは不十分です。
b), c) のリスクは信頼できないネットワークで bookmarklet を実行することが原因ですが、どの程度のネットワークであれば bookmarklet を実行してよいとするかをユーザに指示することは難しいでしょう。
上記記事で高木氏は
そもそも、ブックマークレットの使用というのは、「.exe」ファイルの実行と同様のセキュリティリスクの伴うものであることを忘れてはならない。と指摘されていますが、ネットワークの状況如何で任意のコードが実行される可能性があるという点において、exe ファイルの実行以上に危険な状態だと言えると思います。
解決策としては、bookmarklet に code signing を... というのは難しいので、bookmarklet の配布ページとインクルードするスクリプトに SSL を使えばよいのでは?というのが提案です。
特に hatena のように多数のユーザを抱えているサービスや、パスワードを扱うサイトでは影響範囲が大きいですし、ぜひ採用してほしいものです。
(追記: ただし、これでも a) の問題は解決されません。そもそも一般ユーザにコードの内容を確認せよということ自体難しいので、発行元の信頼性についてドメイン名を確認せよという従来の方式を徹底する必要があります。)
*
非常に簡単ですが、デモとして Cookie を alert で表示する bookmarklet を作ってみました。当然、外部への Cookie の転送は行っていません(情報処理能力テスト: あなたはこれを信用しますか?)。
Show Cookies
ログイン管理を Cookie で行うサイトで試してみるとよいでしょう。
Bookmarklet を登録するという行為が、予想以上に大きな意味を持っていることが実感できると思います。
Comments