安全なWebサイト構築の必須知識！ “発注前”から始めるべきセキュリティ対策のポイント

「Webサイトが改ざんされてしまった」「運営中のECサイトではクレジットカード番号を保存していないのに、第三者へ漏えいしてしまった」――Webサイトを攻撃者からどう守るかは、デジタルマーケティングの推進と同じくらい重要だ。

EGセキュアソリューションズの徳丸氏が「Web担当者Forum ミーティング 2024 秋」に登壇し、専門家の立場からWebサイトの最新セキュリティ動向を解説した。

ゼロデイ攻撃ならぬ「ワンデイ攻撃」が増加。脆弱性を巡る最近の事情

徳丸氏は1985年にソフトウェア開発者としてキャリアをスタート。2008年にはWebアプリケーションセキュリティを専門分野とするHASHコンサルティング株式会社を自ら起業。同社はその後、各種ITサービスを手がけるイー・ガーディアンの子会社になり、現在の社名へ変更されている。

一般ユーザーはなかなか実感しづらいが、Webサイトを巡るセキュリティ事故は、日々当たり前のように発生している。ランサムウェアによる攻撃・被害などが代表的だ。こうしたWebサイトを狙った攻撃の多くは、サイト構築に用いられているソフトウェアの「脆弱性」を悪用するケースが大半を占める。たとえば、CMS（コンテンツ管理システム）や、その関連プラグインに脆弱性が発見されると、攻撃者はそれをねらう。

ある脆弱性の情報が公表される前に、実際にその脆弱性を狙った攻撃が発生してしまうのが「ゼロデイ攻撃」です。ただ、ゼロデイ攻撃の数はそこまで多くありません。これまでであれば、脆弱性の発表から2～3カ月経った後、その脆弱性を利用した攻撃が確認されることがほとんど（徳丸氏）

だが近年は、脆弱性の発表から実際の攻撃発生までの間隔が短くなったという。2～3年前からは、ゼロデイ攻撃ならぬ「ワンデイ攻撃」という表現が多用されていると徳丸氏は説明する。脆弱性発表の翌日～数日後に攻撃が起こる、という意味合いだ。

ユニクロやシャープなど、国内企業・組織が受けた被害事例

Webサイトが攻撃を受けると、実際にどのようなことになるのだろうか。

被害事例①SQLインジェクション：メアド約5千件流出

2023年2月には、日本国内の研究機関において、データベース用サーバーから研究者のメールアドレス5527件分が流出した可能性があることが発表された。これには「SQLインジェクション」と呼ばれる、まさに脆弱性をねらう手法が用いられた。

被害事例②クロスサイトスクリプティング：フィッシングサイトなどへ誘導

2020年9月には、ユニクロのAndroid版アプリにおいて、「クロスサイトスクリプティング」の脆弱性が発見された。この手法は、脆弱性をついてWebサイトへ侵入し、仕掛けを施すことで、アクセスしてきた一般ユーザーを別のWebサイトへ誘導するというもの。なお本件では、事後の対策によって被害は発生しなかったとみられる。

被害事例③リスト型攻撃：25万人のWeb履歴書が流出

2023年にはエン・ジャパンの転職情報サイトで25万人のWeb履歴書が漏えいした。このケースは、外部で流出していたIDとパスワードを攻撃者が転用し、使い回しなどが理由で不正ログインされてしまう「リスト型攻撃」が原因とされる。これは脆弱性狙いとは事故の性質が異なる。

被害事例④Webサイトが改ざん、クレカ情報を含む個人情報が流出した可能性

直近では、シャープの公式オンラインストア｢COCORO STORE｣で個人情報が流出。2024年10月段階での発表によれば5836人分の個人情報が漏えいした。個人情報入力時や注文確定時に、第三者が情報を窃取できるようWebサイトが改ざんされていたという。

現代インターネット社会では、Webサイト攻撃で被害が出てしまった際の悪影響もまた大きい。攻撃されたシステムはほぼ例外なく稼働を停止せざるを得ず、ECなどを主力とする企業にとっては大打撃。株価の急落につながりやすい。事情説明、謝罪、臨時のクレーム対応なども求められる。また、社会的な評価の低下や風評被害につながるなど、事後対応後にも影響が残る可能性がある。

そもそも「脆弱性」とは？ バグとは何が違う？

Webサイト攻撃被害の直接的原因とも言える脆弱性とは、そもそも何なのだろうか。徳丸氏は、いわゆる「バグ」との対比でこう解説する。

たとえば、「ショッピングサイトでボタンを押したのに商品がカートに入らない」といった、できるはずのことができないのがバグです。対して脆弱性は、「ログインしたら他人のマイペーシが表示されてしまう」ようなケースなど、バグの中でも、できないはずのことができるものを指します（徳丸氏）

バグのないソフトウェアは存在しないとも言われる。よって脆弱性もバグの一種と捉えるなら、ソフトウェアと脆弱性の問題は不可分。ソフトウェアが高機能化・複雑化する中では、残念ながらそれが現実だと徳丸氏は説明する。

脆弱性については、対応の優先度付けの判断として分類するための「危険度」があることも知っておくべきという。脆弱性診断結果にて用いられる危険度分類の例としては、最も危険な「Critical（緊急）」を筆頭に、「High（重要）」「Medium（警告）」「Low（注意）」「Information（情報）」の5段階評価となっているケースがある。

全部の脆弱性に対処するのが理想です。ただ実際には予算の都合もありますので、脆弱性診断などを（業者に）依頼する際、「どの段階から対処すべきか？」という話になります。その場合は「Medium」以上への対応を薦めるケースが多いです（徳丸氏）

わずか10数分、SQLインジェクションによるCookie不正入手をデモ

ここで徳丸氏は、Webサイト攻撃の例を会場でデモンストレーションした。ECサイト構築サービス「EC-CUBE」上に、脆弱性がある状態のECサイトを検証目的で用意した。一般的な購入体験の中でECサイトに脆弱性があると、簡単にクレジットカード情報が盗まれてしまうことを説明していった。

サイト管理者と一般購入者は、ブラウザのCookie情報でユーザーを判定し、管理者には管理ページ、一般購入者にはECサイト（マイページ）を表示している。管理者のCookie情報が入手できれば、管理者として管理ページにログインし、攻撃用のプログラムを仕込めることになる。

今回は、データベース検索機能に脆弱性がある想定で、検証目的のECサイトを用意しており、攻撃者が検索システムにとある文字列を入力すると、ユーザー判別に用いるCookie情報がSQLインジェクションにより一覧できてしまったのだ。

攻撃者は、この一覧から管理者用Cookie情報をコピペして自分のブラウザにペーストしてしまえば、管理者になりすましてログインできてしまう。ファイルサーバーにも容易にアクセスできるため、画像をアップロードする程度の手間で、攻撃用実行プログラムをいとも簡単にECサイトに仕込めてしまった。

これ以降、一般ユーザーは当該サイトで個人情報やクレジットカード番号を入力して、注文確定ボタンを押すと、攻撃者が使用する通信監視ツールにクレジットカード情報が流れてしまうようになった。

サーバー上にクレジットカード情報を保存していなくとも、攻撃者に情報が漏れてしまう、極めて深刻な事態だが、ECサイト上の見た目はほぼ変化がない。

デモとしてECサイトに攻撃用プログラムを仕込むまでに要した時間はわずか10分程度。特殊な機材なども使わなかった。またECサイトのセキュリティとして、クレジットカード番号の非保持化は定番だが、今回の攻撃ではほとんど意味がない。有名なプラットフォーム上にECサイトが構築されていても、Webサイト側の脆弱性を放置すると、簡単に攻撃対象になってしまう。

ハッカーはだいぶ前にカード番号非保持化にも対応してしまっています。そしてカード番号は、有名企業から漏れたものかどうかで価値が変わったりしません。中小企業も標的となりますし、ECサイト以外は対策しなくてよいという話でもありません（徳丸氏）

発注前のセキュリティ仕様策定が重要！ 後から変更するのは大変

Webサイトへの攻撃を防ぐために、担当者は何ができるのだろうか。

発注前にセキュリティ要件を含める

徳丸氏によれば、サイト開発をする前の段階から、意識を切り替えるべきという。

サイトを作る前に、セキュリティの要件を決めます。ただ（強固に対策しようとすれば、その分）お金がかかります。サイト開発にまつわるすべての予算からどれくらいセキュリティにかけるのが。それが大事な視点です（徳丸氏）

セキュリティ業界では近年「シフトレフト（Shift Left）」という概念が注目されている。開発過程のうち、より上流にあたる段階からセキュリティ対策要件を盛り込むということだ。

これは建物の工事で考えるとわかりやすい。これから建てるビルにどれくらいの耐震性をもたせるかは、設計の前段階で決めておかなければ、コストや納期、すべてに影響が出る。つまり発注主がどの程度の耐震性を持たせるのかを決めて、発注しなければならない。

また、コストの観点からも、すでに受注が決まっている開発先に対し、後からセキュリティの追加対策を求めても、この段階では入札などの競争原理が働かないため、価格交渉で不利になりやすい。

発注時には、発注者がセキュリティ要件をRFP（Request For Proposal：提案依頼書）にまとめる。精緻であるべきだが、具体的な仕様・機能をゼロから積み上げていくのは専門家でなければ困難だ。たとえばECサイトを構築するなら、日本クレジットが策定する「クレジットカード・セキュリティガイドライン」を参照するケースも多いという。

受注側はRFPを受け、具体的な見積もりを出し、RFPに則って開発する。ただしベンダーであってもセキュリティに詳しいとは限らないので、納品に近い段階では、第三者を介在させてセキュリティ診断・脆弱性診断を行うのが通例だ。

（非常に重要なフェーズだが）アプリがほぼ完成し、すぐにも公開したいというタイミングで診断を行う事になります。慌ただしい時期ですが、診断には2週間かかることもある。業者も忙しいので『明日診断して』というのも無理。計画的に実施してほしい（徳丸氏）

なお脆弱性への対応は、法律要件にもなってきている。たとえば、クレジットカード決済環境を整備するための割賦販売法においては、クレジットカード・セキュリティガイドラインのように業界の定めるガイドラインへの準拠が要請されている。セキュリティ対策は「やったほうがいい」から「やらなければ法律違反」の領域に入ってきた。法対応強化の傾向は加速するだろうと徳丸氏は予測する。

優良ベンダー選びのコツは○○を見せてもらうこと

どんなに発注を頑張っても、ダメなベンダーはセキュリティ的にダメなモノしか作れない──。徳丸氏はそう厳しく指摘する。よってベンダー選びには慎重さが求められるが、予算の問題も常につきまとう。受注側は選定にあたってベンダー側としっかり向き合い、細かな質問・確認を重ねていくべきという。

ベンダーに「セキュリティは大丈夫ですか？」と尋ねれば、「万全です」という答えが返ってくるのが普通です。それに対して「ならば機密保持契約を結ぶので、御社のセキュリティガイドラインを見せてください」とお願いするといいでしょう。私の経験上、必ず見せてくれるはずです。そのガイドラインが薄っぺらだったり、どこかの会社のコピペだったりしたら、それは良いベンダーとは言えないでしょう（徳丸氏）

脆弱性修正のためのバージョンアップ作業や、パッチ適用なども含めた保守契約についても、発注前の確認が欠かせない。

そして実際に攻撃を受けてしまった、つまり「インシデント」が発生したときにどうするかも検討課題となってくる。一般的に、現場のWeb担当者は緊急対応の知識を持たない。どんな連絡体制を作っておくかが肝心だ。

仮に、サイト停止を判断できるのが部長クラスの人物だったとして、どの程度のインシデントであれば昼夜構わず連絡していいのか。あるいは非常時はそうした権限を越えて現場が判断していいのか。非常時でも担当者が迷うことなく、ルールに沿って行動できるのが理想だ。

サイト閉鎖後も気を抜かず。「主体性を持って」

もし、サイト閉鎖（サービス終了）に至っても、それですべてが終了する訳ではない。情報漏えいがのちに発覚するケースは往々にしてあるため、ログの保存やデータのバックアップは必須。利用していたサイト用ドメインを廃棄するケースでは、別の業者が再取得して不正サイトやポルノサイトなどを公開する可能性についても、考慮しなければならない。

そして脆弱性対策はもちろんだが、アカウントやパスワードの管理が疎かでは、そこがセキュリティ上の穴になる。そのため、関係者全員で認識を共有するための運用ルールの作成やアカウントの払い出し先を管理することが重要だ。また、パスワードを強固にした上で使い回しは避け、近年ブラウザーへの搭載が広がっているパスワード管理機能なども使うべきと徳丸氏は助言した。

最後に徳丸氏は「（セキュリティに優れたサイトの構築を）ベンダーが勝手にやってくれることはない」と警告。発注側が主体性を持って、ベンダーにしっかりしたサイトを“作らせる”という心構えで事に臨むべきと唱え、講演を終えた。