たとえば、 https://www.zend2.com のようなパブリックオンラインプロキシを使用して、PHP機密データを含む自分が制御するWebページをロードする必要があるとします。 HTTPS。
クライアント(ブラウザ)、JavaScript、および/または追加のドメイン名とサーバーを変更せずに、中間のプロキシがデータの洞察を持たないようにする方法を教えてください。
ソリューションの唯一の目標は、パブリックプロキシ攻撃層(理論上)を防ぐことです。
Re-webberプロキシ(URLを入力して、そのURLのコンテンツを独自のコンテキストで表示するWebサイト)を使用する場合、ユーザーとエンドWebサイトの間でTLSを使用するとimpossible ,プロキシがそれを提供したい場合でも。
リンクしたプロキシにhttps://google.com
を入力すると、https://www.zend2.com/vip3.php?u=RyhEPtB1SQ6bFRGMjVSDaC2jhw%3D%3D&b=29
にリダイレクトされます。接続するドメインはhttps://www.zend2.com
であることに注意してください。これは、TLSハンドシェイクに使用するドメインです。ブラウザーがwww.zend2.com
ではなくgoogle.com
からの有効な証明書を期待しているため、それ以外の場合は証明書の警告が表示されます。次に、プロキシは宛先サイトと独自のTLSハンドシェイクを行い、コンテンツを要求し、それを復号化し、それを見て、再暗号化して送信します。
このサービスは目の前で中間者攻撃を実行します! HTTPSを介してロードする場合でも、ロードする各Webサイトに独自のHTMLコードを追加します。このコードには、ロードしたWebサイトのコンテキストで実行されるJavaScriptが含まれています。必要に応じて、これをあらゆる種類のXSS攻撃に使用できます。 Webサイトは、アクセスするコンテンツを操作できること、および操作することを実証しているため、機密情報の送信またはアクセスに使用しないでください。
これを回避するには、rewebberサービスを使用しないでください。プロキシサーバーを適切に使用するには、Webブラウザーの接続設定にプロキシサーバーを入力します。その場合、Webブラウザはプロキシサーバーを使用していることを認識しており、プロキシからではなく実際の宛先からのTLS証明書を予期します。その場合、プロキシによる盗聴や操作は不可能になります。
SSLの欠陥の可能性を除いて、証明書がアクセスしているサイトに属していることを確認できます。 SSLが安全であれば、データも安全でなければなりません。証明書の偽造の実現可能性についてあまり確信はありませんが、一般的に読んだのは、適切な機関によって署名されている場合、それは本物であるということです。最初にいくつかの調査を行いますが、SSLが安全であると仮定してデータが傍受される可能性は低いと思いますが、証明書を偽造する方法はあると思います(警告は表示されません-証明書が信頼できることを確認してください) )。