true}.これをElixir/ErlangのJWTライブラリであるJOSEで署名検証してみます。%{}}}ErlangのJWTライブラリの実装は前者の"Headerで指定されているアルゴリズムと鍵で"署名検証を行うものになっています。指定されているとそちらを見て署名検証がOKとなってしまうわけです。(4)verify_strict/3では引数に"許容するalg"のリストを受け取り、それに含まれていたらそのアルゴリズムで検証しましょうという実装になっているため、noneの値を明示的に指定すると署名検証がOKとなります。いう関数で指定できるようになっています。verify_strict/3それぞれでalg=noneによる署名検証が通らなくなります。JWTの署名検証処理なんてのはライブラリに任せておくのが鉄則と言っても良い状況だと思っていますが、今一度自分の使っているライブラリがしっかりとこの辺りに対応できているかを見直してみるのも良いでしょう。ライブラリレベルでalg=noneで署名検証をスキップできる可能性がある場合、その署名検証関数を呼び出すロジックを工夫したり安全に利用できるようにラップしたライブラリを書くなどする必要があるでしょう。鍵と許容するアルゴリズムを1:1(もしくは1:n)で管理さらにそれをkidで識別可能にする複数の鍵を署名検証の関数で指定できるみたいな実装が良いのではないかなと思っており、実際にそういう挙動になるようなラッパーライブラリを実装して利用しています。kitten_blueこの辺りの考えについてはこれまでブログ記事を書いているので参考にどうぞ。r-weblifeではまた!ritou今までバッジを頂いた皆様、ありがとうございます。猫のご飯代にします(ΦωΦ)バッジを贈って著者を応援しようバッジを受け取った著者にはZennから現金やAmazonギフトカードが還元されます。署名を検証こういう実装ってありえるんですかね・・。jwksエンドポイントは普通にあります。kty=RSAなやつまで。この方向性での解決策なら、"JWTのヘッダに指定されたalgが属するktyと、鍵に紐づけられたktyが一致することを確認した上で"じゃないですかね。ktyはRFC的にもMUSTですし、これならalg=noneも、HS<=>RSも回避できます。ライブラリは問題が出ないでしょう。(是非は別にして)これが一般的かなとは思いますね。ここに異論はないです。2021/09/08"JWTのヘッダに指定されたalgが属するktyと、鍵に紐づけられたktyが一致することを確認した上で"ご指摘のとおり、RFCの整合性を取った上でのライブラリ実装としてはこのあたりが落とし所になりそうですね。algのリストを指定して絞るのはたしか2013年ぐらいにこの攻撃というか問題が出たときに各言語のライブラリで一斉に対応された対策だったと記憶しています。1返信ritou今までバッジを頂いた皆様、ありがとうございます。Proよくある質問LinksX(Twitter)GitHubメディアキットLegal利用規約プライバシーポリシ。