August 13, 2008
かくあるべしの批判は簡単にできるが、ちょっと待って。
このエントリーの目的は、例えば受託をやってる人が、改めて過去を振り返って、もう関係が切れてしまったクライアントもできることなら助けてあげてください、というエントリーです。
SQLインジェクション絡みで、Active Server Pagesで動いているサイトが結構狙い打ちにあって、重要な顧客情報が流出したりしています。
こういうネガティブな改修話は瑕疵の問題を持ち出されたりして、ややこしいことになるケースもあるハズ。だから作った側としては、もし気になるところがあっても、余計なことは言いたくないって気持ちはあると思う。
「何故そんなことも知らなかったのか？」
と言われると返す言葉もなくなる。これを一方的に言われてしまい、例えば調査やシステム改修に２ヶ月もの期間がかかる見積もりを一方的に負わなくてはいけないとするならば、正直、このことを黙ってて、システムが消滅するまで何も起こらないことを祈りたいという気持ちになるのは否めない。企業対企業であればなおさらだ。
でも、それでは間違いなく誰も幸せにならない。
ということを前提で、以下の話。
ナチュラムの情報漏えい事件では顧客のパスワードが平文で流出していたことが発覚
多くのWebサイトにおいてパスワードは暗号化（一方通行関数によるハッシュ化）して保存するというコンピュータセキュリティの基本のキが驚くほど浸透しておらず徹底されていない
・・・その他もろもろ。
今回の某社も、ちょっと前に情報流出して詳細な状況レポートを出していた某社も、Active Server Pagesのサイトだったと思う。
当時のASPは、立ち位置的には今のPHPみたいな存在で、Unixでは運用がちょっとと言ったケースなどで、VB出身のエンジニアを中心に使われていたと思う。確かにインターネットセキュリティに関してスキルが低いエンジニアがWebシステムを作っていた確率は高かったかもしれない。
僕も例外ではなくASPを使っていた。
確か2001年ぐらいだったかな。@ITあたりでSQLインジェクションという言葉を目にしたのは。
もちろんその筋では、常識だったのかもしれないし、@ITだったかに出てくる前には、各種MLなどでは言われていたんだろうから、「そんなことも知らなかったの？」と言われればそれまでだが、何を言われようとも、僕が初めてSQLインジェクションについて知ったのは、そういうIT系ニュースサイトに取り上げられたのがきっかけだ。
（つか、初めてSQL書いたのは2000年後半だったりします。）
当時、SQLインジェクションの記事を見て、うわーこんなことができるんだーと思ったものだ。
ASPのデータベースアクセスに使うADO DBには、多分、プレースホルダによってSQLインジェクションを防ぐ機構はなかったんじゃないかと思うし、ASPにはPHPのようなマジッククオート（これはセキュリティ対策ではないそうだが）もなかったので、SQLインジェクションという言葉や、SQLのリスクをちゃんと理解して当たり前のようにエスケープしていた人を除けば、結構な確率でSQLインジェクションを誘発する作りになっていたりするのではないだろうか。
また、パスワードをハッシュで保存すべきという部分は、ASPの標準ライブラリには確か、MD5のライブラリはなくて、ASP開発者御用達のBasp21というフリーのライブラリに依存するか、自作するしかなかったと思う。要は暗号化したいと思えばこそ、見つかるという存在である。
ASPの良いところでもあり悪いところは、ASP自体はかなりシンプルな機能しか持っておらず、ActiveX DLL(COM）で機能を拡張していくというものなので、その情報を知らなければ全く使うアテもないというのはあったと思う。また、Basp21がフリーのライブラリが故に、案件で使えないというところもあったハズだ。
セキュリティについても今ほど情報が充実していなかった時代だったと思うので、第一次ネットバブルの頃に量産されたWebサイトのかなりの数は、非常によろしくない状態で存在しているんじゃないかと肌感覚では思うところ。
そんな時代背景の中で、売り上げを伸ばしてきて今までずっと生き残ってきた老舗のECサイトが、ここへ来てハッキングされて顧客情報が流出してしまうのは、結果論からすると、なるほどやっぱりそうだったのか、という印象ではある。
だから、ハッキングされて当たり前とかそういう話を書きたいわけではないが、今と比べると、やっぱり問題の多いプログラムが存在しうる時代だったと思うので、瑕疵で一方的に開発者が悪いとか、そういう空気にするのではなく、そういう事実は受け入れた上で前に進むためにシステム改修できるような空気になると良いなと思うわけです。
（とても書き方が難しい。けど、GoogleやAmazonと言った名だたるWebサービス企業だって多数のセキュリティホールを修正しながら今があるんだと思います。）
これから先はリスクマネジメントの話であるが、事業が立ち上がって、十分に利益を出しているシステムにおいて、セキュリティ対策のために一からソースコードの監査をするなどと言った行為は、経営者レベルのセキュリティ意識が十分に高くないとできないことだと思う。
何せシステムが肥大化しているハズだから、その検証コストも時間もバカにならないし、スタッフは売り上げを伸ばす人数で最適化されてるハズだし、運用そのもので手一杯。現場の判断だけだと「今まで問題ないから明日も問題ないんじゃないの？」と判断される可能性が非常に高い。
ここに対して、待ったをかけられるのはCTOを含めた危機管理意識を持った経営層ということになるが、結局はコード一行一行の話だったりするし、既に偉くなってしまって現場から離れた人の過去の経験と、「当たり前のセキュリティスキル」が実は乖離しているケースも少なくはないし、何より意志決定できる人ほど、ソースコードから距離が遠いというジレンマもある。
もちろん、お金をかけて外部の業者に頼んだセキュリティ診断などは有効だと思うが、大企業には受け入れられる見積もりも、ベンチャーや他のビジネスからネットビジネスを始めた企業にはなかなか受け入れられない価格だったりする。
どちらかというとネットワーク効果に支えられた薄利多売モデルで商売し、広告宣伝費、人件費、固定費を抑えてきたが故に利益を出してきたというネット系企業のあり方だと、そのコストをかけられるほど危機意識を持つチャンスが、情報漏洩したときという皮肉な状態はなんとも不幸な状態である。
内部で回すにせよ、それだけの危機意識を演出していかねば、本気のセキュリティ監査など、なかなか立ちゆかないというのが現実だと思う。そもそも他人が書いたソースコードを読むのは相応のスキルと精神力が求められるし、何より他人のコードを信用しない性格や批判的精神こそがセキュリティ不具合発見には必須だと思う。
ちなみに偉そうに書いてるように見えるかもしれないが、全然他人事だとは思っていませんので悪しからず。
#今更過ぎるけどWebシステムの開発は難しい。たかだかネットを通じた文字の入出力システムなれど、不特定多数の入力文字列がシステム内をシームレスに駆けめぐり、JavaScriptからファイルシステムからSQLまで影響を及ぼす可能性を秘めているわけですから。
ADOにもちゃんとCommandオブジェクトっていうものがあります。が、
知らない=無い と同意ですね。