こんにちは、tosumaです。
本日、サイトへの悪意のあるアクセスを確認したため調査しました。
1. 結論
まず、リクエストページでのSQLインジェクションの攻撃試行を確認できました。
現時点の調査範囲では、SQLインジェクションが実際に成功し、DBの情報漏えい・改ざん・削除などの被害が発生した証跡は確認できていません。
実害としては攻撃者が送信したSQLインジェクション用ペイロード文字列が、リクエスト情報格納テーブルにその形式のまま保存されリクエスト一覧に不正データとして蓄積されたのみです。
2. 調査対象
・リクエストフォーム送信機能
・リクエスト一覧表示機能
・リクエスト保存テーブル機能
・アクセスログ記録機能
・関連DB内の登録状況
3. 実装内容の再チェック
リクエスト送信は PDO::prepare() とバインド変数で テーブルへINSERT、その他はprepareやhtmlspecialchars() を使用。
そのため、少なくとも今回のリクエスト登録処理では、送信値がそのままSQL文として実行される実装にはなっていない事を改めて確認。
保存済み文字列が一覧表示時にスクリプト実行される経路も、現状コード上は見当たらず。
攻撃文字列はテキストデータとして保存される構造となっているが保存時にSQL文として再解釈されるような実装ではない。
4. 実データの確認
登録データを確認し、不審な文字列の有無、件数、時刻帯、送信元傾向を調査、通常の問い合わせではなく、自動化されたSQLインジェクションスキャンと判断できるもの。
直近の他日付分では、同種の不審投稿は確認されず、今回の集中発生は 2026年4月1日に限って顕著、その他のログも照会し、送信経路としてリクエストフォームが使われた可能性が高い。
しかし、記録方式から見て、SQLが直接実行された証跡は無い。
5. 総括
上記理由により、アプリ実装とDB保存内容の両面から見て、現時点では「攻撃試行はあったが、成功被害は確認されていない」という結論付けをしています。
大前提として、管理者(私)が個人情報アレルギーのため仮にデータを参照されたとしてもFFRKの公式Wikiもしくはエントリーされている方がX(旧Twitter)に公開されている情報しか保持していないため実害は基本的にはありません。
それでも対策を取り不正なアクセスは防ぐ姿勢は持ちます。（情報操作だけでなく、サイトが正常に稼働できない等も防ぐため）
それでは皆さん、引き続き良きレコパライフを！
お読み頂き有難うございました。
※よければもう1本 関連記事をお読み頂けると幸いです
