web-dev-qa-db-ja.com

Webセッション攻撃と対策のリスト

PHPで新しいウェブサイトを書いています。ユーザーセッションデータを追跡するためにCookieを使用します。デザインを完成させる前に、サイトが攻撃に対して脆弱でないことを確認したいと思います。攻撃方法の一覧を書いて、それぞれの対策を考えましたが、これ以上の攻撃方法は誰にでも考えられますか？

私が考えることができるすべての攻撃方法のリスト：

  1. 推測/ブルートフォースセッションCookie
  2. セッションCookieを盗む（例：攻撃者がセッションCookieをUSBに保存した場合）
  3. クロスサイトスクリプティング
  4. フィッシング（セッション固定）
  5. SQLインジェクション
  6. HTTPヘッダーインジェクション

PHP標準セッション関数ではなく、独自のデータベースを使用してセッション情報を保存することに注意してください。攻撃を検出すると、warn_and_halt()という関数を実行します攻撃をログに記録してsysadminに通知し、攻撃を受けているセッションを停止します。

上記の各攻撃タイプに対する私の対策は次のとおりです。

  1. Cookieに格納されたセッションIDに大きな整数を使用するのではなく、独自の乱数を生成し、SHA-1などでハッシュして、推測を少し難しくします。もちろん、この方法で作成されたセッションIDは一意ではない可能性があるため、データベース内の他のすべてのセッションIDを確認し、新しく生成されたセッションIDがすでに存在する場合は再生成する必要があります。私はこの措置に自信を持っています。

  2. USBが別のコンピューターに転送され、セッションCookieが別のブラウザーに読み込まれることを想定しています。セッションごとにユーザーエージェント（ブラウザー名）をログに記録します。セッション中にユーザーエージェントが変更された場合は、warn_and_halt()を使用します。セッションIDを検証するためにIPアドレスを使用している人を読んだことがありますが、完全に無害な理由（たとえば、ユーザーのルーターがリセットしてネゴシエートする場合）のためにセッション中にIPアドレスが変更される可能性があるため、これを使用することはないと思いますISPの新しいIP。 ここで他の対策を提案できますか？

  3. セッションCookieをHTTPonlyに設定し、受信Cookieのドメインも確認します。私の見解では、ブラウザーでこれが発生するのを防ぐためにできることはあまりありません-ブラウザーはHTTPonlyフラグに準拠しないことを選択する可能性があります-私には何もできません！ XSSを防ぐより良い方法を誰かが知っていますか？

  4. ユーザーに「悪い」ユーザーが自分のサイトにログインし、<a href='javascript:void(0);' onclick="document.cookie='sessionid=xxxx';document.location='http://mywebsite/'">などのリンクをユーザー「oblivious」にメールで送信することでフィッシングが発生することを想定しています。これにより、「気付かない」ことなくセッションCookieが設定されます。次に、「気付かない」が個人情報を入力し、ユーザー「悪い」がこの情報を持っています！ほとんどのブラウザは新しいCookieのドメインをmywebsiteとして設定することを許可しないので、「気付かない」はかなり安全です。それでも、各Cookieの受信ドメインをチェックして、それが自分のWebサイト用であることを確認します。セッションIDの保存には、GETまたはPOSTではなく、必ずCookieを使用します。また、アクセスしたすべてのページのセッションIDを変更することで、セッションの修正に対抗します。

  5. SQLインジェクションは、セッションIDを盗むよりもはるかに広い範囲の問題ですが、私は常に受信データ（Cookieを含む）をエスケープし、正規表現を使用して間違った文字を除外することで、これに対処します。これはかなりよくカバーされていると思います。

  6. HTTPヘッダーインジェクションについて学習しました。それにもかかわらず、特にキャリッジリターンと着信ヘッダーの検証では、着信ヘッダーフィールドをエスケープするだけで、簡単に対処できます。

したがって、これらは私が考えることができるすべての攻撃と対策です（オンラインでかなり読んだ後）。私が見逃したものを見つけたら、返信してください。私の対策のいずれかが不十分であると思われる場合は、教えてください。

web-browserphpattackshttpweb-service
3
mulllhausen

「xssを防ぐより良い方法を誰かが知っていますか？」

XSSを防ぐ最善の方法は、XSSについて理解し、コードにXSSの脆弱性を導入しないことです。次のドキュメントを読むことから始めます。

（ XSSを防止するためのPHP関数 も参照してください。）

次に、Webセキュリティについて読むことをお勧めします。開発者向けのWebセキュリティの次の紹介を読むことから始めます。

これは、XSSを回避するのに役立ちます。 Webとこのサイトには、さらに多くのリソースがあります。見てください。

注：HTTPonlyフラグはXSSを妨げません。また、一般的な考えに反して、追加のセキュリティはほとんど提供されません。WebサイトにXSSの脆弱性が含まれている場合でも、攻撃者がユーザーに悪質な行為を行う可能性は依然としてあります。 HTTPonlyフラグを使用すると、攻撃者の作業が困難になりますが、結局のところ、高度な攻撃者はおそらく同じくらい遠くまで到達すると思います。現在、私はHTTPonlyについては議論していません。 HTTPonlyフラグは、サイトの機能を損なうものでなければ問題ありません。しかし、XSSに対する防御策として頼ってはいけません。それは特定の多孔性防御です。

3
D.W.

あなたのポイントのいくつかについて：

  1. 乱数をハッシュすると、再び乱数が得られます。これを行うのは、元の乱数が小さなスペース（つまり推測可能）からのものであり、他の秘密の値がハッシュに入力された場合（攻撃者が同じハッシュを自分で行うことができないため）です。そして、これはMACと呼ばれます。

  2. 攻撃者がセッションCookieを盗むためにUSBを使用しなければならない理由（またはこれがどのように有利になるか）はわかりません。また、ユーザーエージェント文字列も偽造できます。また、攻撃者はどのようにしてCookieにアクセスするのですか？

    • ブラウザの動作を確認するためにクライアントコンピュータに直接アクセスできる場合、彼女は何でも実行できます（これを防ぐ方法はありません）。
    • 彼女がネットワークトラフィックを確認し、そこからCookieを読み取れる場合は、何か問題があります。 SSLを使用（またはより優れたTLS）のトランスポート、つまりHTTPS。
2
Paŭlo Ebermann