"JWT=ステートレス"から一歩踏み出すための考え方
おはようございます、ritouです。 この話に乗っかっていきます。 3行で ログアウト時にJWTを無効化できない実装は今後脆弱性診断で「OWASP Top 10 2021違反」と指摘されるようになりそう(今も個別にされてるかもしれないけど) JWTは単純なフォーマットなので、ステートレスなセッション管理においてログアウトしたときに文字列自体を無効化できない件は独自エンコード方式(一般的にフレームワークのCookieストアと呼ばれているもの)でも起こり得る 「セッションID vs JWTで内包」 以外にも 「セッションIDをJWTに内包」もあり得る。既存の機能を残しつつ「JWTで武装」する選択肢も考えてみてはどうか。 ステートレスなセッション管理でログアウトの際に文字列自体を無効化できない問題 これは前から言われていますし、駆け出し何とか勢のQiita記事に書かれるぐらいには一般的です。 2
Web認証におけるせめぎ合い – 2人のセキュリティ専門家によるやりとり | POSTD
(訳注：2015/11/1、いただいた翻訳フィードバックを元に記事を修正いたしました。) 成長し続ける様々な脅威に対抗すべく、この10年間でWeb認証システムは進化を遂げてきました。この記事では、架空のWebアプリケーション開発者とアタッカーのせめぎ合いを通じて、最新のセキュリティ技術がどのように様々な脅威に対抗することができるかを提示したいと思います。 以下のやり取りにおいて、ユーザはアタッカーが出現する前に、すでにディフェンダーでいくつかのトラストアンカー（パスワードやハードウェアトークンなど）を正規に確立していることが前提となっています。暗号は、時間や空間にわたって、既存のトラストや秘密を伝達する場合にのみ 使うことができます 。もし、トラストやセキュリティが確立される前にアタッカーがディフェンダーになりすましたとしたら、正規のものを見分けるのは極めて難しいでしょう。また、サイトには
TLS暗号設定ガイドライン 安全なウェブサイトのために（暗号設定対策編） | 情報セキュリティ | IPA 独立行政法人 情報処理推進機構
「TLS暗号設定ガイドライン」は、TLSサーバの構築者や運営者が適切なセキュリティを考慮した暗号設定ができるようにするためのガイドラインです。「様々な利用上の判断材料も加味した合理的な根拠」を重視して、TLS通信での実現すべき安全性と必要となる相互接続性とのトレードオフを考慮した3つの設定基準（「高セキュリティ型」「推奨セキュリティ型」「セキュリティ例外型」）を設けており、各々の設定基準に対応して、TLSサーバで設定すべき具体的な要求設定（「遵守項目」と「推奨項目」）を決めております。 本ガイドラインは安全なウェブサイトの作り方とともに適切な暗号設定をする資料の一つとしてお使いいただけます。 なお、本ガイドラインは、暗号技術評価プロジェクトCRYPTRECで作成されました。 「TLS暗号設定ガイドライン」の内容 1章と2章は、本ガイドラインの目的やSSL/TLSについての技術的な基礎知識を
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
TLS徹底演習
