121

ボブは、何かを達成するために Web アプリケーションを使用します。と：

  • 彼のブラウザはダイエット中のため、 Cookieをサポートしていません。
  • Web アプリケーションは人気のあるアプリケーションであり、特定の瞬間に多数のユーザーを処理するため、適切にスケーリングする必要があります。セッションを維持すると同時接続数に制限が課され、もちろん、無視できないほどのパフォーマンス ペナルティが発生する限り、セッションのないシステムが必要になる場合があります :)

いくつかの重要な注意事項:

  • トランスポート セキュリティ( HTTPSとその親友) があります。
  • カーテンの後ろで、Web アプリケーションは現在のユーザーに代わって多くの操作を外部サービスに委任します(これらのシステムは Bob をユーザーの 1 人として認識します) - これは、Bob の資格情報を外部サービスに転送する必要があることを意味します。

では、Bob を (すべての要求で) どのように認証するのでしょうか? そのようなことを実装するための合理的な方法はどれですか?

  • HTMLフォームの隠しフィールドを介して資格情報を使用してテニスをしています...ボールには資格情報（ユーザー名とパスワード）が含まれており、2つのラケットはそれぞれブラウザーとWebアプリケーションです. つまり、Cookie ではなくフォーム フィールドを介してデータを送受信する場合があります。Web 要求ごとに、ブラウザーは資格情報を送信します。ただし、単一ページのアプリケーションの場合、資格情報を含むWeb フォームがWeb ページの存続期間全体にわたって維持される可能性があるため、これはテニスをするのではなく、ゴム製の壁に対してスカッシュをするように見える場合があります。（そして、サーバーは資格情報を返さないように構成されます）。
  • ユーザー名とパスワードをページのコンテキストに保存します-JavaScript変数など。ここでは単一ページが必要です、私見。
  • 暗号化されたトークン ベースの認証。この場合、ログイン アクションにより、暗号化されたセキュリティ トークン (ユーザー名 + パスワード + 何か) が生成されます。このトークンはクライアントに返され、今後のリクエストにはトークンが付随します。これは理にかなっていますか？すでにHTTPSがあります...
  • 他...
  • 最後の手段: これを行わないでください。資格情報をセッションに保存してください。セッションは良好です。クッキーの有無にかかわらず。

前述のアイデアのいずれかに関して、Web / セキュリティに関する懸念はありますか? 例えば、

  • タイムアウト-資格情報とともにタイムスタンプを保持する場合があります (タイムスタンプ = ボブが資格情報を入力した時刻)。たとえば、NOW - タイムスタンプ > しきい値の場合、リクエストを拒否することがあります。
  • クロスサイト スクリプティング保護 - 違いはありませんよね?

これを読むために時間を割いていただきありがとうございます:)

4

2 に答える 2

79

ああ、私はこれらの質問が大好きです-セッションなしでセッションを維持します。

私は、アプリケーションの評価中にこれを行う方法を複数見てきました。一般的な方法の 1 つは、あなたが言及したテニスの方法です。ユーザーを認証するために、すべての要求でユーザー名とパスワードを送信します。私の意見では、特にアプリケーションが単一ページでない場合、これは安全ではありません。また、将来的に認証に加えて承認をアプリに追加したい場合は特に、スケーラブルではありません (ただし、ログインに基づいて何かを構築することもできると思います)。

完全にステートレスではありませんが (JavaScript を実行していると仮定して) 人気のあるメカニズムの 1 つは、セッション Cookie を JavaScript に埋め込むことです。私のセキュリティ担当者はこれを叫んでいますが、実際にはうまくいく可能性があります - すべてのリクエストにはX-Authentication-Tokenヘッダーまたはそのようなものをバックエンドでデータベース、メモリ内のファイルストアなどにマップして、ユーザーを検証します。このトークンは、指定した時間のタイムアウトを持つことができ、タイムアウトした場合、ユーザーは再度ログインする必要があります。これはかなりスケーラブルです。データベースに格納し、その 1 つの SQL ステートメントを実行し、適切なインデックスを使用すると、複数の同時ユーザーであっても、実行にほとんど時間がかかりません。ただし、ここでの負荷テストは間違いなく役立ちます。質問を正しく読むと、これが暗号化されたトークン メカニズムになります。ただし、ユーザー名 + パスワード + 他のものを組み合わせて使用​​するのではなく、たとえば 32 文字の暗号学的にランダムなトークンを使用することを強くお勧めします。予測できませんが、ユーザー ID などと関連付けることはできます。

どちらを使用する場合でも、安全に送信されていることを確認してください。HTTPS はネットワーク全体でユーザーを保護しますが、URL を介してセッション トークンを漏えいした場合 (またはさらに悪いことに、URL を介して資格情報を漏えいした場合) は保護されません。ヘッダーを使用することをお勧めします。それが不可能な場合は、毎回 POST リクエストを介してトークンを送信することをお勧めします (これは、ユーザーのブラウザーの非表示のフォーム フィールドを意味します)。POST リクエストを使用する後者のアプローチでは、CSRF 防御を使用する必要があります。場合によっては、トークン自体を使用することは、ある種の CSRF 防御である可能性があると思います。

最後になりましたが、期限切れのトークンをパージするメカニズムがバックエンドにあることを確認してください。これは、これまで多くのアプリケーションにとって悩みの種でした。認証トークンのデータベースは急速に成長しており、決して消えることはありません。複数のユーザー ログインをサポートする必要がある場合は、必ず数を制限するか、各トークンの時間制限を短くしてください。前に述べたように、負荷テストはこれに対する答えかもしれません。

他にも考えられるセキュリティ上の問題はいくつかありますが、この段階で対処するには範囲が広すぎるため、すべての使用 (および悪用) ケースを念頭に置いておけば、おそらくかなり適切なこのシステム。

于 2013-12-19T06:31:38.123 に答える
1

ログインオプションについて - 通常は、ゲストにもセッションをサポートしたいと考えています。

したがって、ログインを強制したい場合は、暗号化されたトークン オプションが適している可能性があります。なんとなくゲストセッションにもいいかも。別の方向では、URL へのトークンの追加とテニス オプションを組み合わせます。

URL だけで資格情報を送信するのは危険な場合があることに注意してください。たとえば、HTTP リファラー ヘッダーを介して、またはトラフィックを検査したりコンピューターを監視したりするだけで、トークンが漏洩する可能性があります。

もう 1 つは、Cookie を使用できる場合でも、クロス サイト リクエスト フォージェリ (CSRF) 攻撃から身を守るために、ランダム トークンまたはランダム ベリファーを追加することをお勧めします。

于 2013-12-15T09:19:20.003 に答える