app.js を実際に書き換えてみます。結論(先に要点)
| 対象 | 現状 | 置き換え先 | 理由 |
|---|---|---|---|
csurf |
archived / cookie@0.4.0 |
csrf-sync |
御社の構成は既に express-session を使っているので、ステートレスな csrf-csrf より Synchronizer Token Pattern の csrf-sync の方が自然に収まる（csrf-csrf の公式ドキュメントも「セッションを使っているなら csrf-sync を使え」と明言） |
connect-sqlite3 |
内部で古い sqlite3@5.1.7→node-gyp@8.4.1→tar@6.2.1 を抱える |
better-sqlite3 + better-sqlite3-session-store |
セッション専用DBだけ切り離して置き換えれば、脆弱な依存ツリーごと消せる。記事DB用の sqlite3@6.0.1 はそのまま触らなくてOK |
ejs・uuid のメジャーアップは今回の脆弱性とは無関係なので後回しでOKというのも、そのままで合っています。
実際に書き換えます。
手順
1. パッケージの入れ替え
npm uninstall csurf connect-sqlite3
npm install csrf-sync better-sqlite3 better-sqlite3-session-storeこれで csurf が抱えていた cookie@0.4.0 と、connect-sqlite3 が抱えていた sqlite3@5.1.7 → node-gyp@8.4.1 → tar@6.2.1 の依存ツリーが両方消えます。記事DB用に使っている sqlite3@6.0.1 はそのまま残るので、db.all / db.get / db.run 系のコードは一切変更不要です。
2. app.js の変更点(上の添付ファイル済み)
- セッションストア:
connect-sqlite3→better-sqlite3-session-store(better-sqlite3はネイティブビルド周りがシンプルで、古いnode-gyp/tarチェーンを引きずりません) - CSRF対策:
csurf→csrf-sync(セッション前提の Synchronizer Token Pattern。req.csrfToken()はすべてgenerateToken(req)に置換済み) - EJS テンプレート側は
_csrfという隠しフィールド名の慣習を csrf-sync も踏襲しているので変更不要です
3. 動作確認
npm startログイン → 記事投稿 → 編集 → 削除の一連のフォームが通ること(CSRFトークンが正しく検証されること)と、再起動後もログインセッションが sessions.db に残っていることを確認してください。
4. 最終チェック
npm audit
npm ls csurf connect-sqlite3 # → 何も出なければOKこれで9件の脆弱性のうち、少なくとも csurf/connect-sqlite3 経由のものは解消されるはずです。ejs(5→6)と uuid(13→14)のメジャーアップグレードは breaking changes を含む可能性があるので、今回とは別タスクとして落ち着いてから対応するのがおすすめです。
Good news: npm audit は 0 件になりました 🎉 これで csurf / connect-sqlite3 経由の脆弱性は解消です。
今出ているエラーは全く別の問題です。
原因
Error: Could not locate the bindings file...
.../sqlite3/compiled/24.20.0/linux/x64/node_sqlite3.nodeこれは Node.js v24.20.0 がとても新しく、sqlite3(記事DB用に使っている非同期ドライバ、v6.0.1)がその Node バージョン向けのビルド済みバイナリ(prebuilt binary)をまだ用意していない、という意味です。sqlite3 はネイティブアドオン(C++)なので、Node の ABI バージョンごとに専用バイナリが必要です。今回の csurf/connect-sqlite3 の入れ替え作業で npm install が走った際に依存関係が再解決され、この不整合が表面化したと考えられます(直接の原因ではなく、たまたま今気づいた形です)。
対処法
方法A: ソースからビルドし直す(その場しのぎ)
# Fedora の場合、ビルドツールが必要
sudo dnf install -y make gcc-c++ python3
npm rebuild sqlite3 --build-from-sourceこれで手元の環境用にコンパイルされます。ただし Node をまたバージョンアップすると同じ問題が再発します。
方法B: Node のバージョンを prebuilt が存在するものに合わせる(安定運用向け)
v24.20.0 は最新すぎるため、LTS版(v22系など)に落とすのが手堅いです。
nvm install 22
nvm use 22
npm rebuild sqlite3方法C: 記事DBも better-sqlite3 に統一する(根本対策・おすすめ)
セッションストアで既に better-sqlite3 を導入しましたが、これは N-API ベースで ABI 安定性が高く、新しい Node バージョンでも prebuilt バイナリが出やすい設計です。sqlite3(コールバック形式)と better-sqlite3(同期形式)は API が違うため、db.all(...) / db.get(...) / db.run(...) を書き換える必要がありますが、今後 Node を上げるたびにこの手のエラーに悩まされなくなります。
まずは方法Aか方法Bで今すぐ動く状態に戻すのが早いです。方法Cは規模の大きい変更になるので、時間があるときに別タスクとして着手するのがよいと思います。どちらを試しますか？
良いものを見つけました。この style_css.unused02 は、これまで見た他の版とほぼ同じ内容(空白の詰め方が違うだけ)ですが、1点だけ実質的に重要な違いがあります。
重要な発見:ヘッダー装飾画像の参照先が違う
| ファイル | 該当プロパティ | 参照パス |
|---|---|---|
現在使用中の public/css/style.css |
header > p:after |
url('/images/wanko.svg') ← 存在しないファイル(404) |
header.admin > p:after |
url("/img/wanko_admin.svg") ← 存在しないファイル(404) |
|
今回の style_css.unused02 |
header > p:after |
url('/images/top.svg') ← public/images/top.svg は実在します |
header.admin > p:after |
url("/img/top.svg") |
※ /img/フォルダの存在は要確認 |
つまり、**この unused02 は「壊れた wanko.svg 参照を、実在する top.svg に差し替えた版」**である可能性が高いです。以前の ls public/images の結果に top.svg(18,469バイト)がちゃんと存在していたのを覚えていますか?これを使えば、あの404を画像の追加なしに解消できます。
差分は他は全てインデント・改行スタイルの違いだけで、実質的な内容(色・レイアウト)は現在推奨している版と同じです。
提案:この修正を採用する
public/img/top.svg が存在するかだけ確認してください。
ls public/img 2>/dev/null || echo "public/img フォルダは存在しません"もし public/img フォルダ自体が無ければ、admin用も /images/top.svg に統一するのが安全です。反映しておきます。
まとめ
style_css.unused02 は機能・配色面では既存の推奨版と同じでしたが、壊れた画像参照(wanko.svg)を実在する top.svg に差し替えていたヒントを含んでいました。それを反映し、今回の最終版では:
- 配色を落ち着いたブランドカラー(青緑系)に統一
header > p:afterとheader.admin > p:afterの背景装飾画像を、存在しないwanko.svg/wanko_admin.svgから、実在する/images/top.svgに変更
これで 404画像エラーも解消されるはずです。
反映方法
cp style.css public/css/style.css
node app.js 127.0.0.1 3000ブラウザで Ctrl+Shift+R して、ヘッダー右下の装飾画像が404にならず表示されるか確認してください。念のため ls public/img を実行して /img/ フォルダの中身も確認しておくと安心です(もし違う画像が入っていれば、admin用だけそちらに差し替えることもできます)。
0 件のコメント:
コメントを投稿