あなたのウェブサイト、ミニプログラム、または App が外部にサービスを提供している限り、必ずスキャンされ、探られ、攻撃されます。違いは発見されるかどうかだけです。多くのチームは機能開発とリリース速度に全力を注ぎ、セキュリティテストを後回しにした結果、1つの権限昇格インターフェースや1つのアップロードポイントでシステム全体が陥落してしまいます。MIC Studio は長期的なセキュリティテストとリバースエンジニアリングテストサービスの中で、同じ法則を繰り返し見てきました。本当にシステムを突破するのは、高度な技術ではなく、見落とされがちないくつかの古い問題であることが多いのです。この記事では、ウェブサイトセキュリティテストで最も一般的な脆弱性を徹底的に解説し、そのまま実践できる強化提案を提示します。
一、まずセキュリティテストの目標と境界を明確にする
セキュリティテストは、スキャナーを1セット買って1回実行すれば終わりではありません。それは3つの問いに答える必要があります。攻撃者はどの入口から侵入できるのか？侵入後にどれだけのものを取得できるのか？取得後にどれだけの被害を与えられるのか？
テスト方式別に分けると、通常3つの種類があります：
- ブラックボックステスト：完全に外部攻撃者を模擬し、ソースコードやアカウントを掌握せず、最も実際の攻撃シナリオに近い；
- ホワイトボックステスト：ソースコード監査と組み合わせ、ブラックボックスでは発見できない深層のロジック問題を発見できる；
- グレーボックステスト：一部のアカウントやインターフェースドキュメントを取得し、効率が最も高く、頻繁にイテレーションするプロジェクトに適している。
大多数の中小規模プロジェクトにとっては、インターフェース層と権限層を優先的にテストするのが最もコストパフォーマンスが高いです。この2つは問題が最も頻繁に発生し、結果も最も深刻だからです——データ漏洩、権限昇格操作、バックエンド乗っ取りは、基本的にここから始まります。
二、SQLインジェクション：古い問題でありながら、依然として最大の脅威
SQLインジェクションは20年以上存在していますが、今なお各種脆弱性ランキングの常連です。理由は簡単です。1箇所でも SQL が文字列連結で作られていれば、悪用される可能性があります。
典型的なシナリオ：
- ログインインターフェースが文字列連結でユーザーをクエリし、`' or '1'='1` を入力するとパスワードを直接バイパス；
- リストクエリのソートフィールドや検索条件が直接 SQL に連結され、エラー注入や時間ベースのブラインドインジェクションを引き起こす；
- 一部の古いシステムは ORM を使用しているが、ネイティブ SQL を連結しており、同様にリスクが存在する。
強化提案：
- パラメータ化クエリ（プリペアドステートメント）を全面的に使用し、コード規範レベルで文字列連結 SQL を禁止する；
- ソートフィールドやテーブル名などパラメータ化できない位置は、ホワイトリスト検証を使用し、事前設定値のみを許可する；
- データベースアカウントは最小権限の原則に従い、業務アカウントに DROP、FILE、GRANT などの高危険権限を与えない；
- 本番環境では詳細なエラー表示を無効にし、テーブル構造やデータベースバージョンの漏洩を防ぐ；
- WAF を補完的な防御線として導入するが、それを唯一の防御と見なさない。
三、XSS クロスサイトスクリプティング：最も長く潜伏するインジェクション
XSS の本質は、ユーザー入力がコードとして実行されることです。蓄積型 XSS は最も危険です。なぜなら、長期間ページ内に留まり、すべての訪問者に影響を与えるからです。
典型的なシナリオ：
- コメント欄、ニックネーム、個人署名が直接ページに出力される；
- リッチテキストエディタが `