2011年にはWebGLのセキュリティ上の欠陥を指摘したhttps://www.contextis.com/resources/blog/webgl-more-webgl-security-flaws/のようなブログ投稿の波がありました。その時点で、WebGLのフレームバッファの範囲外からピクセルデータを取得するためにWebGLを使用することができるようです。 Khronosのセキュリティサイトでは、この問題は修正されたようですhttps://www.khronos.org/webgl/security/。古いデータが見えないように、新しいメモリがすべてゼロになっていると話します。WebGL 2011のセキュリティ上の欠陥？
要するに、私はここ数年のうちにこれについて多くのチャットを見たことがない、WebGLはまだ安全ではない、または今は良いことですか？現在のセキュリティ上の懸念事項は何ですか？
WebGLは何かの問題を回避しようとするものがあります。
CORS
WebGLのは、そのドメインがクロスオリジンリソース共有のアクセス許可を与える場合を除き、他のドメインから任意の画像を使用して許可していません。
これは、任意のイメージを使用できるCanvas 2D APIとは異なりますが、別のドメインのイメージを使用し、CORS権限を取得しなかった場合、キャンバスは読み取り不可としてマークされます。 getImageDataまたはtoDataURLに電話することはできません。
すべての境界が
メモリにアクセスする機能のすべて
をチェックされ、他のプログラムから残って何もデータがないので、すべてのメモリのWebGLをクリア
はすべてのバッファ、テクスチャ、レンダなどをクリアその境界をチェックしてください。あなたは、シェーダの制限が
シェーダがドライバに送信される前に事前に解析していると、彼らは一定の制限を通過しないにチェック施行され
すべてのシェーダが再書かれている
ユーザーに提供シェーダは、ドライバーに直接渡されていません。代わりに生成された変数名を使用して書き換えられ、必要に応じて境界チェックが挿入され、ドライバのバグを回避するために式が書き換えられます。特定のドライバは、回避策を追加したり、それをブラックリストしようとする問題のブラウザベンダーを持つことが判明した場合
のWebGLの実装は通常、ブラックリストに
を持っています。
一部のブラウザでは、より極端な措置
クロム（そしておそらくすぐにFirefoxが）直接GPUにアクセスするためのWebページのアクセス許可を実行しているプロセスを与えるものではありませんに行きます。 JavaScriptにバグやHTML5のバグがあると、ページでGPU（またはシステムの他の部分）にアクセスできないコードを実行できるようになります。
さらに、実際にChromeでGPUにアクセスするプロセスには、GPU以外のものにアクセスする権限がありません。例えば、そのプロセスはディスクにアクセスできません。
WebGLはJavaScriptやHTML5やImageの解凍やビデオ解読と同じように設計されているため、ブラウザでバグがあった場合は直ちにそれを修正します。
WebGLの目標は、Khronosサイトへのリンクで説明されているように、常に安全であるようになっています。しかし、2011年には、多くのWebGL実装は未だにまだ始まっておらず、うまくいっていません。あなたが発見したように、これらの初期の実装のギャップを指摘していた「空が落ちている」ブログ記事がたくさんありました。
今日まで早送りして、私は現代のWebGL実装がかなり緊密であると主張します。悪意のあるサイトやインジェクションされたコードがWebGL以外のページ上でWebGLコンテキストを作成することを妨げるものは何もないため、WebGLセキュリティのギャップがWebGL対応ページにのみ影響を及ぼすわけではないことを考慮してください。ブラウザのベンダーはこれを真剣に受け止め、未解決のセキュリティ上の問題があると思ったら、デフォルトでWebGLを有効にしたままにしません。
最近の多くの実装では、セキュリティモデルを保持するドライバが存在する場合にのみWebGLが有効になるように、blacklists or whitelistsも含まれています。
はい、デフォルトでWebGLが有効になっているブラウザの場合、ベンダーがWebGL実装のセキュリティに自信を持っていると想定するのは安全です。
マイクロソフトはセキュリティ上の欠陥を見つけるために支払った。今MicrosoftはWebGLを出荷しています – gman