0

したがって、この質問に答えるだけでなく、提案や改善を投げ出すこともできます。私はこれまで大規模なWebアプリケーションをまとめたことがありません。これが私の思考プロセスです：

  • 永続層：標準データベース（現在はMySQL）
  • ビジネスロジック層：RESTのような構造（PHP、Javaサーブレットなど...）
  • プレゼンテーション層：Webブラウザー、Androidデバイス（ブラウザーではなくアプリケーション）など

このアーキテクチャを選択した理由は、デバイスが独自のカスタムUIを考案し、GET、POST、およびサーバーと対話しないものを使用して、RESTのような機能を利用できるようにするためです。

問題1：

問題は、ユーザーの情報をどのように保護するかということです。SSL接続を介してユーザーを認証し、特別なHASHを返すことで、ユーザーはアカウントを操作できますが、誰かがネットワークでリッスンしている場合は、REST呼び出しをリッスンしてHASHを盗むだけです。1つの解決策は、すべてのRESTのような呼び出しがSSLを介して行われる必要があることですが、これは別の問題を引き起こします。

問題2：

RESTプロシージャがSSLである場合、ブラウザはすべてにSSLを使用する必要がありますが、私の理解では、不要な場合は遅くて面倒です。また、SOPを使用すると、セキュリティで保護されていないブラウザからRESTプロシージャへのSSLajax呼び出しを使用できなくなります。HTTPとHTTPSは、同じオリジン、異なるプロトコルであっても、異なるオリジンと見なされます。

このソリューションは実行可能ですか？これらの2つの問題をどのように解決しますか？または、おそらく（おそらく）Webアプリケーション用に調査する必要のあるより優れたアーキテクチャがあります。すべての提案を事前に感謝します。

4

2 に答える 2

0

結局のところ、この答えに対する優れた解決策は実際にはありません。SSL ですべてを保護するか、独自の自作認証システムを考案することができます。一般的な方法は、ユーザーに一意の HASH を送信し、HASH をデータベースとクライアントのマシンの Cookie に保存することです。次に、そのユーザーの IP、User-Agent などのみがその Cookie に対して認証されます。

したがって、答えはイエスです。解決策は実行可能です。アカウントの乗っ取りを禁止するために、特別なセキュリティ対策を維持する必要があります。ログイン用のSSLはパスワードを保護します。一意のハッシュにより、ユーザーはパスワードをアカウントに漏らすことなく引き続き認証を受けることができます。IP、ブラウザ エージェントなど、ユーザーに関する大量の情報を保存することで、アカウントの簡単な乗っ取りを防ぐことができます。

于 2011-04-02T21:01:13.397 に答える
0

誰でもネットワークをリッスンしてユーザー情報を見ることができるため、情報を保護する場合は SSL を使用する必要があります。アクセスを保護する場合は、HTTP 認証RFC2617を使用します。SSL 経由では、Basic で十分に安全ですが、すべてのリクエストに SSL を使用したくない場合は、Digest が最適です。

  • アプリケーションはステートレスにすることができます。つまり、より安らかで、負荷分散が容易になります...
  • リッスンする場合、認証トークンはほとんど再利用できません (セッション ハイジャックなし)。
  • ほとんどすべての HTTP クライアント (ブラウザーまたは lib) は、基本またはダイジェスト HTTP 認証を使用できます。
于 2011-03-28T05:15:55.780 に答える