Shikata Ga Nai

Private? There is no such things.

攻撃者視点”を理解する①

セキュリティ対策

Hello there, ('ω')ノ

📘 セクション1：Webアプリ

攻撃者は 「外から見える部分」 を起点に弱点を探します。
ここでは、企業のWebアプリが“最初に狙われるポイント”を、
非エンジニアの方にもわかるように丁寧に解説します。

🔍 1-1. 入力点のリスク

■ 入力点とは？

ユーザがアプリに何かを送る場所のことです。

例：

  • ログインフォーム（ID / パスワード入力欄）
  • 検索フォーム
  • 問い合わせフォーム
  • URLの「?」以降のパラメータ
  • Cookie / LocalStorage
  • APIに送るリクエスト

■ なぜ危険なのか？

入力できる場所＝攻撃者が“試せる”場所。

つまり

「入力できる場所はすべて、外部から触れる“玄関口”」

となり、入力の扱いに不備があると… - 不正ログイン - 予期しない操作の実行 - 情報漏洩 などにつながることがあります。

■ 防御側がまずすべきこと

  • どこに入力があるかを一覧化する（最重要）
  • 想定外のデータが入ったらどうなるか、動作を確認
  • 入力値チェック（形式・長さ・型など）

🌐 1-2. 公開URLのリスク

■ 公開URLとは？

外部からアクセスできる画面・機能のURL全てです。

攻撃者がすることは非常にシンプルで…

「全部のページにアクセスして、どんな機能があるか確認する」

という作業です。

■ よくある危険パターン

  • 意図していない古いページが残っている
  • 管理画面のURLが推測可能
  • テスト用の機能が本番に残っている
  • ログインしなくてもアクセスできるAPIがある

■ 防御側がすべきこと

  • サイトマップ（URL一覧）を作成する
  • 意図して公開しているURL以外が存在しないか確認
  • 管理用URLは推測困難＋認証必須化

❗ 1-3. エラーメッセージのリスク

■ 何が危険なのか？

エラーメッセージに大量の内部情報が含まれるケースがあります。

例：

SQLException: syntax error near "id=3"
Database: PostgreSQL 12.3

これ、攻撃者にとっては宝の山です：

  • 使っているDBの種類
  • バージョン
  • エラーの原因
  • アプリの内部構造

本来、外部に絶対出すべき情報ではありません。

■ 防御側がすべきこと

  • 本番環境では詳細エラーを表示しない
  • エラーページを共通化し、“内部情報ゼロ”にする
  • ただしエラー内容は「内部ログには残す」こと

🧭 1-4. ヘッダ情報から何が読み取られるか

Webアプリはブラウザに表示される前に
「HTTPレスポンスヘッダ」という情報を返します。

例：

Server: nginx/1.18.0
X-Powered-By: PHP/7.4.3

■ 攻撃者が読み取るポイント

  • サーバ種別（nginx / Apache など）
  • バージョン（古いほど狙われやすい）
  • ミドルウェア（PHP / Node.js など）

これも“攻撃のヒント”になります。

■ 防御側がすべきこと

  • ServerヘッダやX-Powered-Byを非表示にする（推奨設定）
  • 不要な情報が出ていないかチェック

👻 1-5. 「公開しているつもりのない機能」が狙われる理由

攻撃者は、“あえて想定外のページや機能”を探します。

それは：

他の企業でもよく“残しがち”だから。

よくある例：

  • 古い管理画面のURL（/admin_oldなど）
  • テスト用のAPI（/debug /test/）
  • 一部のユーザだけに使わせる内部ページ
  • ログイン不要のAPIが誤って公開されている

攻撃者は 「URLを変えてみる」 だけで簡単に見つけることがあります。

■ 防御側がすべきこと

  • 公開URL一覧を正しくつくる
  • 古い機能は削除 or 完全遮断
  • テスト環境は本番と分離
  • 管理画面は必ず認証＋IP制限

🧩 1-6. Webアプリの“最初の可視化チェックリスト”

（担当者レベルで今すぐできる）

✔ 公開URLの洗い出し

  • 公開しているページを一覧化
  • 想定外のURLが存在しないか

✔ 入力フォームの確認

  • どこに入力できるかを把握
  • 入力値がおかしい時の動作を確認

✔ エラーメッセージの確認

  • ユーザに詳細エラーが出ていないか

✔ レスポンスヘッダの確認

  • Server: や X-Powered-By: が漏れていないか
    （例：curl -I https://自社サイトで確認可）

✔ 古い機能の削除

  • テスト用ページ
  • 旧管理画面
  • 使っていないAPI

🎯 最後に：Webアプリの防御は「把握 = 対策」

Webアプリの攻撃は複雑に見えますが、
実は“見えるところをチェックするだけ”でも大きく安全性が変わります。

  • 入力点
  • 公開URL
  • エラー表示
  • レスポンスヘッダ
  • 使われていない機能の残骸

これらの「外から見える部分」を正しく把握すると、
攻撃者が利用できる入口は大幅に減ります。

Best regards, (^^ゞ