REST APIを使用した適切なセッション管理
RESTful APIの設計が完了しました。このAPIでは、パラメーターとして送信されるAPIトークンを使用して各リクエストを認証します。
クライアントインターフェイスを作成したいのですが、各ブラウザクライアントとのセッションを管理するための適切に安全な方法は何でしょうか。
サーバー側をステートレスに保つフローについて考えました：
- webクライアントはユーザーとパスワードでログインします
- ユーザーのAPIトークンを使用したサーバーの応答
- クライアントはトークンをCookieとして保存します
- aPIサーバーが期待するように、クライアントはリクエストごとにパラメータとしてトークンを送信します
しかし、ここでは何かが正しくないようです...これはあまりにも脆弱ではありませんか？
SSLを使用しているとしましょう。それでも、
APIトークンをそのように簡単に盗むことはできませんか？
それは適切な働き方でもありますか？
トークンは、追加のセキュリティを提供し、最新のWebフレームワークでCSRFから保護するのが簡単なため、WebアプリケーションのCookieにトークンを保存します。 HTML5 Web StorageはXSSに対して脆弱であり、攻撃対象領域が大きく、攻撃が成功するとすべてのアプリケーションユーザーに影響を与える可能性があります。
以下のこのリンクを参照してください。
https://stormpath.com/blog/where-to-store-your-jwts-cookies-vs-html5-web-storage
適切にRESTセッションを行うことはできません。サーバーに保存される傾向があるためです。
したがって、リクエストごとにユーザーを再識別する必要があります。
現在使用しているのはOAuthアプローチです。トークンを発行します。トークンが提供されると、身元の証明と見なされます。誰かがそのトークンを盗むことができた場合、簡単な方法はありません。 「盗む方法」については、XSS、ブラウザ拡張機能、物理的アクセスが主な要因です。XSSを軽減することはできますが、後者の2つについては実際には何もできません。
@ Saikrishna Radarap で述べたように、ベクトルとしてCSRFもありますが、トークンをCookieではない場所に保存する場合は、それほど問題にはなりません。
だから...潜在的なオプション。
最も単純なアプローチは、認証トークンの有効期限を追加するだけです。トークンの有効期限が切れたら、ユーザーに再ログインを依頼します。このように攻撃が成功すると、... emm .. window-of-opportunityが発生します。これは、破壊的な操作を実行するときに、ユーザーにパスワードの再入力を求めることでさらに制限できます。
別のオプションは、 remember-mecookiesのこのアプローチ に基づいてトークンをモデル化することですが、このアプローチには重大な欠点があります-非同期環境ではうまく機能しません。トークンごとに「ヒューズ」を適用することで軽減できます。最初の使用時に「揮発性」とマークし、X秒の「書き込み時間」を割り当てます。これらのX秒が経過すると、同じ「新しい」トークンが返され続け、元のトークンに「期限切れ」のマークが付けられます。
私が頭に入れている3番目のオプションは、HTTP Basic Auth または Digest Auth のいずれかを使用することですが、実際にそれらを試したことはありません。
だから...これらはトピックに関する私の2セントです。
RESTfull APIはインターフェースを必要とせず、ステートレスであることに注意してください。あなたの質問は2つの場合に考えられます：
1：最初のケースでは、REST_APIサーバーのみでインターフェースがなく、有効なリクエストに対するjson応答があるサーバーがあり、他のサーバー（異なるIPから）がリクエストを送信するため、クライアントを管理できません。サーバー間通信であり、すべてのサーバーにIPが1つしかないため、セッションを使用します。したがって、トークンが最適です。
2：2番目のケースでは、同じ機能を提供しましたが、同じサーバーのREST_APIの横にインターフェイスが必要です。これで、インターフェイスだけでセッションを使用でき、他のサーバー（他のサーバー）ではトークンを使用できます。
どちらの場合も、トークンを使用するのが最善の方法です。署名可能でより安全なJWTトークンを使用できます。
すべてが同じサーバー上にある場合、そのサーバーの独自のインターフェースにセッションを使用できることにも注意してください。