owasp

🔑 JWT Verification Bugs: Pin the Algorithm, Then Prove the Fix --- title: "🔑 JWT Verification Bugs: Pin the Algorithm, Then Prove the Fix" published: true description: "Most JWT bugs are verification bugs, not crypto bugs. How to configure PyJWT, jsonwebtoken and jose safely, and the tests that prove it holds." tags: security, appsec, python, javascript cover_image: xalgorix-publisher.xalgord.workers.dev --- Most JWT vulnerabilities aren't broken cryptography. HS256 and RS256 are fine. Where things go wrong is the code that's supposed to check the token: it decodes it but never verifies it, lets the token pick its own algorithm, or checks the signature and then ignores who the token was issued to. This is a fix guide for developers. We'll go through the verification mistakes that keep showing up, how to search your own code for them, how to configure PyJWT, jsonwebtoken and jose so the library enforces the rules for you, and a small test suite that proves your verifier rejects what it should. That last part matters most. "We use a JWT library" doesn't tell you your tokens are safe. A failing forged token in CI does. Only run these tests against code you own or are authorized to test. What "verifying a JWT" actually means A signed JWT is three base64url parts: header.payload.signature. The header names the algorithm (alg), the payload carries claims (iss, sub, aud, exp…), and the signature covers the first two parts. Verifying it properly means checking all of these: 1. The signature is valid, with a key you chose, for an algorithm you chose. 2. The algorithm is one you expect. RFC 8725 (the JWT Best Current Practices, February 2020) says libraries must let the caller specify the allowed algorithms and must not use any others (§3.1). 3. The token hasn't expired (exp) and is already valid (nbf). RFC 7519 allows a small leeway for clock skew, "usually no more than a few minutes" (§4.1.4). 4. It was issued by who you think (iss) for you (aud). If an issuer serves more than one relying party, RFC 8725 §3.9 says the token must carry aud and the recipient must reject it if the audience is missing or isn't theirs. If you skip any one of these, you have a bug. Five ways verification fails 1. Decoding instead of verifying. Node's jsonwebtoken has both jwt.verify() and jwt.decode(). Its README is blunt that decode() doesn't check the signature and shouldn't be used on untrusted input. PortSwigger's JWT material describes exactly this: an app passes tokens only to decode(), so any payload is accepted. The Python version of this bug is options={"verify_signature": False}, which the PyJWT docs call "generally ill-advised". 2. Letting the token choose the algorithm. If your code reads alg from the header and verifies with whatever it says, an attacker controls the check. RFC 8725 §2.1 names the two classic results: - alg: none, an unsigned token with an empty signature. RFC 7518 §3.6 says implementations must not accept unsecured JWSs by default. PortSwigger adds that blocklists for none are often plain string checks, so a value like nOnE can slip through. - Algorithm confusion. A service that signs with RS256 receives a token with alg: HS256 that was HMAC-signed with the service's public key. If the verifier uses whatever algorithm the header names with the key it always uses, the forged token checks out. RFC 8725 §3.1's answer: each key is used with exactly one algorithm, and that's checked every time. 3. A weak HMAC secret. For HS256, RFC 7518 §3.2 requires a key of at least 256 bits, and RFC 8725 §3.5 says human-memorizable passwords must not be used directly as an HMAC key. A key like secret123 can be guessed offline from a single captured token. That's why PortSwigger has a lab just for it. 4. Valid signature, wrong token. The signature checks out, but nobody checks aud, iss or exp. So a token from your staging issuer works in production, an ID token minted for another app works against your API, or a token from last month still works. RFC 8725 §3.10 puts it simply: don't trust received claims. 5. Trusting header parameters that pick the key. jwk, jku and kid tell the verifier which key to use. If the app accepts an embedded key, fetches a key from any URL, or puts kid into a file path or SQL query, the attacker chooses the key. PortSwigger's prevention advice is to strictly allowlist jku hosts and make sure kid can't be used for path traversal or SQL injection. How to find these in your own code Start with a search. It won't prove anything, but it shows you where to look: grep -rnE 'jwt\.decode\(|verify_signature|get_unverified_header|ignoreExpiration' \ --include='*.py' --include='*.js' --include='*.ts' src/ Read each hit with the library in mind. In Node jsonwebtoken, jwt.decode() is the call that doesn't verify, so any hit on a request path is a lead. In PyJWT, jwt.decode() is the verifying call, so the question is what you pass to it: a hard-coded algorithms list, or something read from get_unverified_header()? Any verify_signature: False? An audience? Then check three things in your config: - Where does the allowed algorithm list come from? It should be a constant next to the key, never read from the token. - What is the HMAC secret? If it's short, typed by a person, or in the repo, rotate it. - Which claims are required? If exp is optional in practice, so is expiry. The fix: let the library enforce the rules You don't need to write any crypto yourself. You need to pass the right options. Python (PyJWT): import jwt # PyJWT ISSUER = "https://auth.example.com" AUDIENCE = "api.example.com" def verify_token(token: str, key: bytes) -> dict: return jwt.decode( token, key, algorithms=["HS256"], # pinned next to the key, never read from the token audience=AUDIENCE, issuer=ISSUER, leeway=30, # seconds of clock skew options={"require": ["exp", "iat", "iss", "aud", "sub"]}, ) The PyJWT docs specifically warn against computing algorithms from the token's own alg: hard-code it, or configure it in the same place as the key. options={"require": [...]} makes missing claims an error (MissingRequiredClaimError) instead of a silent pass. Node (jsonwebtoken): const jwt = require('jsonwebtoken'); function verifyToken(token, secret) { return jwt.verify(token, secret, { algorithms: ['HS256'], audience: 'api.example.com', issuer: 'https://auth.example.com', clockTolerance: 30, }); } If you leave out algorithms, the README says the default is based on the key type (for a secret, the HS256/384/512 family). Pass it explicitly anyway, so the allowed list is written down in your code. The README calls expiration "optional", so don't count on verify() to require an exp claim. Make sure your issuer always sets one. Node (jose): import { jwtVerify } from 'jose'; const secret = new TextEncoder().encode(process.env.JWT_SECRET); export async function verifyToken(token) { const { payload } = await jwtVerify(token, secret, { algorithms: ['HS256'], issuer: 'https://auth.example.com', audience: 'api.example.com', clockTolerance: 30, requiredClaims: ['exp', 'sub'], }); return payload; } jose documents that unsecured alg: "none" tokens are never accepted, that issuer and audience require the claim to be present, and that requiredClaims adds more required claims. Two things that apply whatever the library: - Generate the HMAC secret, don't type it. python -c "import secrets; print(secrets.token_hex(32))" gives 32 random bytes (256 bits). Keep it in your secret store, not in the repo. - For RS256/ES256, pin the asymmetric algorithm (["RS256"]) and load keys from your own configured JWKS. Don't follow a jku from the token, and don't trust an embedded jwk. Prove the fix holds This is the step most teams skip. A configuration that looks right is a claim. A forged token your verifier rejects is evidence. Detection isn't proof, and neither is a code review. The suite below builds test tokens with only the standard library, so it works against whatever verifier you use. It includes one positive control: a correctly signed, current token that must be accepted. Without it, a verifier that rejects everything (say, because the key isn't loaded) would pass every negative test and prove nothing. # jwt_test_tokens.py import base64, hashlib, hmac, json, time def b64url(data: bytes) -> str: return base64.urlsafe_b64encode(data).rstrip(b"=").decode() def make_token(header: dict, claims: dict, key: bytes | None) -> str: """Build a compact JWS for tests. key=None gives an unsigned token.""" head = b64url(json.dumps(header, separators=(",", ":")).encode()) body = b64url(json.dumps(claims, separators=(",", ":")).encode()) signing_input = f"{head}.{body}" if key is None: return signing_input + "." # empty signature, trailing dot sig = hmac.new(key, signing_input.encode(), hashlib.sha256).digest() return f"{signing_input}.{b64url(sig)}" def good_claims(**overrides) -> dict: now = int(time.time()) claims = { "iss": "https://auth.example.com", "aud": "api.example.com", "sub": "user-1001", "iat": now, "exp": now + 300, } claims.update(overrides) return claims # test_jwt_verify.py import secrets, time import jwt import pytest from jwt_test_tokens import make_token, good_claims from myapp.auth import verify_token # your verifier from above KEY = secrets.token_bytes(32) # stand-in test key, 256 bits HS256 = {"alg": "HS256", "typ": "JWT"} def test_control_good_token_is_accepted(): claims = verify_token(make_token(HS256, good_claims(), KEY), KEY) assert claims["sub"] == "user-1001" @pytest.mark.parametrize("token", [ make_token({"alg": "none", "typ": "JWT"}, good_claims(), None), make_token({"alg": "nOnE", "typ": "JWT"}, good_claims(), None), make_token(HS256, good_claims(), secrets.token_bytes(32)), # wrong key make_token(HS256, good_claims(exp=int(time.time()) - 600), KEY), # expired make_token(HS256, good_claims(aud="admin.example.com"), KEY), # wrong audience make_token(HS256, good_claims(iss="https://evil.example.net"), KEY), # wrong issuer make_token(HS256, {k: v for k, v in good_claims().items() if k != "exp"}, KEY), # no exp ], ids=["alg-none", "alg-mixed-case-none", "wrong-key", "expired", "wrong-aud", "wrong-iss", "missing-exp"]) def test_bad_tokens_are_rejected(token): with pytest.raises(jwt.InvalidTokenError): verify_token(token, KEY) jwt.InvalidTokenError is PyJWT's base class for decode failures. If your verifier wraps errors in your own exception type, catch that instead. For a Node service, use the same tokens: generate them with this helper as fixtures, or port the helper to your test runner. They're plain strings. Check that the suite can fail. Before you trust a green run, break the verifier on purpose: make it decode without checking the signature. Run against a stand-in verifier broken that way, the control still passes and all seven negative cases fail with "did not raise". That's what you want to see. A suite that stays green when verification is off isn't testing anything. If your service uses RS256, add one more case: a token with alg: HS256, HMAC-signed with your own public key PEM as the secret. With algorithms=["RS256"] pinned, it should be rejected. This is the algorithm confusion case from earlier, run against your own service. !Seven tokens your verifier must reject, and the one it must accept Try it yourself Only test what you own or are authorized to test. These targets are built for practice: - PortSwigger Web Security Academy, JWT labs. Free, and they map directly onto the five failures above: - JWT authentication bypass via unverified signature (Apprentice): the decode()-only bug. - JWT authentication bypass via flawed signature verification (Apprentice): alg: none. - JWT authentication bypass via weak signing key (Practitioner). - JWT authentication bypass via kid header path traversal (Practitioner). - JWT authentication bypass via algorithm confusion (Expert). Burp's JWT Editor extension, which PortSwigger's material uses, makes editing and re-signing tokens much easier. - OWASP crAPI. Its challenge list includes "Find a way to forge valid JWT Tokens" (Challenge 15). It runs locally with Docker Compose; follow the QuickStart in the repo README. - Your own service, locally. Point the test suite above at your verifier, then try to make it go green with verification switched off. If you can't, the suite works. Wrap-up JWT libraries are rarely the problem. The problem is how they're called. Pin the algorithm next to the key, require the claims you depend on, check iss and aud, and use a generated secret. Then prove it: a positive control that must pass, forged and stale tokens that must fail, and one deliberate break to show the suite can tell the difference. That gives you evidence that verification works, not just a config that looks right. Further reading - RFC 8725: JSON Web Token Best Current Practices (§2.1, §3.1, §3.5, §3.9, §3.10) - RFC 7519: JSON Web Token (claims: §4.1, validation: §7.2) - RFC 7518: JSON Web Algorithms (HMAC key size §3.2, none §3.6) - PortSwigger: JWT attacks and Algorithm confusion attacks - PyJWT usage and API reference - node-jsonwebtoken README - jose: jwtVerify and JWTVerifyOptions - OWASP crAPI challenges I'm Krishna, a pentester and the founder of Xalgorix, an open-source AI pentester that only reports vulnerabilities it has actually exploited. --- 🔐 If this was useful, follow me for more hands-on web & API security write-ups. 🔗 Connect with me on LinkedIn: linkedin.com

なぜWebアプリには「全セッション切断」が必要なのか ChatGPTをはじめ、X、Google、Microsoft、Slackなど、多くの主要Webサービスでは、ログイン中の端末を確認したり、別の端末のログイン状態を取り消したりする仕組みが提供されています。 例: Xのセッション管理UI ところが、自分でWebアプリケーションを開発すると、意外とこの機能が抜け落ちていることがあります。ログアウト機能はあるし、パスワード変更もできる。 しかし、他の端末で有効になっているログイン状態を取り消す手段がない。 ログアウトできることと、他の端末を追い出せることは違う まず、ごく普通のログアウトを考えてみます。 PHPであれば、例えば次のような処理です。 // 現在のセッションを破棄する session_destroy(); // これはサーバー側のセッション破棄だけを示した簡略例です。 // 実際のログアウト処理では、セッション変数の初期化や // セッションCookieの削除なども考慮します。 しかし、同じアカウントで別のブラウザからログインしていた場合、そのセッションには影響しません。 例えば、次のような状態です。 ここでスマートフォンからログアウトしても、終了するのはセッションBだけであり、セッションAやCは引き続き使用できます。 ここで、第三者がセッションAのCookieを盗み、それを自分のブラウザに設定した場合を想定すると、本人が自宅PCのブラウザから通常のログアウトを実行すれば、サーバー側でセッションAが正しく失効し、コピーも使えなくなります。 しかし、本人がスマートフォンしか操作できなかったらどうでしょうか。自宅PCのセッションを遠隔で無効化する機能がなければ、第三者のアクセスを止める手段がありません。 つまり、通常のログアウト機能だけでは、アカウントの所有者がすべての認証状態を制御できるわけではないのです。 パスワードを変えれば解決するのでは？ 不正アクセスが疑われる場合、まずパスワードを変更するよう案内されることが多いと思います。もちろん、パスワード変更は重要です。しかし、パスワードを変更しても、既存のログインセッションが自動的に失効するとは限りません。 そもそも、多くのWebアプリケーションは、認証が成功するたびにパスワードを検証しているわけではありません。 ログイン後のアクセスでは、パスワードではなくセッションが認証状態を維持しています。したがって、パスワードを変更しても、既存セッションを失効させる処理がなければ、そのままログイン状態が続く場合があります。 しかもこれは、単純なパスワード認証に限りません。例えば、GitHubやGoogleなどを利用したOAuthログインでも同様です。 認証に成功した後は、アプリケーション自身が発行したセッションによってログイン状態を維持する構成が一般的です。この場合、外部サービス側のパスワードを変更したからといって、アプリケーション側の既存セッションまで自動的に失効するとは限りません。 MFAを有効にしていても結局は同じ 多要素認証（MFA）が有効なら安全なのでは、と考えるかもしれませんが、しかし、MFAは主に認証時の防御です。認証済みのセッションCookieを盗まれた場合、アプリケーションによってはMFAを再度要求せずにアクセスできてしまいます。 ! つまりMFAだろうがパスキーだろうが、結局は扉の鍵をどうするかなのであって、鍵を開けた部屋の中に潜りこまれればいくら鍵を強くしても、あるいは部屋から施錠したとしても有効ではありません。 もちろん、認証情報を端末に結び付ける仕組みや、重要操作時の再認証などで被害を軽減できる場合はありますので、有効ではありますが、ただしそれでも、MFAだけでセッション乗っ取りの問題が解決するわけではありません。新しいログインを防ぐことと、既に成立しているログインを取り消すことは、別のセキュリティ対策なのです。 全セッション切断が必要になる場面 では、どのような状況で全セッション切断が必要になるのでしょうか。 端末の紛失・盗難 もっとも分かりやすい例です。 ログイン状態を維持したままのノートPCやスマートフォンを紛失した場合、別の端末からログイン状態を解除できる必要があります。端末の画面ロックやディスク暗号化は重要ですが、それらだけに依存するのは適切ではありません。 セッションCookieの漏洩 XSS、マルウェア、端末の侵害などによって、セッションCookieや認証トークンが漏洩する可能性があります。 ! 例えば、情報窃取型マルウェア （インフォスティーラー）に端末が感染すると、ブラウザに保存された認証情報やセッションCookieをごっそり窃盗される事があります。 ソフトウェアのサプライチェーン侵害が、こうしたマルウェアの配布経路になる場合もあります。(参考: 800件超の悪性npmパッケージがRAT・スティーラーを配布) HttpOnly属性などの適切なCookie設定は重要ですが、それだけであらゆる漏洩経路を防げるわけではありません。漏洩を完全に防止する仕組みに加えて、漏洩した認証情報を後から使えなくする仕組みも必要です。 共有端末からのログアウト忘れ 大学のPC教室、社内の共有端末、出張先の端末などでログアウトを忘れる場合もあります。本人がその端末に戻れなくても、遠隔からセッションを終了できれば問題を軽減できます。YouTubeなどはよく考えられてはいるものの、他者のテレビにログインしっぱなしという事だってありえます。 アカウント侵害からの復旧 不正アクセスが判明した場合、パスワード変更やMFAの再設定だけでは不十分なことがあります。なぜなら既に別のセッションの入口を持っている可能性があるからです(これはパスワード/MFA/パスキーを経由して鍵を開けるのとは別の概念です)。 ここでは既存セッションをまとめて失効させ、正規ユーザーだけが再びログインできる状態に戻す必要があります。 ! もちろん、攻撃者がパスワードや外部IDプロバイダーのアカウントまで支配しているなら、セッションを切断しただけでは再ログインされてしまいます。したがって、全セッション切断はアカウント復旧の一要素であって、万能な対策ではありません。 管理者による強制切断 ユーザー本人の操作だけでなく、管理者による強制切断も重要です。例えば、退職者のアカウントを無効化した場合です。 アカウントを無効化しても、既存の認証セッションが引き続き利用できる設計では困ります。権限剥奪やアカウント停止の効果が、既存のログイン状態にも確実に反映される必要があります。 ここまで考えると、セッション切断は単なる便利機能ではなく、インシデント発生時にアカウントの制御権を回復するための機能だと分かります。 OWASPもセッションの失効を要求している この問題は、開発者の好みや経験則だけで語られているわけではありません。 Webアプリケーションのセキュリティ基準を公開しているOWASPでは、ASVS（Application Security Verification Standard）という検証基準を策定しています。 OWASP ASVS 5.0のセッション管理に関する要求を見てみます。 要求ID 内容 レベル V7.4.1 終了したセッションを再利用できないこと L1 V7.4.2 アカウント無効化・削除時に全セッションを終了すること L1 V7.4.3 認証要素変更後に他セッションを終了できること L2 V7.4.5 管理者がユーザーのセッションを終了できること L2 V7.5.2 ユーザーがセッションを確認し、再認証後に個別・一括終了できること L2 特にV7.5.2では、ユーザー自身によるセッション一覧の確認と、個別または一括終了が要求されています。 github.com/OWASP/ASVS/blob/master/5.0/en/0x16-V7-… ここで注目したいのは、操作前に少なくとも1つの認証要素による再認証を求めている点です。セッションを乗っ取った攻撃者が、正規ユーザーをすべての端末からログアウトさせることも考えられるためです。 また、OWASPのSession Management Cheat Sheetでも、セッションの遠隔終了、同時ログインの確認、アカウント活動履歴の管理などが推奨されています。 ! ただし、ASVS L2の要求を満たしていないことが、直ちに脆弱性の存在や法令違反を意味するわけではありません。アプリケーションが扱う情報やリスクに応じて、必要な水準を決めることになります。 それでも、一般的な業務アプリケーションや個人情報を扱うサービスでは、全セッション切断を標準的なセキュリティ要件として検討すべきでしょう。 なぜ実装が意外と難しいのか ここまで必要性を説明しましたが、実装は必ずしも簡単ではありません。 理由は単純です。 ログイン状態を作るための仕組みと、既存のログイン状態をすべて探して破棄するための仕組みは別だからです。 例えば、昔ながらのPHPアプリケーションを考えます。 session_start(); $_SESSION['user_id'] = $user['id']; $_SESSION['authenticated'] = true; これでログイン状態を保持できます。 しかし、このコードだけではユーザーIDに紐づく全セッションを探せません。PHP標準のファイルセッションには、ユーザーIDを指定して全セッションを取得するAPIがないためです。 さらに、次のような認証処理があちこちに存在していたらどうでしょうか。 if ($_SESSION['login']) { // 認証済み } if (isset($_SESSION['user_id'])) { // 認証済み } アプリケーションの一部に新しい失効処理を追加しても、別の処理経路からアクセスできる可能性があります。 全セッション切断を正しく実装するには、認証が必要なすべての経路で失効状態を確認する必要があります。結果として、全セッション切断の追加が、認証機構全体の改修になってしまうこともあります。 全セッション切断だけなら別の方法もある 必ずしも、すべてのセッションを列挙する必要はありません。 例えば、ユーザーに認証バージョンを持たせる方式です。 users.auth_version = 3 セッションA：auth_version = 3 セッションB：auth_version = 3 全セッション切断時にバージョンを更新します。 UPDATE users SET auth_version = auth_version + 1 WHERE id = ?; その後、各リクエストで認証バージョンを比較すれば、古いセッションを無効化できます。 users.auth_version = 4 セッションA：auth_version = 3 → 無効 セッションB：auth_version = 3 → 無効 この方式なら、ユーザーとセッションの対応表がなくても全セッションを論理的に失効させられます。ただし、認証が必要な各リクエストでバージョンを検証する必要があります。また、既存の認証処理が散在している場合は、そのすべてに検証処理を適用しなければなりません。 結局、どの方式を採用しても、認証処理の設計が重要になります。 例えばLaravelの場合は比較的少ない改修で実現できる Laravelには、セッション管理や認証の仕組みが標準で用意されていますし、さらに、他の端末をログアウトさせるメソッドも存在します。 // 他のデバイスからログアウトさせる Auth::logoutOtherDevices($currentPassword); ! 最近のLaravelでは、内部的にパスワードハッシュを再生成し、AuthenticateSessionミドルウェアで既存セッションとの不一致を検出する仕組みになっています。 そのため、対象の認証ルートにミドルウェアが適用されていなければ、期待どおりの失効は実現できません。 なお、Laravelには次のような汎用的なメソッドはありません。 // このような標準メソッドはない Auth::logoutAllDevices(); とはいえ、Laravelがすでにセッション管理の仕組みを持っていることは大きな利点です。 Laravelで Database Sessionを利用する場合 LaravelのDatabase Sessionでは、セッションテーブルにユーザーIDが記録されます。 そのため、例えば次のように当該ユーザーのセッションを削除できます。 DB::table('sessions') ->where('user_id', $user->id) ->delete(); ただし、これは全セッション切断処理の一部分にすぎません。 実際には、Remember Meによる再認証への対策、現在のセッションの終了、並行処理なども考慮する必要があります。 そして、この方法はご覧の通りDatabase Sessionを前提としており、ファイルやRedisなど、すべてのセッションドライバでそのまま使えるわけではありません。Laravelが複数のセッションドライバをサポートしていること自体が、汎用的な全セッション切断APIを作りにくくしている理由の一つとも考えられます。 Laravelを利用した独自実装する場合、Remember Meも忘れてはいけない Laravelでは次のような認証が可能です。 Auth::login($user, remember: true); Remember Me機能を有効にしている場合、通常のセッションが失われても、保存されたCookieによって認証状態が復元されることがあります。つまり、セッションテーブルから該当レコードを削除しただけでは、全セッション切断が成立しない可能性があります。 全ログアウト時にはRemember Meトークンも失効させる必要があります。 ! ここで重要なのは、セッションの削除と認証情報の失効は、必ずしも同じ操作ではないということです。 Laravelはそれらを扱う機構を提供していますが、全セッション切断という操作に正しく組み合わせるのはアプリケーション側の仕事です。 他のフレームワークではどうなのか Laravel以外の主要フレームワークも、簡単に調べてみました。 フレームワーク 全セッション切断に利用できる仕組み Ruby on Rails 8 認証ジェネレータのSessionモデル Django 認証ハッシュ、django-allauthのセッション管理 Spring Security SessionRegistry Spring Session ユーザー別のセッション検索・削除 ASP.NET Core Identity Security Stamp Better Auth revokeSessions() Phoenix 認証トークンのDB管理 例えばRails 8の認証ジェネレータでは、ユーザーに紐づく認証セッションをモデルとして管理します。 ASP.NET Core Identityでは、Security Stampを更新することで既存の認証Cookieを失効させる仕組みがあります。ただし、失効の反映には検証間隔が関係します。 Better Authには、一括失効や個別失効の専用APIまで用意されています。 一方、GoのGinやPythonのFastAPIのような比較的軽量なフレームワークでは、採用する認証ライブラリやセッション管理方式によって事情が大きく異なります。 つまり、セッション切断の難易度は、言語そのものよりも、どのような認証基盤を採用しているかに左右されますが、ここで共通しているのは、フレームワークに失効機構が用意されていても、アプリケーションがそれを利用する経路を提供しなければ、ユーザーは使えないということです。 では、最低限どこまで実装すべきなのか では、すべてのWebアプリケーションに、ChatGPTのようなセッション管理画面が必要なのでしょうか。私は、そこまでは必要ないと思います。 例えば、セッションが短命で、機密情報を扱わず、ログイン状態も長期間維持しないような小規模なサービスであれば、セッション一覧画面まで実装する優先度は高くないかもしれません。一方、個人情報や業務情報を扱い、長期間ログイン状態を維持するWebアプリケーションであれば、少なくとも全セッション切断は用意しておきたいところです。 考えられる機能を整理すると、次のようになります。 機能 重要性 通常のログアウトでセッションを確実に失効 基本要件 セッションの有効期限管理 基本要件 アカウント停止・削除時の全セッション失効 基本要件 ユーザー自身による全セッション切断 強く推奨 パスワード変更・復旧時の既存セッション失効 強く推奨 管理者による強制切断 業務システムでは重要 セッション一覧・個別切断 リスクに応じて導入 失効操作前の再認証 高い保証水準では重要 ただし、これは実装上の優先順位を整理したものであり、OWASP ASVSの要求をそのまま分類した表ではありません。また、全セッション切断を設計するときには、いくつか注意すべき点があります。 まず、失効の対象を明確にすることです。 ブラウザのセッションだけなのか、Remember Meも含むのか、APIトークンやモバイルアプリの認証も含むのか。「すべての端末からログアウト」と表示しておきながら、実際には一部の認証経路が残っているなら、ユーザーに誤解を与えます。 次に、失効の即時性です。 セッションを削除しても、既に処理中のリクエストまで即座に停止できるとは限りません。認証バージョン方式などでは、次回の検証まで古いセッションが利用できる場合もあります。「全セッション切断」がどの時点で反映されるかは、認証方式によって異なります。 そして、全切断操作自体の保護です。 攻撃者が有効なセッションを持っている場合、攻撃者も全ログアウト操作を実行できる可能性があります。 全セッション切断などの重要操作には、セッションの存在だけに依存しない再認証が必要です。パスワード、パスキー、MFAなど、アプリケーションの認証方式に応じて実装します。 CSRF対策、操作頻度の制限、再認証、監査ログなどを、アプリケーションのリスクに応じて検討する必要があります。 おわりに：ログインを作るなら、追い出す方法も考えておきたい Webアプリケーションを開発するとき、ログイン機能は当然のように実装します。しかし、一度成立した認証を、本人や管理者がどう取り消すのかについては、意外と後回しになりがちですが、これは設計として少し不自然な気もします。認証情報が漏洩しないことを前提にするのではなく、漏洩する可能性を考え、その際に被害を止められる仕組みを用意する。セキュリティでは、ごく基本的な考え方でしょう。 全セッション切断は、そのための一つの手段です。 もちろん、全セッション切断があれば安全というわけではありません。認証情報の漏洩防止、MFA、適切な有効期限、再認証など、ほかの対策と組み合わせる必要があります。それでも、アカウントを侵害された可能性があるとき、ユーザーが自分で既存の認証状態を取り消せるかどうかは重要です。 LaravelやRailsなど、成熟したフレームワークには、そのための仕組みがかなり用意されています。しかし、実際にユーザーが使える機能にするには、アプリケーション側で処理を接続しなければなりません。反対に、独自実装のレガシーシステムでは、そのための基盤そのものが存在しないかもしれません。そう考えると、新規開発の段階でセッション失効の仕組みを考慮しておく意味は大きいと思います。 ログインできることだけでなく、必要になったら確実にログイン状態を取り消せること。 をWebアプリケーションの認証機能を設計するうえで、初期段階で考慮されるべきとは思います。

Auditing LLM Agents Against 214 OWASP AISVS Requirements: Rico Komenda and Jim Manico at Global AppSec USA 2026 OWASP's AI Security Verification Standard (AISVS) released version 1.01 on October 5, 2026, growing from 191 to 214 testable requirements, with most of the growth in its MCP security chapter. AISVS lists security requirements for applications built on LLMs, agents and retrieval-augmented generation (RAG). Writing "verify that" in a standard is easy, while checking it against a running AI system is not. In their Global AppSec USA 2026 workshop, "Hands-On AI Security Assessment with OWASP AISVS", on Friday, November 6 at 10:30 a.m. in Golden Gate, Rico Komenda and Jim Manico walk through practical assessment scenarios using the standard. Speakers: - Rico Komenda, Senior Product Security Engineer - Jim Manico, Founder, Manicode Security Participants work through real requirements from chapters on prompt injection defense, agentic action security, RAG and vector database hardening, as well as output safety controls. They learn to scope an AI security assessment and select a verification level. They then apply AISVS requirements to LLM-based applications, autonomous agents and MCP-connected tools, so a laptop is needed to follow along. AISVS has three levels. Level 1 is a baseline, Level 2 covers systems handling sensitive data or consequential decisions, and Level 3 is for high assurance. Version 1.01 includes requirements such as rejecting, rather than truncating, inputs that exceed token limits at Level 1. At Level 2, retrieved or tool content must never gain higher priority than the system's own instructions. The MCP security chapter grew from 23 requirements to 40 between versions. On October 20, 2026, the project deferred a planned 2.0 to focus on version 1.02. Rico Komenda is a Senior Product Security Engineer who works on the attack surface of AI-integrated systems. He co-leads AISVS with Jim Manico, Otto Sulin and Russ Memisyazici. Jim Manico founded Manicode Security, which trains developers in secure coding, and founded AISVS. He co-leads OWASP ASVS and wrote "Iron-Clad Java: Building Secure Web Applications." Both speakers also present the AISVS project showcase on Thursday at 10:30 a.m. in Seacliff CD. Komenda gives a talk on security chaos engineering for AI on Thursday at 1:45 p.m. The same team ran this workshop at Global AppSec EU 2026 in Vienna in June. The AISVS repository holds every released version, with requirement IDs that never get renumbered. To go deeper on the topic, start here: - ITSPmagazine podcast: Jim Manico on building AISVS (audio) - OWASP AISVS on GitHub (1.01 release and requirements) - OWASP AISVS project page - LRQA Cyber Labs: AISVS 1.0 chapter-by-chapter - VirtusLab: AISVS 1.0 requirement walkthrough Security testers asked to assess AI features without a defined test scope will practice building one from published requirements. Which AISVS verification level would your production AI features need to meet?

Recon, CVE Checks, Default-Credential Brute Forcing With 135 OWASP Nettacker Modules: Sam Stepanyan and Arkadii Yakovets at Global AppSec USA 2026 OWASP Nettacker, an open-source automated penetration testing framework written in Python, now ships 135 modules, 68 of which check for specific CVEs such as Log4Shell and Citrix Bleed. The name comes from "Network Attacker." Nettacker scans applications or networks, then reports on running services, bugs, vulnerabilities, misconfigurations and default credentials. It can chain different scan methods together. It has drawn interest from penetration testers in Europe and Asia. It is also included in a specialist Linux distribution for security researchers. In their Global AppSec USA 2026 project showcase, "Automated Security Testing with OWASP Nettacker", on Thursday, November 5 at 2:15 p.m. in Seacliff CD, Sam Stepanyan and Arkadii Yakovets run a live demo with practical examples of automated security testing. Speakers: - Sam Stepanyan, OWASP London Chapter Leader - Arkadii Yakovets, Cybersecurity Lead, OWASP Nest and OWASP Nettacker Nettacker's modules break down into 36 scan modules, 90 vulnerability checks and 9 brute-force modules. The brute-force modules test default or weak credentials over FTP, POP3, SMB, SMTP, SSH and Telnet, among others. The CVE checks cover recent targets such as Ivanti Connect Secure, Palo Alto PAN-OS, CrushFTP, Langflow and Next.js. Targets can be IP addresses, ranges, CIDR blocks, domains or URLs. Results come out as HTML, JSON, CSV or text reports. A built-in scan database detects drift between runs, so teams can use Nettacker in CI/CD to catch new exposures. Nettacker runs from the command line, a REST API or a web interface. It is released under the Apache 2.0 license, with version 0.4.1 published in August 2026. Sam Stepanyan is an independent application security consultant with more than 20 years in IT. He serves on the OWASP Global Board of Directors and has led the OWASP London Chapter since 2015. He is a project leader of Nettacker who has also contributed to the OWASP Top 10 and OWASP ZAP. He received the 2023 OWASP WASPY award for chapter leadership. He has presented Nettacker at Black Hat Europe Arsenal, Black Hat Asia, AppSec California and OWASP Global AppSec DC 2023. He has also consulted for City of London financial institutions on secure development and vulnerability management. Arkadii Yakovets joined OWASP in 2023, started contributing to Nettacker that year and became a co-leader. He also founded OWASP Nest, which he leads, as a platform for exploring OWASP projects, chapters and ways to contribute. He has mentored more than 10 Google Summer of Code students on OWASP and Python Software Foundation projects. He leads the open-source Python "holidays" library, which his board candidate page reports at more than 17 million monthly downloads. He holds CISSP, CCSP and CSSLP certifications. He co-presented Nettacker with Stepanyan at Global AppSec EU 2026 in Vienna. The Nettacker repository holds the full module list. The project documentation links recordings of past Nettacker talks going back to 2017. To go deeper on the topic, start here: - NDC Security 2026: Automated Security Testing with OWASP Nettacker (Sam Stepanyan, video) - The Application Security Podcast: Sam Stepanyan on the OWASP Nettacker Project - OWASP Nettacker on GitHub - Help Net Security: OWASP Nettacker open-source scanner - nettacker on PyPI Security teams looking for a free scanner they can run on a schedule against their own external footprint will see Nettacker set up end to end. How often does your team scan its own external footprint for default credentials and known CVEs?

Finding Card Numbers Hiding in Your Postgres Columns or Jira Tickets: Nandan Gupta and Nayan Goel at Global AppSec USA 2026 OWASP PIIHunter scans PostgreSQL columns, Jira ticket comments and free-text notes fields for personally identifiable information that engineers rarely think to look for. Personally identifiable information (PII) includes Social Security numbers, card numbers, phone numbers and names. It often ends up in places no data inventory covers, such as a customer's card number pasted into a support ticket. PIIHunter detects it in three layers. Regular expressions with a Luhn checksum validate card numbers, Microsoft Presidio's machine learning recognizes named entities, and an optional self-hosted LLM handles ambiguous text. No data leaves the organization's perimeter during a scan. In their Global AppSec USA 2026 demo lab, "OWASP PIIHunter: AI-Powered PII Discovery in Databases and Jira", on Thursday, November 5 at 1:15 p.m. in Golden Gate, Nandan Gupta and Nayan Goel scan a real database alongside a live Jira instance. Speakers: - Nandan Gupta, Principal Application Security Engineer - Nayan Goel, Principal Application Security Engineer The demo surfaces SSNs, phone numbers and names from the database. It also catches a credit card number posted in a Jira ticket in real time. The PIIHunter repository shows how the scan stays contained. It connects to PostgreSQL through a read-only role, samples rows rather than reading every one, and stores results in a separate schema with redacted samples. Jira scanning works by polling or through real-time webhooks, which are checked with HMAC-SHA256 signatures. Every scan is written to an audit log. Nandan Gupta is a Principal Application Security Engineer at a fintech company, working on secure design, code review and threat modeling. He has presented at Black Hat Europe, the DEF CON AppSec Village and BSidesSF. He wrote PIIHunter's Jira integration, added in April 2026. Nayan Goel is a Principal Application Security Engineer at a fintech company and an AI security researcher, with more than seven years in application security. He wrote PIIHunter's first version in December 2025, then hardened it for its move to OWASP in October 2026. He created PromptInjector, a tool for testing AI systems for prompt injection that works with OpenAI, Anthropic or Ollama models. He contributes to the OWASP Agentic Security Guidelines. The two co-wrote GraphQL Security Tester, a Burp Suite Professional extension in PortSwigger's BApp Store. It uses Burp AI to generate GraphQL queries that test for SQL injection, authorization bypass, denial of service and information disclosure. To go deeper on the topic, start here: - OWASP PIIHunter source code - Microsoft Presidio documentation - GraphQL Security Tester by Nayan Goel and Nandan Gupta (BApp Store) - PromptInjector by Nayan Goel Privacy and security teams that have mapped PII in their main databases, but never in tickets or notes fields, will see what they may be missing. Has anyone at your company ever searched your Jira tickets for card numbers or Social Security numbers?

Code Review Drills for Finding Bugs and Writing Fixes With OWASP ASVS 5.0: Eden Yardeni at Global AppSec USA 2026 The OWASP Application Security Verification Standard (ASVS) 5.0 contains about 350 security requirements across 17 chapters, and it was the standard's first major release since 2021. ASVS lists what a secure application must do, from input encoding to authentication to WebRTC. AppSec engineers can use those requirements to turn a code review finding into specific feedback a developer can act on. In her Global AppSec USA 2026 demo lab, "Life finds a way: Secure Coding with OWASP ASVS", on Thursday, November 5 at 1:15 p.m. in Golden Gate, Eden Yardeni runs guided code review exercises built on the standard. Speaker: Eden Yardeni, Senior AppSec Engineer Participants learn to identify security vulnerabilities in code, assess their impact and recommend fixes. The exercises cover vulnerabilities across a range of categories. Each exercise shows how to tie a finding to an ASVS requirement. That turns a vague "this is insecure" comment into feedback with a clear standard behind it. The lab needs nothing beyond a laptop with a browser. Eden Yardeni is a Senior AppSec Engineer who contributes to OWASP projects including ASVS. She worked as a full-stack developer before moving into security. She is listed in the working group for ASVS 5.0, alongside project leads Daniel Cuthbert, Elar Lang and Josh Grossman. Her work focuses on defining application security standards and putting them into practice across engineering teams. At SecAppDev 2026 in June, she taught "What's New in ASVS v5," an advanced lecture with code review demos on OAuth, WebSockets and race conditions. That lecture covers the main changes in version 5. Requirements are rewritten as verifiable properties, levels are rebalanced around risk, and CWE mappings give way to OpenCRE, a resource that links security standards to one another. Her lecture slides are published. The full standard, with a mapping back to version 4.0, is in the ASVS repository. To go deeper on the topic, start here: - What's New in ASVS v5, SecAppDev 2026 session page - What's New in ASVS v5 slides (Eden Yardeni) - OWASP ASVS 5.0 on GitHub - OWASP ASVS project page Developers and reviewers who want their code review comments backed by a standard will get practice doing exactly that. Do your code review comments cite a specific security requirement, or just say something is insecure?

From 200 Container CVEs to the Few Dockerfile Lines Worth Fixing: Advait Patel at Global AppSec USA 2026 A container image scan typically returns more than 200 CVEs, most of them noise, with no indication of which few Dockerfile lines a developer should change. According to Advait Patel's session description, those reports get ignored. Someone spends half a day looking up each CVE, then files the rest as accepted risk. OWASP DockSec, which Patel created, sits on top of existing scanners rather than replacing them. It runs Trivy, Hadolint and Docker Scout locally. An LLM then correlates the results, removes duplicates, then ranks what matters for the specific setup. In his Global AppSec USA 2026 demo lab, "DockSec: Closing the Gap Between What Your Scanner Finds and What You Actually Fix", on Thursday, November 5 at 10:30 a.m. in Golden Gate, Advait Patel runs real Dockerfiles through the tool live. Speaker: Advait Patel, Senior Site Reliability Engineer, Broadcom The demo includes Dockerfiles that pass standard scanning clean. For each issue DockSec surfaces, it gives a plain-English explanation along with the exact line-level fix. DockSec produces a 0 to 100 security score for tracking posture over time. It exports HTML, PDF, JSON, CSV or Markdown reports, so security and development teams share one artifact. Only scan metadata leaves the machine; image contents never do. DockSec works with OpenAI, Anthropic or Google Gemini models, or fully locally through Ollama with no API key, and it runs in CI/CD on every build. Attendees can bring their own Dockerfiles. Patel also gives a 30-minute DockSec project showcase on Thursday at 2:45 p.m. in Seacliff CD. Advait Patel is a Senior Site Reliability Engineer at Broadcom in Chicago and a Docker Captain. He has more than eight years of experience in cloud-native architecture, container security and DevSecOps. He is a Google Developer Expert for Google Cloud and AI. He is a founding member of the OWASP AI Vulnerability Scoring System (AIVSS) project. He has co-authored two Springer books on Google Cloud security, along with Cloud Security Alliance guidance on securing LLM workloads. His speaking credits include QCon AI Boston, SANS CloudSecNext, OWASP SnowFROC, PlatformCon and the Linux Security Summit North America. The OWASP DockSec project page shows it reached OWASP Lab status in June 2026, with Arkadii Yakovets as co-leader. It also outputs SARIF and CycloneDX SBOM files. Secrets are redacted before any content reaches an AI provider. SC World reported about 17,000 PyPI downloads. It also described one startup that cut production CVEs by 78 percent, from about 22 to about 5 per month, while triage time per image fell from about 45 minutes to about 6. To go deeper on the topic, start here: - ISACA Podcast: Your Containers Are Probably Full of Holes: Fixing Docker Security with AI (Advait Patel) - OWASP/DockSec on GitHub - Help Net Security interview with Advait Patel on DockSec - SC World: DockSec adoption and triage-time results - docksec on PyPI Platform engineers who own container images, and who are tired of untriaged scanner output, are the audience for this demo. How many open container CVEs does your team currently carry as accepted risk?

That the American Osteopathic College of Radiology [aocr.org](aocr.org) have such an incredible interest in our main Cornucopia repository (owasp/cornucopia) on Github is a mystery to me. Does anyone care to elaborate? #appsec #security #osint

@giadotai Been doing this for research and coding for a while now. I give Codex direct access to the Claude Code CLI. Here are examples at how I codify this. github.com/OWASP/CheatSheetSeries/blob/master/MOD… github.com/OWASP/owasp-java-encoder/blob/main/MOD…

MCPサーバを社内で使い始めている組織は多いのに、リスクを語る語彙が揃っていなかった。OWASPが分類を出したことで、脅威モデリングや監査の会話が成立するようになる。セキュリティ担当はTop 10の対応表から目を通すと早い OWASP/MCP-Taxonomy