Posts in category: ブログ

連日と言っていいほどサイバー犯罪のニュースを耳にするようになったと思うが、この増加傾向は何を表しているんだろうか。
そのベースにあるのは、まさに「脆弱（ぜいじゃく）なWeb」が多いことである。今の時代、悪意のある人間はいとも簡単にWebページにアクセスでき、脆弱な部分を見抜いてしまう。
このような行為を手助けするかのように自動化されたツールが出回っているのも事実である。つまり、サイバーテロを試みる者さえいれば「専門的」なハッカーである必要はないのだ。
「安全なWeb」の実現には、努力目標としてセキュリティレベルを上げていくようなさまざまな行動を起こさなければならない。
本稿では2016年上半期のWeb脆弱性TOP4を取り上げる。下半期のセキュリティ対策を設けるにあたり、微力ながら参考になればと願っている。
1.SQLインジェクション（SQL Injection）
Webサイト攻撃の定番ともいえるSQLインジェクションは、アプリケーションプログラムの脆弱性を突き、開発レベルでは想定していなかったSQL文を実行することでデータベースを不正に操作する攻撃手法である。
この攻撃が成功すると、ハッカーはデータベースサーバに対してファイルの読み込みや書き込みが可能な状態になり、任意のプログラミングを実行できるようになる。
WHO（世界保健機構）のような大きな団体ですらSQLインジェクション攻撃にさらされたことがある。
悪意のある者はWebから簡単に自動化されたツールを入手し、攻撃のための下見に利用している。
例えば「sqlmap」という自動化ツールを使用すれば、ターゲットのURLに対してSQLインジェクションが可能となる脆弱性がないかどうかスキャンできる。
しかし、Exploit（エクスプロイト）攻撃を通じて、間違ったコードを挿入する場合、MySQLシンタックスエラーが生じることもある。
2014年、ハッキングの被害にあったソニープレイステーションのケースもSQLインジェクションによるもので、この昔ながらの脆弱性を突いた攻撃は現在でも十分すぎるほどの破壊力がある。
SQLインジェクションの試みが通ってしまうと、そこから抜かれる情報によって、企業側には計り知れない被害を及ぼすことになる。
2.クロスサイトスクリプティング（Cross Site Scripting：XSS）
ユーザーの入力に対し適切な措置が設けられていないシステムの脆弱性を突くXSS（クロスサイトスクリプティング）も定番の攻撃だ。
ユーザーに対し入力を許可する部分は、悪意のある者にとっては利用価値が高く、常に攻撃の対象になるのである。
実行可能なコードやスクリプトのタグをシステム側に挿入し、意図した行動を起こすようにコントロールできる強力な攻撃の入口となるからだ。
一般ユーザーが、XSSが仕込まれたWebサイトを訪問し、ページを閲覧するために1クリックするだけで悪意のあるコードが実行され、セッションクッキーや個人情報等が何者かに渡されてしまう。
実際クレジットカード情報も抜かれ、本人の覚えのない買い物をしてしまうケースも多々ある。
WhiteHat Securityが公開しているホワイトペーパーによれば、どんなWebサイトでも67％はXSSの脆弱性にさらされているという。
つまり、XSSを利用したWebハッキングは攻撃を行う側にとってコストパフォーマンスが高い方法であるのだ。
セッション・ハイジャック（Session Hijacking）を決行し、政府のWebサイトを改ざんする等、その効果の高さは大したものである。
ただし近年、Webブラウザ側で事前にXSSの試みをチェックする機能が実装されていることは不幸中の幸いである。
3.ファイルインクルージョン（File Inclusion）
ファイルインクルージョンは、Webサーバ上のデータに対し入力検証の不備を突いて不正なスクリプトを挿入する攻撃手法である。
そのパターンとしては、RFI（Remote File Inclusion）とLFI（Local File Inclusion）がある。
RFIは不正なスクリプトをサーバに挿入し、ターゲットのページを介して悪意のあるコードを実行させることで、サーバ側はもちろん、クライアント側にも被害を及ぼすことになる。
LFIは、ターゲットのサーバ上のファイルに対し、不正なスクリプトを挿入し、デフォルトファイル名の変更、データのアップロード／ダウンロードの実行等やりたい放題ができる。
この脆弱性をうまく利用できれば、ログファイルからIDとパスワードを洗い出し、他の攻撃と組み合わせてログインジェクション攻撃なども実行できてしまう。
このような脆弱性に対応するためには、入力検証の仕組みの脆弱性を把握し、不備を改修していくことを推奨する。
4.不完全な認証及びセッション管理（Broken Authentication and Session Management）　
Webアプリケーションでは、HTTPのリクエストトラッキング機能がない故に認証のリクエストとそのセッションを継続的に管理する必要がある。
悪意のある者は、このセッション情報から、ユーザーのタイムアウト、パスワード、ログアウト等さまざまな情報を入手できる。
この脆弱性の記憶に新しい事例は、マイクロソフトが提供するHotmailに悪意のあるスクリプトを挿入し、ユーザーのパスワードを入手しようとする攻撃を改修した際に発覚したものだ。
この脆弱性ではユーザーインタフェースにトロイの木馬を仕掛け、ユーザーにパスワードの入力を複数回求めるものだった。
そして、その入力データは即座に悪意ある者に送られるというシンプルながら非常によくできたものであった。
この種の脆弱性は、企業側で認証システムをカスタマイズし、セッション管理の不備があらわになってしまった場合に起こり得る。
ユーザーがログアウトの処理をせずにそのままサイトを閉じてしまうようなケースでこのような脆弱性にさらされる可能性が高い。
開発者レベルでセッション管理の確認はもちろん、SSLによるセッションの暗号化も基本中の基本の対策であろう。
まずは、行動を起こす　このコラムで紹介した脆弱性は、Webアプリケーション、Webサーバ、Webページにおける最も有名な攻撃手法である。
ありとあらゆる対策は開示されていて対応は進んでいるものの、まだまだ道は長いと言える。
開発時における優先順位の上位に「Webセキュリティ」を持ってきてもらえるように認識を変えることも伴わなければならない。
まずは、この4つの脆弱性に対し、企業側で行動を起こすことをお願いしたい。
脆弱性を認識しているのか、対策は取っているのか。現実問題として確認してほしい。
次のステップは、WAFなどの適切なソリューションの検討だ。脆弱性はセキュリティホールとも言われる。
しかし、この小さい穴を利用して、貴重な情報を盗み出したいと思う者がたくさんいる。
企業としての社会的責任、そして貢献を考える際に、経営側は「セキュリティ」を念頭に置かなければならない。
セキュリティホールはしっかりと埋めておかなければならないのである。
製品に関するお問合せはこちら
パートナーに関するお問合せはこちら
Cloudbricの製品情報はこちら