博士

やあ、ロボ子。今日のニュースは、オンラインストリーミングアセットのウォーターマークの脆弱性についてじゃ。

ロボ子

ウォーターマークの脆弱性ですか。具体的にはどのようなものでしょうか、博士？

博士

ふむ、記事によると、ウォーターマークは著作権表示や不正な配布の抑制に使われるのじゃが、実装方法によっては簡単に回避できるらしいぞ。

ロボ子

なるほど。例えば、どのような回避策があるのですか？

博士

例えば、単純なHTML要素として実装されたウォーターマークは、要素を削除するだけで回避できるのじゃ。フローティングdivとかじゃな。

ロボ子

それは簡単ですね。JavaScriptベースのウォーターマークの場合はどうでしょうか？

博士

JavaScriptで動的に生成・監視される要素は、ちょっとやっかいじゃな。要素の削除を試みると再生成されたり、アセットの再生が停止されたりするらしい。

ロボ子

それに対する回避策はあるのでしょうか？

博士

JavaScriptファイルの削除、コードのデバッグ、CSSスタイルの変更などが考えられるみたいじゃぞ。なかなか骨が折れるのじゃ。

ロボ子

なるほど。他にも脆弱性の事例はありますか？

博士

ピクチャーインピクチャー（PiP）機能を使うと、ウォーターマークが適用されたビデオ要素から簡単にエスケープできる場合があるらしいぞ。ずる賢いのじゃ！

ロボ子

PiPですか。それは意外ですね。

博士

それから、Subresource Integrity (SRI) の誤用も問題じゃ。SRIを削除することで保護を回避できる場合があるらしい。

ロボ子

SRIはセキュリティのためにあるはずなのに、それを逆手に取られるとは…。

博士

さらに、ウォーターマークの内容自体を改ざんできる場合もあるみたいじゃ。アカウント名をユーザープロファイルから変更できる場合、攻撃者が表示内容を制御できる可能性があるのじゃ。

ロボ子

それは深刻ですね。ウォーターマークの意味がなくなってしまいます。

博士

オフライン再生についても触れられておるぞ。HLS（HTTP Live Streaming）を利用したビデオ配信において、m3u8プレイリストファイルを解析して、ビデオやオーディオセグメントをダウンロードすることで、オフライン再生が可能になるのじゃ。

ロボ子

なるほど。セグメントが暗号化されている場合はどうなるのでしょうか？

博士

その場合は、m3u8ファイルに記述された暗号化方式と鍵URIを利用して復号化する必要があるのじゃ。ffmpegやopensslを使ったり、専用のPythonスクリプトを使う方法もあるみたいじゃな。

ロボ子

色々な方法があるんですね。でも、結局のところ、ウォーターマークはあまり信用できないということでしょうか？

博士

ウォーターマークは責任追及と抑止の手段としては重要じゃが、クライアント側の制御を持つ攻撃者によって容易に回避される可能性があることは覚えておくべきじゃな。セキュアなストリーミングソリューションを開発する際は、ウォーターマークと、サーバーサイドレンダリングやDRMなどの強化された配信メカニズムを組み合わせることを検討すべきじゃ。

ロボ子

DRMですね。Widevine、PlayReady、FairPlay Streamingなどのフレームワークがありましたね。

博士

そうじゃ。DRMも組み合わせることで、より強固なセキュリティを確保できるのじゃ。しかし、DRMもまた、攻撃の対象になることを忘れてはならないぞ。

ロボ子

セキュリティ対策は、常にイタチごっこですね。

博士

まさにそうじゃ！ ちなみに、このニュースを提供しているKulkan Securityという会社は、ペネトレーションテストを専門としているらしいぞ。一度、ロボ子のセキュリティホールをペネトレーションテストしてあげようかの？

ロボ子

それはご遠慮しておきます…。