多くの経営者は、公式サイトに対して「開ける、見られる、電話番号を残せる」だけで十分だと考えています。公開日の検収が終わると、その後何年も誰も管理画面にログインして確認しません。
ある日、顧客から「御社のサイトを開くとカジノページに飛ぶ」と電話が来たり、データベースがダークウェブで販売されているというメールを受け取ったりして、初めて問題がずっと前から存在していたことに気づきます。
ウェブサイトセキュリティテストは大企業のための贅沢品ではありません。あなたのサイトに管理画面、フォーム、顧客データがあるなら、定期的な健康診断を受ける価値があります。
まず理解しよう：セキュリティテストは何をテストするのか
多くの人は、セキュリティテストとは「脆弱性をスキャンする」ことだと思っています。スキャナーを入れて一通り実行し、レポートを出せば終わりだと。しかし、それは半分しかやっていません。
完全なセキュリティテストは、少なくとも3つの層をカバーする必要があります：
第一層は設定と露出面です。 管理画面のログインアドレスが /admin のようなデフォルトパスになっていないか、テスト環境を閉じ忘れて公衆インターネットに直接露出していないか、データベースポートが外部に開放されていないか、バックアップファイルがウェブサイトのルートディレクトリに置かれて直接ダウンロードできないか。こうした問題は高度な技術を必要としませんが、事故が起きる確率が最も高いです。
第二層は一般的なWeb脆弱性です。 SQLインジェクション、権限昇格、ファイルアップロード、XSS、弱いパスワード。特に管理システムでは、一般アカウントがURLパラメータを変更するだけで他人の注文を見られるかどうか。これは多くの企業サイト開発時に全く考慮されていない部分です。
第三層はビジネスロジックです。 例えば予約ミニアプリで、フロントエンドの制限を回避して重複送信できないか、クーポンAPIがスクリプトで不正利用されないか、キャプチャが形だけになっていないか。こうした問題はスキャナーでは検出できず、手動テストしかありません。
3層すべてを一通り確認して初めて、自分がどの位置に立っているかを知ることができます。
なぜ「定期」でなければならず、「一度だけ」ではいけないのか
セキュリティテストはワクチンではありません。一度打てば終身免疫というわけにはいきません。むしろ健康診断に近く、今年正常だからといって来年も正常とは限りません。
理由は非常に現実的です：
システムは変化しています。 あなたの企業サイトは、今四半期にオンライン客服を追加し、来四半期に決済を接続し、年末にはCMSバージョンを変更するかもしれません。コードを変更するたびに、新しい穴が生まれる可能性があります。前回テスト時に問題がなかったのは、その機能がまだ存在しなかったからです。
コンポーネントは変化しています。 サイトで使用しているフレームワーク、プラグイン、サードパーティSDKは、ベンダーが継続的に新しい脆弱性を開示します。あなたは何もしていなくても、依存しているものが変わっています。
攻撃手法は変化しています。 自動化ツールは毎日全网のIPをスキャンし、半年間更新されていないサイトを探しています。攻撃者はあなたを選ぶのではなく、侵入しやすいサイトを選ぶのです。
実用的なペースは：基幹業務システムは半年に一度、一般的な企業サイトは少なくとも年に一度、大規模なリニューアルや新機能追加のたびに追加で一度。 決済、ユーザー登録、管理システムがある場合は半年に近づけましょう。
具体的なシナリオ：公式サイトリニューアル後に見落とされたこと
よくある例を挙げます。
ある企業が公式サイトをリニューアルし、ビジュアルをアップグレードし、製品フィルターを追加し、「お問い合わせ」フォームを追加し、ついでに管理画面を旧システムから新しいCMSに移行しました。開発期間は1ヶ月、公開検収ではページ表示とフォーム送信が正常にできるかを確認し、問題なしとして承認しました。
3ヶ月後、問題が発覚しました：新しい管理画面の管理者ログインには失敗回数制限もキャプチャもありませんでした。つまり、スクリプトで無限にパスワードを試行できる状態でした。同時に、お問い合わせフォームのAPIにはレート制限がなく、数万件のスパムデータを送り込まれ、データベースが応答遅延を起こすほど圧迫されました。
この2つの問題は、基本的なセキュリティテストで10分以内に発見できます。しかし、リニューアルプロセスの中で誰もこの部分を担当していませんでした。
これが、セキュリティテストを公開プロセスに組み込むべき理由であり、事故が起きてから補うべきではない理由です。ウェブサイト開発の納品チェックリストには、「セキュリティテスト合格」という項目があるべきです。
自分でテストするか外部に依頼するか、どう分けるか
すべてを外注する必要はありません。基本的な動作はチーム自身でできます：
- 管理画面で強力なパスワードを強制し、二段階認証を有効にする
- 不要なテスト環境、サンプルページ、デフォルトアカウントを閉じる
- バックアップファイルとログディレクトリが公衆インターネットからアクセスできないか確認する
- サードパーティコンポーネントに既知の脆弱性がないか定期的に確認する
これらは運用規律に属し、コストが低く効果が高いので、やらない理由はありません。
しかし、権限昇格、インジェクション、ロジックバイパス、リバーステストなど、攻撃経路を構築する必要がある部分は、通常専門家が行う必要があります。理由は自社の人間ができないからではなく、開発者とテスターは自社システムに詳しすぎて、「正常な経路」をたどりやすく、攻撃者がどこで曲がるかを思いつかないからです。
どのような場合に MIC Studio に相談すべきか
以下の条件に当てはまる場合、私たちの介入を検討できます：
第一に、ウェブサイトやミニアプリが公開されたばかり、または大規模なリニューアルが完了したばかりで、独立した視点で一通り確認し、明らかな穴がないことを確認する必要がある場合。
第二に、管理システムが複数ロールの権限に関わる場合、例えば代理店、従業員、管理者の階層があり、権限昇格の問題が心配な場合。
第三に、マルウェアを仕込まれた、スパムデータを送り込まれた、脅迫メールを受け取ったことがあり、まず問題を特定してから強化を検討する必要がある場合。
第四に、Appやスクリプト系の業務があり、APIレベルのリバーステストを行い、データ転送と認証が信頼できるか確認する必要がある場合。
MIC Studio は企業ウェブサイト開発、ミニアプリ開発、App開発 の際に、セキュリティテストを納品プロセスの一部として組み込みます。また、単独のウェブサイトセキュリティテスト依頼も受け付けています。テスト後は、理解できないスキャンレポートではなく、実行可能な修正チェックリストを提供します。
すぐに実行できる3つの提案
第一に、「セキュリティテスト」を次回のリニューアル検収チェックリストに追加しましょう。 来年を待つ必要はなく、次にコードを触るときに組み込めば、コストは最小です。
第二に、今日すぐに3つのことを確認しましょう： 管理画面のログインアドレスが推測可能か、テスト環境が閉じられているか、ウェブサイトのルートディレクトリに不審なファイルがないか。30分で確認できます。
第三に、基幹システムに固定の再テスト日時を設定しましょう。 カレンダーに書き込み、半年に一度、時期が来たら実行し、思い出すことに頼らないようにしましょう。
セキュリティというものは、問題が起きていないときは無駄なお金に見えますが、問題が起きたときに最も安い出費だったと気づくものです。