co3k.org

サーバ側でのセッション無効化ができない (鍵を無効化し、発行済セッション全体を無効化することはできる)

サーバ側でセッションを管理しない以上、サーバ側でどのセッションを無効化するべきか判断することができません。

個別のセッションを無効にしたい場面としては、たとえば、

• ユーザのパスワード変更時、そのユーザのアクティブなセッションをすべて無効にし、再ログインを促す
• ユーザのログイン履歴から、ユーザ自身の身に覚えのないセッションを選んで無効にする
• パスワードリスト攻撃などによってアカウントが乗っ取られたユーザのセッションを無効化する

あたりがあるでしょうか。こういった機能は少なくとも単純には実現できません。機能そのものを諦めるか、ペイロードにサーバ由来の値をなんらか含むなどの工夫が必要です。

ただし、たとえば秘密鍵が漏洩した場合や、極めて広範なアカウント乗っ取りが発生した場合、重大なセキュリティ脆弱性があった場合の対応策として、発行済セッション全体を無効化することはできます。どうやればよいかというと、秘密鍵を更新するだけです。そうすれば古い鍵を使って作られたトークンは無効となりますので、 (その鍵を使ったセッションを利用していた) 全アクティブユーザは再ログインを要求されます。

……と、さらっと書いちゃいましたが、ログイン処理は Web アプリケーションにおいて比較的コストがかかる部類の処理 (のはず。たとえばパスワード認証の場合であれば password stretching をしているはずなので) であり、それが集中しうるということは計算に入れる必要があります。まあもっとも、これは程度問題で、セッション管理機構の実装方式に依らずに覚悟しなければならないことではあります。しかし、 30% のユーザがなりすましの影響を受けたとして、影響を受けた 30% のユーザのために影響を受けなかった 70% のユーザのセッションまでリセットするか、もしくはその逆、つまり、影響を受けなかった 70% のユーザに配慮して影響を受けた 30% のユーザのセッションを危険に晒すか、という、 all or nothing の問題となってくることは認識しておいたほうがよいでしょう。

ユーザの能動的な「ログアウト」はセッションを失効させない

また、似たような理屈で、ユーザがログアウト機能を用いて能動的に「ログアウト」した場合でも、ユーザのストレージからトークンが削除されるだけで、トークンそのものが無効になるわけではありません。ログアウト前にトークンのデータを控えておけば、何事もなかったかのようにセッションを継続することができます。

セッションデータの削除処理がクライアント側で確実に実行されさえすれば、たとえば CSRF 攻撃対策としてのログアウト行為は伝統的なセッション機構と同程度に機能するかと思います。

ただし、何らかの要因でトークンを外部に晒してしまい、そのトークンによるセッションハイジャックを自主的に防ぐためのアクションとしてのログアウトは期待通りに機能しません。この場合、ユーザがログアウトをおこなってもセッションハイジャックは止められません。

そういったわけなので、サービスのログアウト機能に対して、運営者やユーザが暗にどういった効用を期待しているか、その期待を満たすことができるのかについて、サボらずによくよく吟味しなければいけません。

有効期限を明示的にペイロードに含まない限り、セッションが恒久的に有効になる

いや、さすがに含めるでしょって思いますけど、含んでいなかった例が確認されています。含めましょうね……。

Ruby on Rails の cookie store はペイロードに有効期限を含まないらしいので、アプリケーション開発者が自主的に考慮を加える必要があります。

しかし、 JWT では考慮済みで、 exp というフィールドがオプションですが存在しますので、これをちゃんと指定しておくことでこの問題は回避できます。

また、さすがというか、さすがにというか、 OpenID Connect の ID Token においては、 exp は REQUIRED です。

秘密鍵を知っていれば任意のユーザに対するセッションハイジャックが可能

これはつまり内部犯行を想定していて、それを言ったらって話なわけですけど、まあまあちょっと聞いてくださいよ。

サーバ側にセッションデータを格納し、セッション ID を払い出す方式の場合、内部犯がセッションハイジャックするためには、

• セッション DB へのアクセス権を得る。もっとも Web サーバを経由するでしょうし、これはクリアするんじゃないでしょうか
• セッション DB からセッション ID を盗む
• 盗んだセッション ID を使ってセッションハイジャックする

というステップを経るわけですけど、全セッション ID を一覧するような行動はさすがに発覚の危険がありますから、バレないように数件ずつとか、あるいは 1 ユーザずつとかやっていくことになるわけです。ただ、そのいずれもクライアントから送られてくるセッション ID を検索する操作とは異なる (ログインセッションの一覧機能を提供している場合はこの限りではありません) ので、ひょっとしたら事後になるかもしれませんが攻撃の痕跡を見つけることはできそうではあります。

一方で、今回問題にしている例の場合、内部犯は、

• Web サーバで動くアプリケーションのメモリ上に載っている秘密鍵を盗む
• 任意のあらゆるユーザのセッションデータを作って署名し、セッションハイジャックする

というステップを経ることになります。サーバ側から見たときに通常と異なるイベントは最初のステップだけです。これどうやって防ぎます？　もしくはどう検知します？

というかまさか秘密鍵をソースコードに埋め込んでいたりしないですよね？　当たり前ですが、それはもう秘密鍵を盗む必要すらなくなります。今まさに内部犯行がおこなわれていてもまったく不思議ではありません。いますぐ鍵を更新し、鍵管理方法を見直しましょう。

いわゆる退職者バックドアになる

そういうわけですから鍵管理が重要となります。

運営者や開発者の人員構成に変更があった場合 (有り体に言うと異動や退職があった場合) に秘密鍵を更新しないと、いわゆる退職者バックドアとなります。

まあこれも組織内で何かしらの共有パスワードを使っている場合の管理と同じっちゃ同じ [2] ですが、この秘密鍵がそういう種類のものだということを理解しておく必要があります。この認識が抜けている例も確認しています。

また、運営会社と開発会社が異なる場合など、開発用に一時的に解放していたサービスのアカウント情報などを、運営に移行する際にひととおり更改する、というのは当然の発想ですし、おそらくフローに組み込まれているはずですが、 JWT の秘密鍵についても同様に変更しなければならないものとして扱う必要があります。

というより、秘密鍵を渡していますか？（受け取っていますか？）　というよりというより、 JWT をセッション管理に使っていることを知らせていますか？（知らされていますか？）

そもそも秘密鍵は定期的に更新しなければならない

最初に、僕は暗号技術には明るくないので、この項目についてズレたことを言ってしまっているかもしれません。ただし要点は外していないはず。ここに限らずですがあらゆるフィードバックを歓迎します。

トークンに対するオフライン攻撃が可能なので、共通鍵暗号や HMAC の場合ならば鍵の総当たり、公開鍵暗号 (非対称鍵暗号) の場合、たとえば RSA 暗号であれば公開鍵に対する素因数分解を想定しないわけにはいきません。つまり、みなさんが PKI の上で TLS 通信をやっているときと同じように、秘密鍵に有効期限を与える必要があるってことです。なにせ単体でセッションハイジャック可能な鍵なわけですから、それくらいはやって当然ですね。

そうなるともちろん、定期的な鍵の更新を考慮しておく必要があります。一年に一回、元旦に全ユーザが一斉ログアウト＆一斉ログイン、みたいなことをやるのはちょっとおもしろすぎる (「あけおめメール」ならぬ「あけおめログイン」ですね) ので、新旧鍵の併用期間が必要になってきます。そういう運用は想定していますか？

ちなみにあんまりこのエントリで OpenID Connect を激推しするつもりはない [3] のですが、 OpenID Connect にはこのための仕組みがあります。 JWK (JSON Web Key) っていう標準がある (RFC 7517) んですけど、有効な公開鍵の一覧を用意しておいて、更に鍵を一意に特定するための ID を与えておくというものです (JWK Set)。それでもって ID Token (JWT) のヘッダ部にて、用いた鍵の ID を kid フィールドに格納しておくと、

0. JWT 検証時には kid の指す鍵を用いるようにしておく
1. 古い鍵を廃止する前に、新しい鍵を生成して JWK Set に追加する
2. 新規に発行する JWT については、新しい鍵を用いるようにする (新しい鍵の ID を kid に含む)
3. 古い鍵を使った JWT の有効期限が訪れるのを待つ (もちろん待たなくてもよい)
4. 古い鍵を JWK Set から削除する

これで一斉ログアウトなしに鍵が更新できるというわけです。まあもちろん JWK を使わないといけないわけではありませんが、鍵のローテーションをするのであれば、似たような仕組みは備えておく必要があります。

alg の柔軟性 (alg=none 許容で即死など)

ああ、そういえばそんな問題あったなーという感じなんですが、 JWT は、

• トークン側に、そのトークンで利用している暗号アルゴリズムが含まれる
• どの暗号アルゴリズムを許容するかは、そのトークンを検証する側 (今回の例であればサーバ側) に完全に委ねられている

という性質を持ちます。このことから、以下のような問題が知られています。基本的にはほとんどのライブラリで対策済みのはずですが、本当に対策済みかどうかは確認しておいたほうがいいでしょう (本当に即死するんで！)。

• alg に none を許容している場合は、署名部分を空にしたトークン (つまり {"alg":"none","typ":"JWT"}.{"user_id": "1"}.) が有効となるので、秘密鍵を知らなくても任意のセッションをハイジャックできます
• サーバ側が公開鍵暗号 (非対称鍵暗号) を期待しているにも関わらず alg に HS256 を、つまり HMAC-SHA256 などを許容している場合で、そのトークンを検証するのに使われる RSA 公開鍵を HMAC における秘密鍵として扱ってしまう実装が存在しました。つまり秘密鍵を公開している状態になるので、これもセッションハイジャックし放題です

まあこういう性質を持つってことは、 TLS におけるダウングレード攻撃と同等のことができるってことです。許容する暗号アルゴリズムは必要最低限のものに絞りましょう。というかクライアント側でトークンの検証をしないのであれば、サーバ側で利用可能な最強のアルゴリズムだけを許容しておきましょう。

これが JOSE の Security Consideration に書かれていないのがちょっとよくない、というか draft 段階の実装時点で既に問題になったトピックなんで、なんというかどうにかしてフィードバックすればよかったごめんなさい。

JWE で利用可能な暗号アルゴリズムが微妙 (らしい)

先述の通り、僕は暗号技術に明るくありません。したがってこのトピックは完全に僕の手に余るものなのですが、 No Way, JOSE! Javascript Object Signing and Encryption is a Bad Standard That Everyone Should Avoid - Paragon Initiative Enterprises Blog では、 JWE で利用可能な鍵暗号アルゴリズムについて、

• RSA with PKCS #1v1.5 Padding はパディングオラクル攻撃に対して脆弱である

• RSA with OAEP Padding は RSA を信頼するなら安全であるが、 RSA は長期的には信頼しにくい

  • 僕でも知っていることだと、「ハードウェアの性能向上による鍵解読リスクへの対策として鍵長を増やしているわけだが、そのうち限界来ません？」とか「乱数生成に問題があって、異なる鍵同士が同じ素数を選択してしまった場合に脆弱だよね」とかですが、他にもあるのかもしれません (これすら間違っていたらごめんなさい。暗号は本当に素人なんです)

• 楕円曲線暗号は invalid-curve attacks に脆弱な ECDH しか利用できない

• AES-GCM については……ごめんなさい、文意が取れなかったので原文をそのまま引きます

  > Because no list of questionable public-key encryption modes could be complete without shoehorning a shared-key encryption mode, the JOSE standards also allow you to use AES-GCM to possibly exchange an AES-GCM key.

としています。

事実とはいえ自分で何度も書くのが辛くなってきたのですが、僕は暗号技術に明るくなく、暗号アルゴリズムの選定の際には CRYPTREC暗号リスト (※リンク先 PDF) に頼りっきりという有様なので、リストに掲載されている RSA-OAEP を普通に採用することになるだろうなと思います。

もちろんどのような暗号アルゴリズムを採用するとしても、暗号アルゴリズム自体の危殆化には備えておかなければならないわけで、まあそこさえ抑えておけば大丈夫じゃないかな……たぶん……。

cookie の HttpOnly フラグの保護を受けない (thanks to @s_tajima_tech)

で、これは僕は思いついていなかったんですが、 @s_tajima_tech が教えてくれました。多謝。

まあ平成最後の秋に生きるみなさんであればもうご存知のとおり、この HttpOnly フラグは XSS の脅威を軽減するっていうものなんですが、 XSS の脅威って別にセッションハイジャックだけではないので、 Web アプリケーションにおいてはそもそも XSS が生じにくい設計にして、 XSS を根絶した状態を前提とするべき――なんですけれども、 Virtual DOM を使おうがなんちゃら DOM を使おうがビューフレームワークを使おうが、 DOM Based XSS を作り込むときはやっぱり作り込む (リンク生成部分とかバインディング記法の動的生成部分とかね) ので、運用の観点から言うとやっぱり気になるところかもしれない。しかしそうは言っても XSS は根絶しましょう！

cookie の secure フラグの保護を受けない

あと cookie が守ってくれるものって何かないかなーと考えていたら secure フラグがありました。

とはいえ、 HTTP 通信時と HTTPS 通信時でセッションを分ける必要があるのは cookie も Web Storage も変わらないし、なんなら Web Storage の場合は same-origin policy の保護を受けるので、 security フラグがなくとも自然に分離した形で保存されます。

しかし、攻撃者の罠サイト、あるいは攻撃対象サービスの HTTP なリソースを (通信路上で改竄したうえで) 経由して JWT を返す認証 API (HTTPS) の実行を強制させることができ (※)、かつ認証 API (HTTPS) のレスポンスの CORS 設定が雑 (※) な場合、 HTTP なリソースからセッション用の JWT を盗むことができる――つまり HTTPS の保護を迂回してセッションを盗み、セッションハイジャックすることが可能です。

cookie の場合は、たとえどんなに Access-Control-Expose-Headers の設定が緩かったとしても XMLHttpRequest や Fetch API から Set-Cookie や Set-Cookie2 ヘッダの内容を読み取ることはできません。攻撃者が通信の内容を得ることができない以上、 secure フラグ付きの cookie の内容を得ることはできません。

……と、一応書いてはみたものの、※印で示したような前提は突破する必要があります。なにか見落としている可能性をあまり否定はしませんが、これはちょっと無理のあるシナリオかな、と思います。