13

私は現在、AJAXベースのサイトの認証に取り組んでおり、この種のベストプラクティスについて誰かが推奨事項を持っているかどうか疑問に思っていました。

私の最初のアプローチは、Cookieベースのシステムでした。基本的に、認証コードを使用してCookieを設定し、すべてのデータアクセスでCookieが変更されました。また、認証に失敗した場合は常に、ハイジャック犯を防ぐために、そのユーザーによるすべてのセッションの認証が解除されました。セッションをハイジャックするには、誰かがログインしたままにしておく必要があり、ハッカーはセッションをスプーフィングするために最後のCookie更新を送信する必要があります。

残念ながら、AJAXの性質上、複数のリクエストをすばやく行うと、順序が狂ってCookieが間違って設定され、セッションが中断される可能性があるため、再実装する必要があります。

私のアイデアは次のとおりです。

  • 明らかに安全性の低いセッションベースの方法
  • サイト全体でSSLを使用する（やり過ぎのようです）
  • ssl認証されたiFrameを使用して安全なトランザクションを実行します（jqueryのハッキングを少し行うことで、これが可能であると思います）

問題は転送されるデータではなく、唯一の懸念は、誰かが自分のものではないアカウントを制御する可能性があることです。

明らかに安全性の低いセッションベースの方法

4

6 に答える 6

1

個人的には、サイト全体（またはそのほとんど）にSSLを使用するのがやり過ぎだとは思いませんでした。たぶん少し前、速度と送りが遅かったとき。今、私はサイトのどの部分もSSLの下に置くことを躊躇しません。

サイト全体でSSLを使用することが許容できると判断した場合は、サーバーが401応答を 返す古い「基本認証」を使用することを検討してください。これにより、ブラウザーはユーザー名/パスワードの入力を求められます。アプリケーションがこのタイプのログインで動作できる場合、ブラウザが適切なクレデンシャルを使用してリクエストを再送信するため、AJAXおよびサイトへの他のすべてのアクセスに最適です（SSLを使用する場合は安全ですが、SSLを使用する場合のみです） --プレーンhttpで基本認証を使用しないでください！）。

于 2008-09-23T03:26:50.127 に答える
1

一般的な解決策は、ユーザーのセッションIDをハッシュし、それをすべてのリクエストで渡して、リクエストが有効なユーザーからのものであることを確認することです（このスライドショーを参照）。これはCSRFの観点からはかなり安全ですが、誰かがデータを盗聴している場合、データが傍受される可能性があります。ニーズに応じて、SSLは常に最も安全な方法になります。

于 2008-09-30T08:24:13.103 に答える
1

SSL は必須であり、複数のユーザーが使用できる透過的なプロキシ接続を防ぎます。次に、受信 IP アドレスを認証済みの IP アドレスで確認するだけです。

再認証:

  • IPアドレスが変わるとすぐに
  • リクエストなしで n 秒を超えるタイムアウトが発生した場合
  • 重要な取引について個別に
于 2008-09-24T17:47:29.363 に答える
0

サーバーからの各応答に「生成された」タイムスタンプを付け、AJAXアプリケーションが常に最新のタイムスタンプを持つCookieを使用できるとしたらどうでしょうか。

于 2008-09-23T03:20:52.140 に答える
0

最善の策は、ApacheやTomcatで以前に認証された接続を介してSSL接続を使用することです。 どちらか一方のフォームベースの認証で、必要なSSL接続を使用すると、安全な接続が得られます。WebアプリはセッションのセキュリティとIDを提供でき、クライアント側のAjaxはセキュリティを気にする必要がありません。

于 2008-09-23T03:27:38.720 に答える
0

Billy Hoffman と Bryan Sullivan による Ajax Security という本を読んでみてください。セキュリティに対する私の考え方が変わったことがわかりました。Ajax の各フェーズには、非常に具体的な提案があります。

于 2008-09-30T02:50:15.717 に答える