製品進化とマネジメント風景第134話 WEBアプリのセキュリティマネジメント

2025.06.23 コラム

当社のホームページは、一度、ハッカーに侵入されました。原因は、組み見込んでいたプラグインアプリの脆弱性を放置してしまったためでした。そのプラグインだけは自動アップデートできないものであり、その放置が問題を引き起こしました。

この件については既に個人情報保護委員会にも報告済であり、その後、何の連絡もないので一応、収まったのだと認識しています。対策は、自動アップデートできないプラグインの定期的な監視であり、これを実行しています。

一般的にWebアプリについては、新たな脆弱性が見つかるとすぐに脆弱性を解消すべく突貫工事を行いバージョンアップされます。バージョンアップ後のアプリは、少なくとも対象の脆弱性は解消しているので、最新版に変えることは原則として有効な対策となります。

情報セキュリティ事故を契機として、当社は、セキュリティをさらに強化する活動をしてきました。活動の中で分かったことは、世の中の殆どのWEBアプリケーションには何らかの脆弱性があるということでした。

驚かされたのは、GAFAのようなIT企業のホームページやMS365のような世界中で使われているWEBアプリケーションであっても、まだまだ多くの脆弱性があるということでした。

実際、MS365については少なくも週に一度は新たなセキュリティ強化の対策の導入が行われ、そのアップデート情報の連絡が入ってきます。よくよく考えると、我々のセキュリティは常に綱渡り状態にあるようなのです。

とは言え、何とか被害が抑制されているのは、ホワイトハッカーが悪意のあるハッカーよりも先に脆弱性を見つけ出し、それを企業等に連絡してくれるおかげです。感謝するとともに、その知見を活用することが彼らの努力に報いることだと考えています。

読者の中には、「なぜ、次々と新たな脆弱性が出てくるのか？」と疑問に思う人もいるでしょう。その理由を一言でいえば、WEBアプリを作る言語の中に、本質的な脆弱性の源泉があるからです。

本コラムでは、WEBアプリにおける代表的な脆弱性とその本質的な原因およびその対策を紹介していきます。

今日の企業は高度に分業化されているので、この手の話は「IT専門部門に任せておけば良い」と考えられがちです。しかし、経営者やプロジェクトマネジャであっても、その本質を理解していないと、仮に事業とセキュリティを両立できない方向に進んでいても、その事実に気付くことすら出来ません。

大事な事は、情報セキュリティと事業の維持・成長の両立です。IT専門家でなくても、本質だけは掴んでおく必要があるということです。

ここからは、まず、ホームページにおける主要な脆弱性の事例を述べます。具体例としては、クロスサイトスクリプティング(XSS)、クロスサイトリクエストフォージェリ（CSRF)およびSQLインジェクションの３つを選びました。他にも名前の付いた脆弱性は色々ありますが、この３つは特に悪用例が多いと言われているので選択しました。

ホームページには、外部からの入力があるものとないものに分類することができます。上述した３つの脆弱性は外部からの入力がある場合に起こります。

ホームページには、外部から変更できるパラメータを表示する場所がいくつも含まれていますが、１つでもXSS脆弱性があると、cookieや個人情報を盗まれる、あるいはホームページの画面を書き換えられてしまう可能性があります。

ホームページの画面を書き換えられた時、それにすぐに気付ければ被害を最小限に抑えられますが、気付かないと、そのホームページにアクセスしてきた外部ユーザーにまで被害を広めてしまうことになります。

自社だけの被害に限定できれば自己責任の範疇ですが、ホームページにアクセスしようとした他者に対してまで被害を広めることになると、社会的な責任を負わなければなりません。

2番目のCSRFですが、悪意のあるホームページを閲覧しただけで、例えば、部品を勝手に購入される、メールアドレスやパスワードを変更される、見知らぬ口座に送金処理をしてしまうなどのトラブルが起こる場合があります。

通常、ブラウザは「同一オリジンポリシー」により、外部からコマンドを入力してもそれを受け付けません。そのようにしてセキュリティを保っているわけです。しかし、ホームページを書き換えられてしまうと、ブラウザの「同一オリジンポリシー」が適用されなくなるため、悪意のある相手が決めたルールの支配を受けることになってしまいます。そのため、その場から逃げようとしてコマンドを入力しても受けつけられなくなるような状況に陥ります。

よくあるケースは、警告音が鳴り響いて止まらなくなり、「警告音を止めるにはこのボタンを押せ」といった形での誘導が行われます。もし、その誘導に従ってしまうとどんどん深みに嵌まっていくことになるのです。

3番目のSQLインジェクションは企業のデータベースを盗む、あるいは改ざんすることを目的としています。企業にとっては最もダメージが大きい攻撃の１つと言えるでしょう。

ここまで３つの事例を挙げましたがその根源は同じです。ホームページの入力部分に、ある種のコマンドが入力されると、それによってホームページが書き換えられるようになってしまうことです。

ある種のコマンドとは何でしょうか？　分かりやすい例は「<, >, &, ', ''」といった記号です。これらは特定のコマンドとして認識されてしまいます。より厄介な場合として、記号ではなく、ある特定の英数字の組合せがコマンドとして認識されてしまう場合もあります。

ホームページはHTML言語やPHP言語で書かれています。HTML言語は、JavaScriptに代表される実行可能なスクリプト言語を容易に組み込むことができます。それゆえ、動きのある魅力的なホームページを作ることが可能になるのですが、スクリプト言語には強力な実行能力が付与されているため、悪用される源になるということです。PHP言語も一種のスクリプト言語であり、同様のリスクを内在しています。

では、外部からの入力により、ホームページを書き換えられないようにするにはどうすれば良いのでしょうか？　単純にいえば、上記の記号や特定の英数字の組合せをコマンドとして認識させないように、入力データを洗浄処理すればよいのです。

画像が入力される場合も注意が必要です。画像データは、基本、英数字や記号によるコマンドの集合体であり、その一部に悪意のあるコマンドが仕込まれている場合があるからです。ブラウザが検知してくれる場合もありますが、検知してくれない場合もありますから、WEB上に公開されている画像をむやみにダウンロードするのは危険かもしれません。

企業のホームページには、殆どの場合、問い合わせ等の入力フォームがあるはずです。当社のホームページにも、セミナーやコンサルティングの申し込みをするフォームがあります。入力の洗浄を適切に実施しているかどうか、確認しておく必要があります。プラグインを使っている場合には、定期的に脆弱性チェックが必須です。

さて、ここからはWEBアプリの利便性を高める認可プロセス（OAuth)における脆弱性の話に移ります。OAuthはオープンなプロトコルであり、Web、モバイル、デスクトップのアプリケーションのセキュアな標準的な認可プロセスです。

OAuthを使えば、ユーザーはWebサイト上で、ユーザー名やパスワードを作成する必要なしでアカウントを作成し、ログインできるようになります。利便性の高い仕組みですが、開発者の実装ミスにより脆弱性が発生するという欠点があります。

実際のビジネスにおいては、例えば、生産性向上のために、デスクトップで作成したプログラムをクラウド上のアプリと連携させて運用するというケースがあります。以下でOAuthのプロセスを概観しますが、イメージが湧きやすいように、デスクトップアプリとMS365の連携を例として説明します。

まず、OAuthでログインしようとしているユーザー（あなた）がいますが、これは「リソースオーナー」と呼ばれます。あなたはクラウド上にあるMS365の利用権をもっています。この利用権を「リソースサーバー」と呼びます。

そして、今、自分が作成したデスクトップアプリをMS365上にあるWord、 Excel、Outlook、Copilot等と連携して運用したいと考えています。このデスクトップアプリは「クライアント」と呼ばれ、リソースオーナーがリソースサーバーにアクセスさせたいサードパーティーアプリであることを意味します。

リソースオーナー（あなた）は、まず、MS365上に、作成したデスクトップアプリを登録する必要があります。登録する際、そのアプリにはクライアントIDが発行され、その後、証明書に相当するクライアントシークレットが発行されます。クライアントシークレットは画面が変われば消えてしまうので、必ず控えを取る必要があります。

このような準備をした上で、リソースオーナーのクライアント（デスクトップアプリ）が、リソースサーバーであるMS365から認可を受けるためのプロセスを行います。この際に、クライアントIDとクライアントシークレットが必要となります。認可されると、アクセストークンが発行されます。

アクセストークンは平文で書かれており、使用する範囲、権限、使用期限および証明書としての秘密鍵がセットで記載されています。デスクトップアプリにこのアクセストークンを読み込めば、クラウド上のMS365のリソースを使って色々な作業を行うことが可能となります。

かなり面倒なプロセスですがセキュリティが高いので、当社がメルマガを送信する時にこのプロセスで使っています。とは言え、マイクロソフトのこのプロセスについても、10年くらい前に一度、深刻な脆弱性が見つかりました。

具体的には、アクセストークンを発行するプロセスにおいて、入力情報の洗浄が不十分であったため、ある種のコマンドを入力すると、他者がユーザーになりすますことができてしまったのです。

上記の脆弱性はすぐに修正されましたが、最近ではAIの能力が向上し、デスクトップからクラウド上のAIを繋いで仕事をする機会が増えていると思います。その際は上記のような認可プロセスを経る必要がありますが、仮に、リソースサーバー側の、つまりAIを提供する側の設定にミスがあると、アクセストークンを盗まれる可能性があるということです。

アクセストークンが盗まれるとなりすましをされるので、これまでどんな調査や質問をしてきたか、どんな非公開データで学習をしてきたか等の情報が漏洩するとともに、自社データで学習したＡＩを勝手に使われることにもなります。

リソースサーバー側のミスはユーザーには分からないので、この種のリスクを低減するためにできることは、アクセストークンを発行する際に、使用する範囲、権限、期限をできるだけ狭く、しかも短い期間に設定することだと言えましょう。

生産性向上、利便性向上のためにクラウドを使う時代になりましたが、自社のミスだけでなく、他社のミスによっても情報セキュリティ事故やノウハウ流出が発生しうるため、専門家任せにせず、自分が使うシステムを良く理解してから使う配慮が必要だと考えます。