Webサイトのほとんどの脆弱性は、HTTP要求の変更、URLまたはヘッダーのなりすまし、およびサーバーに対するその他の予期しないアクションの結果です。 通常のユーザーはこれを行うことができませんが、最新のアプリケーションはクライアントとサーバーで構成されているため、実際にはサーバーはユーザーがクライアント部分を使用する方法を制御できません。
このため、「二重検証」はいたるところに存在します。画面には、ユーザーがアクセスできるオブジェクトのみを表示する必要があり、さらにユーザーがこのオブジェクトにアクセスできるかどうかをサーバーで確認する必要があります。
そこでSecureCanvasのアイデアが生まれました-サイトを一種のATM /ターミナルに変え、ユーザーはマウスをタイプして動かすだけです。 悪意のあるリクエストをインターセプトする代わりに、ゲームを別のプレーンに転送し、攻撃対象をゼロに減らして、ユーザーが自分がすべきことだけを実行できるようにします-サイトと対話します。
現在、ユーザーがbank.comをダウンロードする場合、このサイトはクラウド内の仮想の安価なWebkitインスタンスにロードされ、シンクロナイザーページがユーザーに返されます。 このページは、すべてのクリックとクリックをWebソケットを使用してクラウドにブロードキャストします。クラウドでは、これらのアクションは実際のブラウザーで既に実行されています。 したがって、コンソールを開いたり、クエリやソースコードを確認したりすることは不可能です。
最初は、VNCセッションとキャンバス要素に基づいてこれを実装し、クラウドブラウザーがサイト自体の画像を返すようにするというアイデアでした。 しかし、このアイデアは失敗する運命にあります-画質は大幅に劣化し、フォントはぼやけ、ネットワーク遅延ユーザーはあまり気に入らないでしょう。 したがって、より有望なアプローチは、クラウドブラウザーがページの特別なDOMスナップショットを送信し、以前のスナップショットとの差分を作成することです（同様のテクノロジーがReact.jsで他の目的に使用されます）。
したがって、サイトの応答性は同じレベルのままです-あなたは同じ具体的でよく描かれたタグを見るでしょうが、バックグラウンドで入力またはクリックしたものはすべてクラウドブラウザに転送され、そこではJavascriptロジックのみが実際のbank.comサーバーへのリクエストを生成し、外部を変更しますページビュー。
なりすましから保護するためのURL検証ツールもあります。 URLの使用を単に禁止し、ルートアドレスのみをダウンロードできます。これはオンラインバンクに最適です。 各アドレスにHMACで署名できるため、必要なアドレスをダウンロードできるのは署名の名前のみです（このアドレスに対してSIGNを使用せずに/ private_info / 2-SIGNを開くことはできません。インターフェースでこのリンクをクリックした後にのみSIGNが発行されます）。 または、最も便利なオプションは、以前にダウンロードされたアドレスのみをダウンロードすることです（インターフェースとの対話の結果）。
SecureCanvasが防御できない唯一のことは、インターフェイスベースの脆弱性です。 サイトのインターフェースのみを使用して攻撃を実行できる場合-ユーザー名に「または1 = 1」を入力するかブルートフォースを実行すると、このサイトには何も役立ちません。
このテクノロジーは完全に実現可能であり、ターゲットオーディエンス（オンラインバンクやその他の金融サービスが頭に浮かぶ）と投資に関する問題を解決するために残っています。本当に必要です。 ちなみに、アイデアがナンセンスに思えた場合（そして、私はあなたを理解できる）、最初に形状技術を見て、次にそれらに行われた6,600万ドルの投資を見てください。 はい、これは不可能です。 または、彼らがすることは役に立たないでしょう。 AIがなければ、JSが生成できる要求とできない要求を理解することは不可能です。 ところで、彼らのタスクはほぼ同様です-応答の完全な難読化を通じてサイトとの「想定外の」対話を禁止します（不明瞭によるセキュリティは失敗する運命にあります）
しかし、SecureCanvasを実装しています（もちろん、困難なしではありません）。その利点は、肉眼でも（「保護画面の下にあるATM内のサイトのような」）一般の人にも見えます。 夢を見たり、議論しましょう:)