node.jsを利用したクローラー作成(42)

フロントエンドとバックエンドのセキュリティ検討を行う！

🤯うわー

ベストプラクティスにしろ項目多すぎる…

N予備校のテキスト

よくあるwebサービスの脆弱性について診断を行う。

✅OSコマンドインジェクション　←該当なし
✅SQLインジェクション　←対応済み
・NoSQL部分(firestore)のクエリはサーバー側で投げる
・urlをパラメータ化している部分はvalidation(whitelist)を行う
✅ディレクトリ・トラバーサル ←対応済み
・expressのRooterが担保する
・GCPのdispatch.yamlがrootingを担保する
✅セッションハイジャック　← 対応済み
・firebase auth のトークン発行機能+serviceworkerでのセッション管理にて担保する
・firebaseのuidはバレても大丈夫そうだが、積極的な公開を控える

firebaseの認証で扱うユーザーのuidを公開の状態にしてもセキュリティ的に問題ないか。｜teratail

✅XSS ← ユーザー入力値に応じた表示部分なし。
・エンドポイント(API)については入力値をvalidationする。
✅CSRF ←ユーザー入力値に応じた送信部分なし。
・認証状態についてはfirebase authトークンが期限付きになっている。
✅ HTTP ヘッダインジェクション　←問題なし
・servicewokerでheaderにトークンを埋め込む。サーバー側で検証する。
・⚠serviceworker実装が手作りに近い…。
✅クリックジャッキング ←対応済み
・expressのhelmet middlewareにてX-Frame-Options設定がされる
✅パスワード周り ←対応済み
・firebaseuiを利用したOauth認証。自サイトではpassword等を管理しない。
・⚠firebaseuiの実装よく見てない…。

GAEのセキュリティ

セキュリティ診断機能とfirewallあり

アプリの保護  |  Node.js 用 App Engine スタンダード環境に関するドキュメント  |  Google Cloud

🔰セキュリティ診断　←サイトdeploy後にやる。保留。
🔰firewall設定　←保留。アクセス解析と合わせないと意味ない。
アクセス解析設定を後でやる。

DDOS攻撃について

App EngineはSYN floods攻撃、IP fragment floods攻撃、ポート枯渇攻撃など、レイヤー4以下の攻撃の多くを緩和・吸収するGoogleフロントエンドの後ろに位置します。

Google Cloud Platform上でのDDoS保護と影響緩和のベストプラクティス（和訳） - Qiita

正規のHTTP通信の大量送信についてはfirewallにて対処する。
cloud armerは未調査。前提としてCloud Load Balancingが必要で、そちらは有料なので…。

バックエンドのエンドポイントを守る

✅対応済み
・GCP内で付与される特殊なリクエストヘッダーを用いて、CloudTaskからの呼び出しかどうか判定できる。

App Engine タスクハンドラの作成  |  Cloud Tasks のドキュメント  |  Google Cloud

expressでは判定用のミドルウェア作成し、ダメならリクエストを却下する。
GAEのcronリクエストにも特殊リクエストヘッダーがある。そちらも対応。

cron.yaml を使用したジョブのスケジューリング  |  Java の App Engine フレキシブル環境に関するドキュメント

Expressのセキュリティベストプラクティス

公式情報。

Security Best Practices for Express in Production

✅古いExpressのversion使わない ←ok
✅TLSを利用する ←GAEはhttpsで公開される

App Engine に関するよくある質問  |  App Engine ドキュメント  |  Google Cloud

✅helmet利用する ←導入
✅Cookieを安全に利用する← Cookie利用なし。
・firebase-js-sdk導入したら勝手に使ってる？←使ってなかった
✅ブルートフォース対策 ←GAEdefault + firewallのwhitelist
✅依存関係の脆弱性解決 ←ツールにて確認。
・yarn auditを実行。脆弱性なし。npmでのauditやり方と対処記事。

毎日npm auditを実行して脆弱性対応する - Qiita

・snykを実行。脆弱性なし。日本語情報少ねぇ。

✓ Tested 354 dependencies for known issues, no vulnerable paths found.

Getting started with the CLI

Node.jsセキュリティ

項目多くて辛い。気になるところだけやる…。

We're under attack! 23 Node.js security best practices

✅Eslint入れろ　←導入した。
・とりあえずデフォルト設定を利用。
未使用変数の削除と異常時処理の一部の不具合修正できた。今の設定。

module.exports = {
   "env": {
       "node": true,
       "mocha": true,
       "browser": true,
       "es6": true
   },
   "extends": "eslint:recommended",
   "globals": {
       "Atomics": "readonly",
       "SharedArrayBuffer": "readonly"
   },
   "parserOptions": {
       "ecmaVersion": 2018,
       "sourceType": "module"
   },
   "rules": {
   }
};

・Expressのnextは必ず警告される…行を無視するコメントで対応する。

// eslint-disable-next-line no-unused-vars

Default error handler, next(), and ESLint's no unused var rule 揃 Issue #78 揃 expressjs/generator

✅プロセスのエラーをキャッチしろ。クラッシュさせるな。
・express-async-handlerで非同期エンドポイントはエラーをキャッチする。

徳丸本

真面目に取り組むと凄い年月かかる！ざっくりと読んだ。

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践

✅ HTTPレスポンスのコンテンツヘッダは必ず設定する ←ajax周り対応。
✅ツールによる脆弱性診断← GCPconsoleからGAE security checkを行う
・書籍で紹介されてたのはOWASP ZAP

徳丸さんの最近バズった記事。

架空企業「オニギリペイ」に学ぶ、セキュリティインシデント対策

セキュリティ対応はすんげー大変…ってことだ😇地獄かな

本で紹介されてた参考資料
IPAの資料(ちと古い)

安全なウェブサイトの作り方：IPA 独立行政法人 情報処理推進機構

まとめ

ServiceWorkerのセッション管理系が手作り感あるので一番心配…。
(次点は謎の失敗が多いfirebaseui)
IPAの資料にも書いてあったが、セッション周りを自分で実装してるとセキュリティホールになりやすいらしい。

備考 (脆弱性有無の判定基準詳細、その他）
セッション ID のパラメータ名等で、言語・ミドルウェアのセッション管理
機構を使用しているかを判断します(※注 9)。
判断がつかない場合には、"手作りの疑いあり"として報告します。

一応根幹はfirebaseAuthを利用しているので完全に手作りではない！
と主張して今日は寝よう…。