3

私は HttpOnly Cookie と、XHR リクエストを TRACE メソッドと組み合わせて使用​​してサーバーからエコーバックされた Cookie 値を取得する可能性に存在する問題についていくつかの調査を行いました。

安全な Web アプリケーションの場合、現在、次の設定を行っています。

  • ログイン時にセッション Cookie が送信され、セキュアおよび httpOnly プロパティが設定されます
  • TRACE http メソッドがドメイン全体で無効になっている (「405 メソッドは許可されていません」を返す)

クロスサイト リクエスト フォージェリを回避するために、フォームの非表示フィールドにランダム キーを追加しました。このキーは、リクエストが受け入れられるように各 POST リクエストで返される必要があります。

これとは別に、許可されているタグと属性を選択するためにホワイトリストを使用して、すべての HTML がデフォルトでエスケープされますが、これが十分ではない理由を説明するために:次の方法で、Internet Explorer で JavaScript を渡すために使用できます。

<span style="width: expression(alert('Example'));"> </span>

そして、最後の質問です。誰か、このセットアップの潜在的な欠陥に対する欠陥や提案を指摘していただけますか? それとも、同じまたはまったく異なるアプローチを使用していますか?

既知の問題:

  • すべてのブラウザが httpOnly をサポートしているわけではありません
  • css JS 式をフィルタリングするだけでは不十分です。@import(external-style-sheet) も機能します
4

2 に答える 2

7

あなたの投稿 (少し誤解を招くタイトル) に基づいて、Httponly 属性が document.cookie を介した Cookie へのアクセスを防ぎ、XSS がユーザーの偽装を含む他の厄介なことから保護するために何もしないことを理解していると思います (つまり、する必要はありませんCookie を盗み、取得した CSRF トークンを使用できるようにする)、ブラウザで脆弱なプラグインをチェックしてマルウェアをインストールする、JavaScript キーロガーをインストールする、内部ネットワークをスキャンするなど、ページを書き換えるなど。

あなたが言うように、各タグのタグと属性をホワイトリストに登録するだけでは不十分です。おそらくホワイトリストの正規表現を介して、属性値に対してより厳密な検証を適用する必要があります。

XSS や CSRF に直接関係しないいくつかの考慮事項の不完全なリスト:

  • 終了タグが欠落しているなどの不完全な html をどのように処理しますか?
  • ユーザー入力の一重引用符、二重引用符、およびバックスラッシュをどのように処理しますか?
  • URL リンクや属性値など、さまざまなコンテキストで出力されるユーザー入力をどのように処理しますか?
  • 入力が実際に入力文字セットエンコーディングと一致することを確認しますか?
  • 応答ヘッダーとメタ タグで Content-Type を明示的に設定していますか?
  • HTTP 経由で提供される中程度の機密性の高いユーザー ページがある場合、適切な Cache-Control ヘッダーを設定しますか?
  • ユーザー入力がサンドボックス化されていることをどのように保証しますか? 具体的には、CSS を許可する場合、スタイルが制限された領域にのみ適用され、他の領域を変更できないようにするにはどうすればよいでしょうか?
  • サイトの広告を含むサードパーティの JavaScript を使用していますか?
  • セッション Cookie は改ざんから保護されていますか?
  • ユーザーが変更できる HTTP ヘッダーを含むすべての入力をサニタイズしますか?
  • CSRF トークンは本当にランダムですか? はいの場合、ランダムトークンをどのように生成しますか? そうでない場合、どのように構築しますか？
  • プリペアド ステートメントとバインド パラメータを使用していますか?
  • ユーザーはファイルをアップロードできますか?
  • ユーザーがアップロードした画像などのコンテンツを提供していますか? はいの場合、ファイル コンテンツ (GIFAR の欠陥) をどのように検証しますか? また、ファイルは同じドメインから提供されますか?
  • API アクセスを提供していますか? はいの場合、同じドメインでホストされていますか? どのようなクロスドメイン制限がありますか?
于 2010-02-17T07:33:32.410 に答える
2

HttpOnly Cookies は優れたセキュリティ対策ですが、XSS を停止するようには設計されておらず、攻撃者が xss の脆弱性を悪用するのをより困難にするだけです。詳しく説明しましょう。

トークン ベースの xsrf セキュリティ システムは XSS を使用してバイパスできるため、攻撃者は xss の脆弱性を悪用するために Cookie を知る必要はありません。

クロスサイト リクエスト フォージェリを回避するために、フォームの非表示フィールドにランダム キーを追加しました。このキーは、リクエストが受け入れられるように各 POST リクエストで返される必要があります。

たとえば、XSS を使用すると、攻撃者は xmlhttprequest を使用してドメイン上の任意のページを読み取ることができる JavaScript を実行できます。したがって、攻撃者は xmlhttprequest を使用して XSRF トークンを読み取り、それを使用して POST 要求を偽造できます。これは、XSS の 1 つのプロパティが、Same Origin Policyの中断を許可するためです。例として、これは私が今説明したことを行う、私が書いた実際のエクスプロイトです 。

XSS を防ぐ最善の方法は、不快な文字<>を対応する html エンティティに変換することです。PHP では、次のことをお勧めします。

$var=htmlspeicalchars($var,ENT_QUOTES);

これにより、一重引用符と二重引用符が修正されるため、ほとんどのxss を停止できます。結果の文字列が html タグにある場合でも。たとえば、引用符を置き換えると、攻撃者はこのエクスプロイトを使用できなくなります。これは、攻撃者が "onload=" を実行するために引用符を破る必要があるためです。

$var="' onload='alert(document.cookie)'";

このhtmlに：

print("<img src='http://HOST/img.php?=".$var."'>");

ただし、<span>タグを使用してリストした特定のケースは、攻撃者が引用符を必要としないため、依然として問題になる可能性があります! <script>タグ内に配置すると、xss の脆弱性も発生します。ユーザー入力が配置される場所については安全に注意してください。すべての脆弱性に「万能」または「特効薬」はありません。

HTTP の "TRACE" メソッドを利用する "XST" 攻撃は、実際には現実的な攻撃ではありません。その理由は、攻撃者が Web ブラウザに「TRACE」http 要求を強制的に実行させることができないためです。攻撃者は、「GET」の場合は javascript またはタグを使用して「GET」および「POST」メソッドを強制でき<img>ますが、HTTP ヘッダーの残りの部分は立ち入り禁止です。TRACE は、ほぼすべての Apache システムでデフォルトで有効になっていることに注意してください。本当に危険な場合は、まとめて削除されます。Nessus などの多くのセキュリティ テスト ツールは、Apache が TRACE をサポートしている場合にエラーをスローしますが、簡単に無効にすることもできます。

于 2010-02-17T07:46:26.370 に答える