SQL インジェクション

Web デベロッパーの方なら、SQL インジェクションというセキュリティホールについては良くご存知だと思いますし、コードを書くときは十分に気をつけていると思います。

実はつい最近のお仕事で、よそのベンダーコードを引き継いで、Web サイトのメンテナンスをすることになりました。ある Web サービスの呼び出しをアップグレードするというのが元のタスクでした。

ところが、その調査過程で見たのは、世にも恐ろしいセキュリティホールだらけのコードでした。

危険がいっぱいのコード

SQL インジェクションに限らず、セキュリティホールと言うのは主にユーザーから送信されたデータ、あるいはファイルなどの外部からのデータを、あまり検証しないで取り込むところに発生する場合が多いものです。

バッファオーバーフローなら、予想されたデータ長よりも長いとか、フォーマットに合わないとか、そういう類の入力が問題になり、クロスサイトスクリプティングや SQL インジェクションなどは、ユーザーの入力をそのまま取り込んでしまうときに容易に発生します。

だから、これが問題を起こしそうかどうか、というのはソースをパッと見てわかることも少なくありません。

実は今回のコードはパッと見て危ないコードとわかりました。

試しにテスト環境で動作確認をしましたが、案の定、自分のアカウントに他人のデータを取り込むことも、他人のアカウントに変なデータを書き込むこともなんでもできてしまうような状況でした。

全く恐ろしいとしか言いようがありません。

上で SQL インジェクションやクロスサイトスクリプティングなどの、いわば有名な脆弱性 (パターン) を書きましたが、それらの仕組み、防ぎ方、などは Web デベロッパーとしては必須の知識です。

新しいものでもなく、私も 2002 年の頃に既に TechEd でもこれらについてデモを含めて、いろいろとご説明させていただいたこともあります。

まだあまりよくわからないと言う方は、一度しっかり勉強する必要があります。

かくいう私もその仕組みと ASP/ASP.NET での対処方法は良くわかっているつもりですが、LAMP 環境ではまだまだ勉強する必要性を感じています。

私はこちらの Hunting Security Bugs という書籍を、念のため手元において、コードをチェックしています。

また、最近は PHP のコードでより理解を深めるために、次の本をオーダーしました。

来週月曜日に届く予定なので、面白いことを見つけたらこのブログか本サイトで紹介する予定です。