0

主にスマートフォンアプリケーションからアクセスされる重要でないデータ用の小さなREST Webサービスを開発しています。ユーザーの個々のデータへのアクセスを制限するには (承認にはグループやロールは必要ありません)、何らかの基本的な認証を実装する必要があります。

サービスは HTTP 経由でアクセスされるため、HTTP 認証を使用することはお勧めできません。ユーザー名とパスワードはすべての要求でクリアテキストで送信され、クライアント デバイスに保存する必要があるからです。

したがって、私の考えは、次の方法で認証を実装することでした。

  1. ユーザーは、ユーザー名/パスワードを渡す Web サービスのログイン方法を使用してログオンします
  2. このメソッドは、ユーザー名とパスワードの組み合わせの有効性をチェックします (ソルト化およびハッシュ化されたパスワードを含むデータベースに基づく)
  3. ログインが成功すると、ユーザーの ID (データベース テーブルの主キー) が属性としてセッションに保存されます。
  4. 次のリクエストでは、この属性を使用してユーザーを認証します。

コードでは、ログイン メソッドは次のようになります。

User user = this.authentificate(username, password);
HttpSession session = request.getSession(true);
if (user != null)
   session.setAttribute("UserId", user.getId());
else
   session.invalidate();

その後、セッションに基づいてユーザーを認証できます。

int userId = (int) request.getSession().getAttribute("UserId");
User currentUser = getUserById(userId);

このアプローチは「安全」と見なすことができますか (簡単なセッション ハイジャックは不可能です - 私が理解している限り、属性の値はサーバーを離れません)。
欠点や代替手段はありますか?

4

1 に答える 1

2

ユーザー ID をセッションに保存することに関しては、問題ないと思いますが、別の問題があります。

まず、ログイン方法が HTTPS 経由であると仮定します。そうしないと、ユーザー名とパスワードがクリア テキストでログイン方法に送信され、以前と同じ問題に戻ってしまいます。

次に、ログイン方法が HTTPS 経由である場合、セッション cookie は HTTPS cookie になり、他のすべての API 呼び出しも HTTPS 経由である必要があります。後続の呼び出しが HTTP 経由の場合、新しいセッション Cookie が取得され、そのセッションでユーザー ID を使用できなくなります。

HTTPS を使用しない安全な認証が本当に必要な場合は、共有秘密署名スキーム (HMAC など) または RSA などの非対称署名システムを使用して、クライアントに署名リクエストを送信し、署名されたリクエストをサーバー側で検証する必要があります。

于 2012-10-18T15:30:20.383 に答える