認証と投稿がセキュリティリスクが高い

今週は、ぼくが趣味で開発しているブラウザゲームをネットで公開したのだけれど、そのときにアプリケーションセキュリティについて調べて、対策をいくつか実践した。

Webアプリケーションの脆弱性

脆弱性は「ぜいじゃくせい」と読む。コンピュータ関連でこの用語が出てきた場合は、セキュリティ上の弱点のことを意味する。セキュリティホールといったりもするらしい。他の文脈では、ぼくは脆弱性という言葉を聞いたことがないので、知らない方も多いかもしれない。

脆弱性のあるサイトは、次のようなリスクを抱えている。

• 個人情報やクレジットカード情報の漏出

• サービス運営の妨害

• マルウェアの拡散

• フィッシング攻撃

• 信頼性の損失

他にもたくさんあるだろうが、今回はそれらのリスクを網羅的に紹介することが目的ではないので割愛する。ようするに、Webにはいろいろなリスクが存在していて、すべてに対策を講じるのは大変そうだ、という雰囲気が伝わればそれでよい。

どんなアプリケーションが危険か

セキュリティリスクを大きく高めるものが次の2つだ。

• 認証（ログイン）機能

• コンテンツ投稿機能

ちなみに、今回ぼくが公開したブラウザゲームには、この2つの機能はどちらもない。そのため、冒頭に書いたようにセキュリティ対策も意外と短い時間で済んだ。

認証情報をめぐる攻防

攻撃方法やセキュリティ対策の記事を読んでいると、メールアドレスやパスワード、セッションIDなどの認証情報に関する話がほとんどであることに気づく。

認証というのは、つまりログインのことで、他人に認証情報を盗まれると、不正にアカウントを利用されて、本来秘密にしたい情報が漏洩したり、意図しない操作が実行されたりする。

アカウント登録をさせるサイトは、常にこのリスクがつきまとう。認証機能を持つということは、ユーザを他のユーザと区別する必要があるということだ。なぜ区別が必要かというと、自分以外には見せたくない情報を入力させたり、限られた人にだけ特定の操作を許可したりするためだ。

認証情報が盗まれるということは、すなわちユーザ同士を区別できなくなるということだ。個人を識別できないというだけで、これだけの被害につながるというのは、ネットの登場以前はあまり想像できなかったのではないかと思う。そして、顔を見るだけで個人を識別できる人間の能力は凄まじい。

コンテンツ投稿機能

コンテンツ投稿というのは、ファイルのアップロードだったり、コメントの書き込みだったりする。そういう機能を提供するとセキュリティリスクが高まるという認識は、あまり一般的でないように思う。

SQLインジェクションやクロスサイトスクリプティングなど、有名な脆弱性の多くは、実はユーザからの入力をプログラムが受け入れていることが原因である。想定していなかったファイルやコマンドが入力されて、サービス運用が妨害されたり、個人情報が盗まれたりする。

認証情報を盗むための手段として、投稿機能が使われることがある。

どんな対策を講じたのか

今回ぼくが公開したアプリケーションには、認証機能も投稿機能も今のところない。ユーザが個人情報を入力する場面はないし、ユーザの入力がプログラムの処理や表示に影響する場面もない。

このようなアプリケーションではセキュリティリスクは低い。Cookieやリファラーが外部のサイトに送信されないように設定したり、ページが外部のリソースを読み込まないように設定したり、その程度の対策しかすることがなかった。

もちろん、そんな単純なアプリケーションでも、攻撃されて被害が生じる可能性はゼロではない。サービスが停止したり、意図せずページが書き換えられて信頼を損失することもあるので、対策は必要ではある。しかし、盗まれて困るような資産はそもそも保持していないので、被害といってもしれている。

まとめ

認証機能とコンテンツ投稿機能がセキュリティリスクを上げる、と書いたが、「だから何なのだ」という感じもある。リスクに繋がるからといって機能の提供をやめることはできない。というより、それは本末転倒である。

いろんな脆弱性があるけれど、狙われるところは決まっている。普通のアプリケーションは個人の識別にセッションIDなどの文字列を使っているが、これが狙われやすい。

そのうち人間同士のコミュニケーションのように、顔や声、発言の内容などから総合的にAIが本人性確認をするようになるのではないだろうか、と想像した。