2017-03-23 7 views
3

私は自分のサイトにHPKPヘッダーを追加しましたが、ChromeやSafariには敬意を表しません。私はプロキシを設定し、chrome://net-internals/#hstsに行って私のドメインを探して手動でテストしましたが、それは見つかりませんでした。 HPKPは正しいと思われ、HPKP toolsetを使ってテストしましたので、有効であることがわかりました。ChromeとSafariがHPKPを迎えることはありません

私は私の流れで変なことをしているかもしれないと思っています。私はmyapp.example.com以上のWebアプリを持っています。ログインすると、アプリケーションはauthserver.example.com/beginにリダイレクトされ、OpenID Connect認証コードフローが開始されます。 HPKPヘッダーはauthserver.example.com/beginからのみ返され、これが問題になると思います。私はinclude-subdomainをHPKPヘッダに入れているので、これは問題ではないと思います。

これはHPKPヘッダ(改行は読みやすくするために追加された)である:

public-key-pins:max-age=864000;includeSubDomains; \ 
pin-sha256="bcppaSjDk7AM8C/13vyGOR+EJHDYzv9/liatMm4fLdE="; \ 
pin-sha256="cJjqBxF88mhfexjIArmQxvZFqWQa45p40n05C6X/rNI="; \ 
report-uri="https://reporturl.example" 

ありがとう!

+0

ChromeとSafariに限定されません。最近のブラウザはすべてそれを行います。多くのWebコンポーネントはWebセキュリティモデルの「機能」*のためにそれを行います。 – jww

答えて

1

私は一種の過去を潜入、

RFC 7469, Public Key Pinning Extension for HTTP ...私はプロキシを設定することにより、手動でそれをテスト...私のサイトにHPKPヘッダを追加しましたが、それはクロムやSafariで表彰されていません君は。 IETFはそれを上書きして公開したので、攻撃者は既知の良いピンセットを破ることができます。これは、標準で一度、"上書き"で記載されていますが、詳細は記載されていません。また、IETFは、セキュリティの考慮事項のセクションで議論を公開することに失敗しました。

さらに、設定したプロキシが無効になっています。誤ったプロキシ、モバイルデバイスOEMによってインストールされたプロキシ証明書、またはそれをインストールするためにユーザーを騙した攻撃者によって制御されるプロキシであるかどうかは関係ありません。 Webセキュリティモデルと標準によって許可されています。彼らは傍受を受け入れ、それを有効なユースケースと考えています。彼らがした他の

何かが壊れたピンセットの報告はならないまたはべきではないを行いました。これは、ユーザーエージェントがカバーアップに共謀していることを意味します。これは、セキュリティ上の考慮事項のセクションでは説明していません。彼らは本当にあなたの想定される安全な接続が傍受されていることを人々に知らせたくありません。

ウェブセキュリティモデル外に移動することを避けるための最良の方法です。セキュリティが重要な場合は、ブラウザベースのアプリケーションを使用しないでください。ハイブリッドアプリを使用して、自分で固定します。ハイブリッドアプリはWebViewコントロールまたはビューをホストできますが、引き続きチャンネルにアクセスしてパラメータを確認します。また、OWASP's Certificate and Public Key Pinningを参照してください。

IETFメーリングリストのComments on draft-ietf-websec-key-pinningも参照してください。このコメントの示唆の1つは、タイトルを"公開鍵を使用して上書きする拡張機能"に変更して機能を強調表示することでした。当然のことながら、それは彼らが望むものではありません。彼らはユーザーの知識なしに秘密裏にそれをやろうとしています。

2.7:


ここではRFC 6479から関連するテキストです。事前にロードされたピンリストとの相互作用

UAは、埋め込み情報のビルトインリストなどの追加情報を 情報に追加する実装を選択することがあります。 このようなUAは、ユーザがそのような追加のソースを無効にすることを可能にするべきであり、 はそれらを考慮に入れないようにすることを含む。

以前に観察されたPKPヘッダー応答フィールドの ピンとピンの両方を内蔵している既知の固定ホストの有効ポリシーは、実装定義の です。

+0

詳細な回答ありがとうございます!私は以下の答えにコメントを残しましたが、あなたの答えはかなり似ていますが、私はそれがこの答えにも関係していると思います。 –

1

ローカルにインストールされたCA(あなたが言うようにプロキシに使用されているようなもの)は、HPKPのチェックを無効にします。

大手企業で使用されているウイルス対策ソフトウェアとプロキシは、基本的にMITMがローカルで発行された証明書を通じてトラフィックをトラップし、それ以外の場合はトラフィックを読み取ることができないため、インターネットを完全に壊さないために必要です。

CAをローカルにインストールするとマシンにアクセスする必要があると主張する人もいますが、とにかくゲームオーバーですが、私にとってもこれはHPKPの保護を大幅に軽減し、HPKPを使用するリスクが高いことを意味します私は本当にそれのファンではありません。

+0

それでは、HPKPのポイントは何ですか?たぶん私は何かが欠けているかもしれません...また、なぜ私は 'chrome:// net-internals /#hsts'の設定を見ることができませんでしたか?あなたが言っているのであれば、それはローカルプロキシによってオーバーライドされていますが、それを見たいと思っています。 –

+1

HPKPは非プロキシトラフィックにのみ有効です。私が言いましたように、私にとっては、スーパーフィッシュのような攻撃から身を守ることができないという意味で、大きな穴です。はい、私は地元のPCが侵害されたら、あなたはできることはほとんどありませんが、まだ大きな穴のように見えるということに気づいています。そして、HPKPがそうすることができる危険性(サイト所有者が自殺していることが原因)を加えれば、私は本当にそれが努力する価値があるとは思わないということです。 –

+1

ポリシーは、ポリシーが検証されている場合にのみ、 'chrome:// net-internals /#hsts'に保存されます。これは、有効でないポリシーが格納されてサイトが壊れるのを防ぐためです。プロキシを介してのみ訪問した場合、HPKPポリシーは決して有効ではなく(その接続にピンが使用されていないため)、ポリシーは無視されます。プロキシなしで訪問する場合は、そのページに保存して利用できるようにする必要があります。また、有効なポリシーには2つの完全に独立したピンを使用する必要があるので、ルートCA証明書とリーフ証明書だけを固定し、両方が同じチェーンで使用されている場合は動作しません。 –

関連する問題