TomoMemo.dev顧客へ提供するプロダクトはもちろん、顧客に直接手を触れられるものでなくても、以下の理由から対策しておくべき。（と思ったのでメモしておく）
SQL Injectionとは、ウェブアプリケーションの脆弱性を突く攻撃手法。
入力フォームやURLパラメータなどから不正なSQLをデータベースに送り込み、本来意図しないデータの盗み出し・改ざん・削除などを行うこと。
ちなみに、SQLとはStructured Query Languageの略、構造化問い合わせ言語。
内部の脅威 / Insider Threat
- 開発者や運用担当者、あるいは権限を奪われた第三者により、不正にデータを読み書きされるリスクがある
- バッチ処理や定期ジョブは高権限で動くことが多い
- 攻撃を受けると被害は甚大
誤操作や設定ミスの予防
- 環境変数やコマンドライン引数、様々な経路でパラメータが渡るバッチ処理は想定外の文字列が入り込みやすい
- 今回のケースはAWS CDKで構築しているStep Functions
- 自動化された運用中に、誰かの手違いで想定外の文字列を渡してしまい、取り返しのつかない事故を起こすことも考えられる
将来的な再利用・拡張を見据えること
- 他チームへの公開を検討するとき、脆弱性が残っていると大きな手戻りになる
- 内部専用だとしても、あとから全社的改修コストが跳ね上がる
コンプライアンス・ログ監査要件
- 社内でも機密データ（個人情報、経営数字など）を扱う場合、J-SOX／内部統制の観点で不正アクセス防止策が求められる
- パラメータ化クエリ・エスケープ処理は、こうした監査要件をクリアする第一歩となる
手を抜くとどうなるか？3つの考えられること
- データ改ざん
- 売上実績や在庫管理データが書き換えられ、経営判断を誤らせるきっかけになる
- 業務停止
- DROPやTRUNCATEによるテーブル削除やロックでバッチ処理そのものが止まる
- 情報漏洩
- 開発中の新機能情報や顧客データが外部に流出、社内プロジェクトに致命傷を負う
最低限すべき対策
- パラメータ化クエリの徹底
- 入力値のバリデーション
- DBユーザーの権限を「読み取りのみ」「特定テーブルのみ」など最小限に制限
- 定期的なコードレビュー
- 自動脆弱性スキャンの実施