2016-09-30 1 views
0

私の場合は、ウェブアプリとモバイルアプリのセキュリティを適切に実装する方法を理解してください。同じサービスのウェブアプリとモバイルアプリの認証(一般的なセキュリティ)

  1. バックエンド:私が持っているもの

    。 JSONテキストを消費して生成するStateless REST APIのようなものです。どんな種類の状態も格納しません。

  2. Webアプリケーション。サービス機能への主要なポータル。
  3. モバイルアプリケーション。

バックエンドには状態を保存しません。代わりに、私はモバイルとWebブラウザの両方のアプリケーションにこれを委譲します。 ここにセキュリティの問題があります。どうすればそれを適切に保護できますか?

セッションのメカニズムが本当にうまくいかないので、私はJWTに行くことにしました。 私のJWTでは、ユーザーIDと、ユーザーの特権などのその他の情報を保存するつもりです。

モバイルアプリの場合、このトークンをレスポンスの一部として送信し、アプリはそのセキュアストア内にアプリを保存します。 各要求は、このトークンをAuthorization Headerとして送信します。ウェブアプリについては

、私はHttpOnlyのクッキーを経由して、このトークンを送信するつもりです。したがって、このトークンは、クライアントからのすべての要求に含まれます。 問題は、CSRF攻撃の可能性があります。それに対処するために私は次のことを考えました。各ユーザーの「セッション」はCSRFトークンに関連付けられます。 私はこのトークンをサーバーに保存できません(ステートレスAPIを覚えておいてください)、HttpOnly Cookieを介して暗号化された(再びJWTで)トークンをクライアントに送信し、通常のCookieでは非暗号化します。

これで、Webクライアントはすべてのクッキーから非暗号化トークンを使用して、それをサーバーに戻します。サーバーは、このトークンがHttpOnly Cookieに格納されている暗号化されたものと一致するかどうかをチェックします。

また、私は、WebアプリケーションとモバイルWebアプリケーションに異なるURLエンドポイントを使用します。何のために?上記の認証メカニズムを別々に保つために、これはサービスを安全に保つのに役立ちます。

あなたはそれが解決策だと思いますか?ここに何の問題がありますか?

ありがとうございます。

答えて

0

一般的に、あなたが説明したものは、よく見え、かなり標準的です。しかし、私が正しく理解すれば、CSRFの保護には欠陥があります。

私が正しく理解していることを確認するには、csrfトークンが暗号化されたhttpOnlyクッキーに格納され、参照としてサーバーに送り返されます。別のクッキーは同じ値で暗号化されず、プレーンな(非httpのみ)クッキーであり、サーバーはこれらの2つを比較します。ポイントは何ですか?攻撃者はWebページを作成してユーザーがあなたのWebサイトにリクエストを行い、両方のCookieがまだ送信されるようにすることができます。

参照Cookieは参照用にhttpOnly Cookieに入っていますが、もう1つはCookieであってはいけません。たとえば、すべての要求に追加する要求ヘッダー値などです。クライアントはレスポンスでそれを受け取ることができましたが、クッキーとして受け取ることはできませんでした。 WebアプリケーションのjQueryを使用すると、beforeSendフックを使用して、後続のすべてのリクエストにヘッダーとして追加できます。このようにして、攻撃者は別のドメインから有効な要求を行うことができませんでした。

+0

ありがとう、それは私が意味したものです。暗号化されておらず、HttpOnlyではない他のクッキーは、クライアントが値を取得してフォームパラメータとして送信するために必要です(例えば、提案した別のヘッダ)。 次に、サーバーは暗号化されたCookieと受信したフォームパラメータまたはカスタムヘッダーの値を比較します。 – yateam

+0

それは良い音だ。 :) –

関連する問題