2. 「知識不足」と「うっかりミス」

2. 「知識不足」と「うっかりミス」

今回ご紹介した、よく見つかる脆弱性ですが、大きく「知識不足」と「うっかりミス」の2つに分類されます。「CSRF」や「自動化の停止が不適切」など、明らかにこのような脆弱性に対して、対策しようという意思が見受けられず、サイト全体で発生している問題があります。こうした問題は「知識不足」により作られた脆弱性と言えます。これらの脆弱性が発見される場合は、開発担当者にセキュリティ教育を実施し、脆弱性についての認識を高めていく必要があります。

「SQLインジェクション」、「XSS」については、知名度が高いためかほとんどのサイトで意識した対策がなされています。しかし、多くのサイトでこれらの脆弱性が部分的に対策されずに残っているようです。これらについては、「うっかりミス」で対策が漏れたケースもありますが、後述するような、機能追加の際に「知識不足」で部分的に対策が漏れるケースもあります。

3. 機能追加にご用心

Webサイト全体では問題なくても、特定の機能だけに問題があるケースが多々見受けられます。特にXSSやSQLインジェクションなどの有名な脆弱性はほとんどのサイトで何らかの対策が実施され、サイト全体にわたって問題があるケースは少ないです。しかし、一部、分かりにくい個所で対策漏れがあったり、特定の個所に限定して脆弱性が発見されたりするケースは多いです。

中でも特定の機能にだけ脆弱性が集中しているのは、Webサイト全体を構築した際には、セキュリティ対策をきちんと行った上で作られ、チェックもなされた様なのですが、後で追加された機能に脆弱性が作り込まれたのではないかと推測されるケースです。

自社開発の場合は、経験の浅いプログラマが追加機能の製作を行い、十分な検査がなされないまま、リリースされたのではないかと推測されます。また、開発会社に委託している場合は、追加機能部分から、セキュリティについてあまり知識のない他の開発会社に変わった等の理由が考えられます。

前者の場合は、開発者の教育を行いながら、リリース前にしっかりとした検査を行う必要があるでしょう。後者の場合は、第1回でご紹介した、「セキュリティ要件定義書」を使用して開発委託業者の質を上げることを勧めます。

最後に

今回、3回にわたって紹介した診断現場からの情報、いかがでしたか？なかなかセキュリティ対策に予算が見込めない状況ですが、セキュリティ要件定義の活用、サイトリリース前のピンポイントチェックで、最低限のセキュリティ対策がなされれば幸いです。

具体的な脆弱性対策については、他のサイトでも多く紹介されていますので、今回あえて言及していませんが、個別にご興味・ご質問のある方は直接ご連絡いただければ幸いです。