なぜPHPアプリにセキュリティホールが多いのか?

第46回 セキュリティ対策を考える上で欠かせないコンテクスト

この記事を読むのに必要な時間:およそ 9 分

環境と共に変わるセキュリティ対策の常識

セキュリティ対策の定義が変わらない限り,ある場面でセキュリティ対策とされるものがほかの場面でもセキュリティ対策であることに変わりません。しかし,セキュリティ対策の常識が変化することはよくあります。進化が非常に速いコンピュータの世界では,数十年前のセキュリティ対策の常識が完全に非常識となっている場合もあります。しかし,特定のケースで非常識になってしまったセキュリティ対策でも⁠セキュリティ対策でなくなる⁠ことはありません。

例えば,25年ほど前の1980年代半ばまで,銀行のキャッシュカードはカード自体の磁気データに暗証番号が記録されていました。今であれば少なくともハッシュ化したデータを利用すると思いますが,ハッシュすらも利用されていません。暗証番号がそのまま記録されており,カードリーダーさえあれば簡単に読み取れました。今のコンピュータの環境で考えればとんでもなく脆弱な設計だと言えます。

しかし,ATMが開発された当時は大型コンピュータであっても今のパソコンと比べると処理速度も通信速度も格段に劣る貧弱なものでした。このため,処理速度からもネットワーク帯域からもハッシュ化したデータのやり取りはもちろん,暗証番号の照合でさえ許されませんでした。負荷集中によるサービス不能状態を回避するセキュリティ対策として処理・仕様の簡略化を行ったのだと考えられます。今のコンピュータの性能とネットワーク環境ではあり得ないようなセキュリティ対策ですが,当時としては妥当なセキュリティ対策であったと言えます。

今のATMシステムでは「暗証番号をカードに記録する対策は無効なセキュリティ対策」であることに異論はないと思います。こんな馬鹿馬鹿しいセキュリティ対策をしているようなシステムは今はないはずだと思われるかも知れません。しかし,現在のWebシステムでもこれと同レベルの対策を採用しているサイトが多く存在します。SSL通信に対応していないサービスがその一例です。

通信の秘密が担保できない回線,例えば公衆Wi-Fiなどでは,SSL通信を用いないと通信の機密性は保てません。Wi-Fi基地局の設置者はセッションIDを含めた機密情報を簡単に盗聴できます。SSLを用いないサービスは脆弱なサービスであると言えます。

しかし,DoSのリスクを回避するためSSLを使わないサービス仕様も現状ではまだまだ十分有効なセキュリティ対策です。SSL通信による負荷にシステムが耐えられないため,暗号化をしないHTTP通信を利用するサービスは多くあるでしょう※6⁠。最近,GoogleがすべてのサービスにSSL通信を使うようになってから,サイト全体・サービス全体にSSL通信を使うケースも増えましたが,まだ当たり前になっているとは言えない状況です。

20年後の新人ITエンジニアに「昔はSSL通信を行わずにWebサイトを構築するのが当たり前だった」と紹介すると皆さんが「昔のキャッシュカードの暗証番号」の話を聞いたときと同じ感覚を感じると思います。20年も経つと処理速度や記憶容量の制限がなくなり,⁠処理・仕様の簡略化」は必要なセキュリティ対策として残っていないかも知れませんが,アプリケーションはハードウェアの進化と共に肥大化してきたのでどうなっているかは分かりません。

どの対策がセキュリティ対策でどの対策がセキュリティ対策でないか議論することは無意味であることがこの例からも分かると思います。セキュリティ対策を議論するのであれば,実際の制約や要件において有用であるか有用でないかの議論をしなければ意味がありません。

※6

ハードウェアによる暗号化に対応したCPUは比較的新しいCPUであり,対応するライブラリも比較的新しいライブラリです。古い既存のインフラのまま全通信をSSL化すると安定したサービスが提供できなくなるサービスは多いと思われます。

「セキュリティ対策ではない」の本当の意味

セキュリティ対策は完全でないことも多く,具体的なシステムにセキュリティ対策を行う場合,ITセキュリティの定義からはセキュリティ対策であるのに「セキュリティ対策ではない」と言われることがよくあります。これも初心者が「セキュリティ対策は難しい」と感じてしまう主な原因の1つではないでしょうか?

セキュリティ対策であるのに「セキュリティ対策ではない」と言う場合,言葉の一部が省略されています。

  • (有効な)セキュリティ対策ではない
  • (必要な)セキュリティ対策ではない
  • (十分な)セキュリティ対策ではない
  • (完全な)セキュリティ対策ではない
  • (効果的な)セキュリティ対策ではない

もしかすると「セキュリティ対策」という用語自体が日本人には曖昧であるため直感的に分りづらいのかも知れません。ISO/IEC 13335-1では「セキュリティ対策」という用語ではなくセーフガードを用いています。JISではカタカナで「セーフガード」をそのまま用いていますが,日本語に訳すとすると「安全対策」が妥当だと思います。こちらのほうが分かりやすいかも知れません。

  • (有効な)安全対策ではない
  • (必要な)安全対策ではない
  • (十分な)安全対策ではない
  • (完全な)安全対策ではない
  • (効果的な)安全対策ではない

どうでしょうか?

  • 「HTTP Basic認証はセキュリティ対策ではない
  • 「セキュリティ処理・仕様の簡略化はセキュリティ対策ではない

にあまり違和感を覚えない方でも

  • 「HTTP Basic認証は安全対策ではない
  • 「セキュリティ処理・仕様の簡略化は安全対策ではない

と書くと違和感がわかりやすいかも知れません。

  • 「HTTP Basic認証は(経路の安全が確保できない場合は信頼できる)安全対策ではない
  • 「セキュリティ処理・仕様の簡略化は(よほどの事情がない限り選択すべき)安全対策ではない

と表現するとわかりやすいのではないでしょうか?

円滑なコミュニケーションには共通の用語・概念が欠かせません。本来は〇〇なセキュリティ対策ではない」という意味で使われるべきところで単に「セキュリティ対策ではない」と言われていることには注意が必要です。明示した上で独自の用語・概念を用いることまで止めるべきだとは考えていませんが,基本的には標準規格・業界標準とされる用語・概念を共通の用語・概念とすべきでしょう(ISO 13335-1は先進国で構成されるOECDでの合意に基づき作られた国際基準です。共通の用語・概念とするには十分です⁠⁠。

セキュリティ対策を特別扱いする理由

前回の記事でセキュリティ対策だけ特別扱いする理由を解説しています。簡単におさらいをします。

図5 バグと脆弱性とセキュリティホールの関係

図5 バグと脆弱性とセキュリティホールの関係

脆弱性やセキュリティホールはアプリケーション要求仕様によって大きくなったり,小さくなったりしますが,必ずバグ対策よりセキュリティ対策のほうが小さくなります。

ソフトウェアは作ったようにしか動作しません。思ったように動作するソフトウェアを作る作業は非常に難しい作業です。その難しい作業の中で,特に重要な部分で問題が発生しないように対策するものがセキュリティ対策です。セキュリティ対策はバグ対策のサブセットとなるのでアプリケーション構築に必要とされる最低限の前提知識として区別するために特別に扱います。

著者プロフィール

大垣靖男(おおがきやすお)

University of Denver卒。同校にてコンピュータサイエンスとビジネスを学ぶ。株式会社シーエーシーを経て,エレクトロニック・サービス・イニシアチブ有限会社を設立。
オープンソース製品は比較的古くから利用し,Linuxは0.9xのころから利用している。オープンソースシステム開発への参加はエレクトロニック・サービス・イニシアチブ設立後から。PHPプロジェクトでは,PostgreSQLモジュールのメンテナンスを担当している。

URLhttp://blog.ohgaki.net/

著書