安全なログイントークン管理、フロントエンドの必須戦略

以下は、Single Page Application（SPA）でよく見られるログインと認証が必要な API リクエストのコードです。

async function login(id, pw) {
const res = await fetch('<cross_origin_api_url>/api/auth', {
method: 'POST',
body: encrypt({id, pw}),
mode: 'cors'
});
const token = await res.json();
localStorage.setItem('accessToken', token.accessToken);
}

async function getProtectedResource(id) {
const accessToken = localStorage.getItem('accessToken');
const res = fetch(`<cross_origin_api_url>/api/protected-resource/${id}`, {
headers: {
Authorization: `Bearer ${accessToken}`
},
mode: 'cors'
});
}

このコードには以下のような履歴があります：

1. バックエンドとのAPI規約：

• Authorizationヘッダーにトークンを含める。
• Access-Control-Allow-Originヘッダーは開発の便宜上、* に設定されている。

2. トークンの永続性の実装：

• localStorageAPIを使用してトークンを保存。

上記のコードと履歴を見た場合、露呈する脅威は以下の通りです。

Authorization Header → XSS攻撃

Authorizationヘッダーを通じてAccess Tokenを渡す方式はXSS攻撃に脆弱です。Authorizationヘッダーを通じてトークンを渡すためには、トークンはJavaScriptのメモリやストレージ領域に保存される必要があります。もし攻撃者がXSS攻撃に成功すれば、ページ内のJavaScriptコードにアクセスでき、その結果、トークンやそれを取得できる関数がグローバルスコープに露出していれば、トークンを盗むことができます。

LocalStorage → XSS攻撃

上記のコードでは、localStorage APIを使用して永続性を実現しています。localStorageはブラウザ全体からアクセス可能で、キーさえ分かれば攻撃者がトークンを奪取することができます。したがって、XSS攻撃が成功すれば、localStorageに保存されたトークンは非常に簡単に盗まれることになります。

Access-Control-Allow-Origin: * → セッションハイジャック、CSRF

ブラウザはCross-Originリクエストに対して、Cross-Origin Resource Sharing(CORS)ポリシーを使用して、機密情報を軽々しく送信しないように保護します。しかし、Access-Control-Allow-Originヘッダーを*に設定すると、すべての外部ドメインからのリクエストを受け入れてしまいます。これにより、セッションハイジャックやCSRF攻撃のリスクが増大します。CORS設定自体が直接的にCSRFの脆弱性に結びつくわけではありませんが、攻撃者が脆弱性を悪用した場合、被害がさらに大きくなる可能性があります。

認証方式の改善方法

フロントエンドでトークンを安全に管理するためには、逆説的に、コードレベルでトークンを管理するのではなく、セキュリティ設定が施されたクッキーを使用して受動的に管理する方が効果的です。これを実現するために、以下の対策を推奨します。

HTTPSベースの通信

今では当然のことかもしれませんが、HTTPSを使用しないと、どんなにコードレベルでセキュリティを強化しても、攻撃者による Man in the Middle(MitM)攻撃に脆弱になります。HTTPSは基本中の基本であり、必ず使用する必要があります。

永続性はWeb Storage → Cookieに変更

Web Storage APIはXSS脆弱性を抱えていますが、機密データ（トークンなど）はCookieを使用してブラウザに保存する方が安全です。Cookie自体にもXSSおよびCSRF脆弱性がありますが、追加の設定を施すことで、これらのリスクを最小限に抑えることができます。

• HTTP Only: JavaScriptからcookieへのアクセスを禁止することで、XSS攻撃によるcookieの盗難を防ぎます。このクッキーは基本的にサーバーが生成します。
• SameSite=Strict: 同一サイトからのリクエストでない限り、cookieをヘッダーに含めません。これによりCSRF攻撃を大幅に軽減できます。もし、特別な理由で同一サイトのAPIリクエストが難しい場合は、少なくともSameSite=Laxに設定します。
• Secure: ブラウザとサーバーが共にHTTPSの環境でのみcookieを送信するように設定します。これによりMitM攻撃を防ぐことができます。

適切なCORSポリシー設定

もしサーバーとオリジンが異なるWebアプリケーションの場合、Access-Control-Allow-Originヘッダーを許可された一部のドメインにのみ動的に割り当てるように設定することがセキュリティに役立ちます。

例えば、people.abc.comからdefg.com/apiにCORSリクエストを送信する場合、defg.com/apiの開発者は、people.abc.comからのリクエストに対してのみ値を残すように設定します。

Access-Control-Allow-Origin: people.abc.com

cookieベースでCORSリクエストを通じて認証を行う場合、サーバーは追加のヘッダー設定を行う必要があります。これにより、cookie に保存されたアクセス・トークンをサーバーに送信できます。

Access-Control-Allow-Credentials: true

改善結果

上記のソリューションに基づいて、元のコードはどのように改善されるのでしょうか？

async function login(id, pw) {
await fetch('https://<cross_origin_api_url>/api/auth', {
    method: 'POST',
    body: encrypt({id, pw}),
    mode: 'cors'
});
}

async function getProtectedResource(id) {
const res = fetch(`https://<cross_origin_api_url>/api/protected-resource/${id}`, {
mode: 'cors',
credentials: 'include'
});
}

フロントエンドコードは驚くほどシンプルになりました。フロントエンドで行うべきロジックはほとんどなく、設定だけで完了します。しかし、実際には背後で多くのことが行われていることがわかります。これを分解して、どのように認証が行われるかを理解しましょう。

What Happens Behind the Scene 1: When login Is Called

この図は、例示されたコードでlogin関数が呼ばれたとき、ブラウザとサーバー間で行われる通信の流れを示しています。

1. ブラウザはリクエストを送信する前に、クロスサイトへのリクエストかどうかを検証します。
2. クロスサイトであれば、プレフライトリクエストをサーバーに送信します（OPTIONSメソッドが使用されます）。
3. サーバーはOPTIONSメソッドリクエストに対して、許可されたドメインかどうかを判断し、クロスサイトリクエストを許可するヘッダー（Access-Control-Allow-Origin、Access-Control-Allow-Credentials）を送信します。
4. ブラウザはプレフライトレスポンスを確認し、サーバーが適切なヘッダーを送信した場合、元のリクエストを再度送信します。
5. サーバーはリクエストの認証を確認し、cookieにhttpOnly、Secure、SameSite=Laxを設定します。
6. ブラウザはそのcookieをブラウザに保存します。

What Happens Behind the Scene 2: When getProtectedResource is Called

1. ブラウザ - 対象リソースサーバーにCORSプレフライトリクエストを送信します。これはサーバーがCORSヘッダーをどう設定しているかを検証する手順です。
2. サーバー - 対象リソースへのCORSプレフライトリクエストが来ると、Access-Control-Allow-Origin ヘッダーを適切に返すかどうかを決定します。
3. ブラウザ - サーバーがCORSヘッダーを正しく設定していれば、実際のリクエストを送信します。credentialsフィールドがincludeに設定されている場合、Access-Control-Allow-Credentials: trueかを確認し、cookieをリクエストヘッダーに含めて送信します。
4. サーバー - リクエストに含まれたcookieからtokenを取り出し、内部で認証を行います。ログインしていない場合やフロントエンドでセキュリティ設定が適切に行われていない場合、cookieは存在しないため、リソースへのアクセスをブロックできます。

結果として、XSSやCSRFをかなり防御できる形となり、セキュリティレベルも向上しました。

さらに改善する

私たちのフロントエンドチームも、従来のWeb Storageベースのトークン管理方式からCookie方式に移行することで、セキュリティレベルを大幅に改善し、認証ロジックも簡素化することができました。ただし、セキュリティの分野では常に完璧な方法は存在しないため、結果的にトークンが盗まれても被害を最小限に抑えるための対策を設定する必要があります。

トークンローテーション

トークンの有効期限を短くし、頻繁にトークンを更新することです。これをトークンローテーションと呼びます。

有効期限が長いアクセストークンは、一度盗まれると攻撃者がシステムに与える影響が大きくなります。したがって、トークンが盗まれた場合でも、すぐにそのトークンの権限が無効になるように、アクセストークンに短い寿命を与える必要があります。

リフレッシュトークン

トークンの有効期限が短いと、一般的なユーザーは頻繁にログインする必要があり、不便を感じることがあります。これを防ぐために、実際の認証と認可に使用されるアクセストークンの時間は短く設定し、その一方でアクセストークンの再発行のためにリフレッシュトークンを利用します。ユーザーは、リフレッシュトークンが有効な限り、再度ログインせずにトークンローテーションを実現することができます。

安全なWebサービスのためのフロントエンドトークン認証実装戦略

最終的に、Webセキュリティの基本原則を遵守しながら、安全なフロントエンドトークン認証方式を実装することは非常に重要です。複雑さを減らし、重要なセキュリティ処理をサーバー側で実行することは、攻撃者の攻撃対象面を減らすのに効果的です。フロントエンドでのトークン管理は、Cookieベースの受動的なセキュリティアプローチによって強化でき、ブラウザのセキュリティポリシーを活用して認証プロセスを安全に処理できます。

また、トークンの盗難に備えて、トークンの寿命を短く設定し、定期的に更新するトークンローテーション戦略を導入することで、セキュリティを高めると同時にユーザー体験も改善することができます。このようなアプローチを通じて、QueryPieが提案する安全なフロントエンドトークン認証を実現し、より安全なWebサービスを提供できるようになります。

参考文献

• https://developer.mozilla.org/en-US/docs/Web/HTTP/Cookies
• https://www.okta.com/identity-101/what-is-token-based-authentication/
• https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch