セキュリティの
学び場

今回の解説ニュース

SQLインジェクションの攻撃により、Webサイトから一部のメールアドレスが漏洩したということです。SQLインジェクションの対策や、脆弱性が減らない現状の背景について説明します。

今回のインシデントは、Webサーバのプログラムの一部の脆弱性を突いて、会員のメールアドレスが外部に流出している可能性が判明したということです。原因として、SQLインジェクションの脆弱性が挙げられています。

対策として、攻撃のあったプログラムを停止し、再度の攻撃を受けないよう対応を実施したということです。また、対象の顧客に対し、個別にメールを送付し、個人情報保護委員会と警察署へ報告を行っています。再発防止策として、外部専門機関による脆弱性診断を実施し、サーバシステム、Webサイトのセキュリティを強化したということです。

SQLインジェクションへの対策、2つのアプローチ

SQLインジェクションの対策として、ソースコードを修正する方法と、アプリケーションの外側で修正する方法があります。それぞれについて説明します。

まず、ソースコードを修正する方法として、SQLインジェクションが発生している箇所を特定して、適切な書き方に修正します。具体的には、SQL文を動的に組み立てている箇所に文字列連結を使っていることが考えられますので、代わりにプレースホルダを使いましょう。プレースホルダとは、外部から入力される値を受け取る場所です。SQL文で外部から入力される値をプレースホルダで受け取ることにより、機械的な処理によってSQL文が組み立てられるため、SQLインジェクションの脆弱性を解消することができます。

また、アプリケーションの外側で修正する方法として、WAFを導入することが挙げられます。WAFとは、Web Application Firewallの略で、外部からWebアプリケーションに対する攻撃を防ぐセキュリティ対策です。Webサイトの代わりに外部からの通信を受け取り、SQLインジェクションなどの攻撃とみなされた通信を遮断します。ただし、WAFですべての攻撃を防ぐことができるわけではありませんので、ソースコードを修正して脆弱性を根本的に解消することを原則としましょう。

なぜ対策があってもSQLインジェクションの被害が減らないのか？

SQLインジェクションの被害が減らない理由の一つは、プログラミングが人の手作業によって属人的に書かれているからです。対策として、コーディング規約の策定が有効です。

開発においては開発者自身にゆだねられる事が多い

最近の開発プロジェクトにおいては、非エンジニアでもプログラミングができるような、専門的な知識が不要になる環境が整備されつつあるとはいえ、多くの現場では、専門知識を持った開発者の手によってソースコードが書かれています。具体的には、先ほど説明したプレースホルダやフレームワークなど、SQLインジェクションを発生させないための機能は複数用意されているものの、インシデントの発生が後を絶ちません。理由は、それらのセキュリティ機能はあくまでも道具であり、それらが正しく使われるかは、ソースコードを書く開発者自身に依存しているからです。

「コーディング規約」の存在

プログラミングにおける様々なセキュリティの道具を正しく使うためには、説明書に当たるコーディング規約が必要です。コーディング規約とは、ソースコードの書き方についてまとめられたルールです。複数の開発者が参加するプロジェクトで、主に品質や保守性などを担保することを目的として、開発者が守るべきプログラミングの作法がまとめられています。

全ての開発参加者に共通の認識を持たせる

例えば、SQLインジェクションが発生しないソースコードの書き方は存在しています。それをコーディング規約としてまとめることで、ソフトウェアに脆弱性が作りこまれることを防ぎます。もちろん、すべてのプロジェクトに参加する開発者がコーディング規約を守られるように、啓発や教育などが併せて必要です。

今回はSQLインジェクションが発生する背景とその対策についてお届けしました。「属人的であればブレが生じる」「ブレが生じればミスが起こる」ミスが許されないセキュリティ対策の属人性を排除するために、標準化や仕組化を目指していきましょう。