※読みにくいので随時更新予定
サーバサイドとフロントエンドを別ドメインで稼働させる今時な構成の場合、以下にしてセキュリティを確保するかは様々な情報が飛び交っています。中には明らかにアウトな方法を紹介していることも。
なので、一旦自分の認識整理も兼ねて再度調査することに。セキュリティガチ勢寄りではなく実務目線と言いますか、ある程度担保したら見切り発車で開発始めながらキャッチアップは続けていくというスタンスです。
ちなみに想定している構成はLaravel(Sanctum[SPA認証])+React(別ドメイン)です。
Cookieかつサーバ側で管理を行うステートフルな仕組みで考察していきます。JWT(ステートレス)ではありません。解説はしていますが。
※一個人の意見として参考するに留め、必ず自分自身で納得いくまで調べてください。最適解を保証するものではありません。
ステートレスとステートフルの違い
まずはここをはっきりさせることで、必要な対策もうっすら見えてくるかと。
JWT(ステートレス)の場合はクライアントから送信されるトークンを解析し、それが改竄されていない正しいものであれば処理を通すというものです。
なので、サーバ側ではリクエストの都度トークンを解析して正しく発行されたトークンなのかを判断します。トークンがユーザIDのような識別する値を直接持ち、これをベースに認証や認可を行うよう。
サーバ側ではセッション情報を管理していないのでもしトークンが流出するとサーバ側は基本なす術がありません。
一方ステートフルの場合、サーバ側にてログインからずっとセッション情報を持ち続けるので対象のユーザのみログアウトさせるというような処理が可能です。
この辺りは開発以外のレイヤーも含めてどちらを採用するか考えるべきです。
CORSについて
CORSはサーバサイドにて設定します。他ドメインからのリクエストを許可することが可能です。なので今回の場合、SPAのドメインからのリクエストに関しては許可する必要があります。大事なことは、CORSによって不正なドメインからのリクエストは結果をブラウザが破棄するというだけで、サーバサイドにてブロックされるわけではありません。なので攻撃者が正規のリクエストを装った場合、CORS以外での対策を行なっていなければ処理自体は実行されてしまうのです。
CSRFトークンについて
CSRFとはとあるユーザがすでにログイン中のサイトに対して、別ドメインの悪質なサイトがリクエストを送信するという攻撃です。CORSとは別にこの対策を行なっていないと成りすまして書き込みされたりします。そこでサーバ側が発行し、クライアントがリクエスト時に付加するものがCSRFトークンです。
JWTの場合、CSRFトークンも必要なくなります。CSRF対策は「リクエストがサーバ側の意図したものかどうか」を正しく判定しなければなりません。
JWTを使う場合は、リクエストヘッダにAuthorizationとして記述するのですが、このヘッダの値はサーバ側が許可したドメインからのリクエストでない限りはプリフライトリクエストによって切り捨てられます。そのためドメインの保証はされている状態なのです。
一方ステートフルの場合はCookieのみで認証管理を行うため、別の対策が必要です。そのため、ログイン時からCSRFトークンを発行し、ヘッダに乗せてやりとりするという方法が一般的となっております。
面倒だなと思いましたよね？LaravelとReact(Axios)で通信する際、サーバ側のCookie送信が許可されていればCSRFトークンの実装は意識しなくて良くなるそうなのですが、また別の記事にて。
SameSite=noneにてCookie送信先をホワイトリストで管理する
今回考察している構成では、全くの別ドメインからのリクエストを受け取る必要性が出てきます。JWTの場合はAccess-Control-Allow-Originにて対象ドメインを設定すると、ホワイトリストで連携したいドメインを管理することが可能です。それに加えてステートフル、Cookieベースで認証管理を行う場合はSameSite=noneを設定することで、Cookieを共有します。ただ一点気をつけるべきは、ここでAccess-Control-Allow-Originはブラウザ側の機能であって、リクエストはサーバ側に通ってしまうということ。プラスしてブラウザ以外からのリクエストにおいてはセキュリティ面としての効力を発揮しないということ。ブラウザが不正なリクエストとして結果を破棄しているだけなのです。
トークンやCookieの盗難
前提としてHTTPSかつHttpOnlyであるとします。JWTをローカルストレージに保存するな論は昔から存在しますが、私個人の意見としては最も大きな懸念点はJSからアクセスできてしまう部分だと思います。攻撃者がXSSによってトークンにアクセスできてしまうのは怖いかなと。jsのライブラリが信用できるとも限りませんし。
一方、Cookieの情報はサーバサイドにてCORS設定を正しく行なえば、たとえSameSite=noneでも抜き取られることはありません。
補足
以下は捕捉的な情報です。もっといろいろ考えてみたい方は目を通してみると良いかと思います。
ネイティブアプリからのリクエストはどうなる？
上記の仕組みはあくまでブラウザが持っているもので、ネイティブアプリの場合はまた必要な対応が変わってきますし、正直お手上げな場面も存在します。まず事実として、どのような設定を行なっていたとしてもCookieやローカルストレージ上のデータが盗まれる可能性はあります。
たとえば攻撃者アプリがwebViewを実装し、そこから利用者にwebサービスへログインさせたとします。この場合、たとえHttpOnlyを設定していてもネイティブアプリの機能でCookieを取得することは可能なのです。これはローカルストレージ上のトークンも同じ。
ブラウザとはそもそもの仕組みや従うべき業界仕様が違うからこうなってしまうのです。
これに対策を講じるならば、ログイン時の２要素認証等が必要になってきます。
怪しいアプリをインストールするなというのはこういうところもあるんですね。
不特定多数のドメインからのリクエストを受けたい場合は？
こうなってくると別次元レベルでの実装が必要だと思ってください。Google等の有名なサービスを参考にすれば自ずと必要な対策が見えてくるのではと思います。
