Cordovaを使用してSPAとモバイルアプリケーションのREST APIを保護する方法

Question

これを取り巻く「ベストプラクティス」について多くの研究を行い、ブログ投稿、SO質問後のSOの質問、OWASPの後のOWASP記事記事。私はいくつかの明確な答えにいくつかの不明点がありました。

まず、 "DOさん"：

1. 使用JWTのHttpOnly /で私のREST API [1][2]
2. 店JWTにセキュアなクッキーをユーザーに許可すると、CSRF保護で構築します。 HTML5のローカルストレージに[3][4][5]を保管しないでください（実際には、この点は議論の余地がある、それが簡単にXSSやCSRFから保護するためにある？[6]）
3. JWT [7]の署名方法

を確認して今私が始めましたSPA（Angularで構築されている）を使用し、HTML5のsessionStorageを使用することは、短命のトークンに対しては十分に安全であると仮定していますが、XSS攻撃は次のいずれかの原因で発生する「悪い俳優」から発生する可能性があります。 CDNからロードされた多くのライブラリ。

長持ちしたトークンを使用する予定はありません。使用していない10分後に有効期限が切れますが、セッションごとに有効期限を追跡するか、リフレッシュトークンを使用するかどうかを判断しています。 - StormPath JWTを使用しているビッグプレイヤーはリフレッシュトークンを使用していると信じています（Googleはそれらを使用しますが、HTML5 localStorageが安全で長期的なストレージに保存する必要があると言います）。

私は、ユーザーがページをリフレッシュするとログインする必要がないようにしたいので、クライアント側にトークンを保存する必要があります。また、SPAをCordovaの助けを借りて「モバイルアプリ」として使用したいと考えています。クッキーを使用すると、Cordovaでクッキーをサポート/保管する必要がなくなるため、代わりにHTML5ローカルストレージに切り替える必要があることが明らかです。モバイルではページをリフレッシュすることについて本当に心配する必要はないので、私は自分のトークンを記憶させて、私が決める戦略で期限切れにすることができます。

モバイルでの「ベアラ」ヘッダーで、デスクトップ上のCookieベースのJWTを使用する場合、トークンに2つの異なる方法を与える認証エンドポイントが必要です.REST API側で認証すると、私は、クッキーベースのJWT（CSRF付き）とヘッダーベースのJWT検証の両方をサポートする必要があります。この合併症は、私がここでのセキュリティへの影響を正確に予測できるかどうかわからないので、私は心配しています。上記の思考の集中砲火を要約する

：

• は、デスクトップ、およびモバイルのためのペイロードがHTTPのみ/セキュアクッキーを介したトークンを配るだろう認証ハンドラを作成します。
• 私のREST APIでは、ヘッダーベースとCookieベースの両方の検証方法をサポートしています。これには、CookieベースのアプローチのCSRF保護が含まれます。

私はこのアプローチを取ることを望んでいないだろう、なぜ何らかの理由はありますか？私はSPAで重大なリスクとしてXSSを取ると仮定します。その場合、SPAを介して認証を行うと、XSS攻撃が同様に傍受される可能性があるため、認証用の古典的なログインページが必要ですモバイルとデスクトップの両方で）！しかし、モバイルでは、JWTをSPAに注入する必要があります。おそらくカスタムDOM要素（メタタグ？）、その時点でSPAにログインを実行させ、モバイルデバイス上でXSSを脅威とみなさないようにすることができます。 Cordovaはすべてのアセットをインストールパッケージにパッケージ化していますが、これはやや良いですが、デスクトップバージョンで同じアプローチをとってみませんか？

私のアプリケーションは非常に少ないユーザー入力を受け取り、それは主に、ダッシュボード/レポートツールです。 「メッセージセンター」がありますが、コンテンツは常にユーザー作成（そのユーザーのみ）であり、サニタイズする必要があります。 私のユースケースでは、「ベストプラクティス」から逸脱し、XSSをSPAの重大なリスクとして数えないlocalStorageに頼ってもかまいませんか？これは、この全体を単純化し（元々計画されているようにHTML5のsessionStorageを使用する）、複雑さを軽減し、潜在的なセキュリティ脆弱性を軽減します。私は、前進する前にリスクを理解しておきたい。

モバイル用のネイティブアプリを構築し、Cordovaを使用してSPAをモバイルアプリに変換する以外に、このセキュリティを保護するための安全な方法はありませんか？私はこれが事実であることを嫌っていますが、それは非常にうまくいくかもしれません。

私は、問題のすべての考えをいただければと思います！

Answer 1

モバイルデバイスを実行するにはJavaScriptベースのクロスプラットフォームのアプリケーションを設計することを考えて、通常のWebブラウザベースのアプリケーションを設計するとの警告の多くは必ずしも適用されません。

限り、セキュリティに関しては、あなたがJWTや簡単なOAuthのトーク​​ンを使用することを決定したかどうか、すべての通信はHTTPS経由であることを確認してください。

必要に応じてlocalStorageを使用してください。 httpリクエストの構造を考えると、実際にはすべて、テキストベースのメッセージを複数のセクションに分割してサーバーに送信しています。リクエストのヘッダーは、Cookieを含む他の部分よりも安全ではありません。したがって、セキュリティの観点からの注目点は、トークンの生成/検証/無効化、デバイスへのトークンの格納、要求の転送メカニズムです。

1. 生成/検証/無効：サーバー上にトークンを生成します。いくつかの技術/戦略を使用して、衝突や出血の可能性がないことを確認してください。また、サーバー上のトークンを無効にして、トークンをさらに使用する際にサーバーから要求されたデータへのアクセスを拒否できるようにしてください。それは、サーバーがリソースへのアクセスを拒否したときに、ユーザーUIの操作を処理することは、アプリケーションの中であなた次第です。あなたは、デバイス上のトークンを保存する方法

2. は、デバイスのOSのmakeはあなたに利用できるようにするものに制約されています。ネイティブアプリの使用がクロスプラットフォームよりも優れているかどうかについては、ローカルストレージなどの「すぐに使える」ものに満足できない場合は、特定のネイティブ戦略を使用してトークンを保存するネイティブコードローダープラグインを作成すると思います可能であれば、私の経験ではこれは通常過度のものです。誰かが別の経験を持っているならば、この1つで訂正するのが楽しいです。

3. ALL Webサービスのエンドポイント通信のために例外なく常にHTTPSを使用してください。 HTTPSは絶対不可能ですが、専用の強盗がロックを取ることを学ぶことができたため、フロントドアなしで家を建てることはありません。これは輸送機構をかなり確保する。

通常、これはネイティブアプリもあまりにも処理しなければならないものです。