PHPカンファレンス北海道講演資料

PHPカンファレンス北海道講演資料

日付	2012年04月21日（土曜日）
時間	15時30分～16時10分
場所	札幌市産業振興センター
演題	徳丸本に載っていないWebアプリケーションセキュリティ

• phpcondo.pdf(1.4MB)

徳丸本に載っていないWebアプリケーションセキュリティ

View more PowerPoint from Hiroshi Tokumaru

講演ビデオ

徳丸本に載っていないWebアプリケーションセキュリティ / PHPカンファレンス北海道2012 from suzuki on Vimeo.

※リンク、ブックマーク等は、PDF直接ではなく、このページにお願いします。

OWASP JAPAN 1st Local Chapter Meeting講演資料

OWASP JAPAN 1st Local Chapter Meeting講演資料

日付	2012年03月27日（金曜日）
時間	19時00分～20時30分
場所	日本橋公会堂
演題	ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～

• owasp-japan-20120327.pdf(714KB)

ここが変だよ、グローバルスタンダードの脆弱性対策～入力値の考え方～

View more presentations from Hiroshi Tokumaru

※リンク、ブックマーク等は、PDF直接ではなく、このページにお願いします。

ホスト型の廉価版WAFであるSiteGuard Liteを評価した

このエントリでは、株式会社ジェイピー・セキュア（以下、JP-Secureと表記）のホスト型WAFであるSiteGuard Liteβ版の評価結果を報告します。SiteGuard Liteは、ModSecurityのようにApacheにモジュールとして組み込むタイプのWAFです。

はじめに

JP-Secure社が本年2月に、廉価なホスト型WAFとしてSiteGuard Liteを販売開始すると発表しています。このβ版を入手して評価しましたので、その内容を報告します。
商用製品の紹介ですので、以下に「重要情報の告知」を示します。

• HASHコンサルティング株式会社および徳丸浩（以下、単に徳丸浩と記述）は、SiteGuard Liteβ版の評価プログラムに申し込み、β版を無償で提供されている
• 徳丸浩はβ版提供以外に金品その他の提供を受けていない
• 本稿執筆時点でJP-Secure社とアフィリエイト契約はなく、その予定もない
• 評価結果をブログに書くことはJP-Secure社の了解を受けており、執筆内容の制約は受けていない

ただし、徳丸浩はセキュリティを商売にしておりますので、製品を評価した結果がよいものであれば、その製品を販売したいと思っています。そのため、評価記事が宣伝の要素を持つことはあり得ます。できるだけ客観的な評価を心がけますが、上記前提をご了承いただいた上で読者の判断により続きをお読みいただくか、読むのをやめていただければと思います。

SiteGuard Liteとは

SiteGuard Liteは、JP-Secure社がApacheのモジュールとして提供するホスト型WAFで、今年2月から販売開始されます。JP-Secureには元々フル版のSiteGuardがありますので、SiteGuard Liteはその名の通り廉価版という位置づけなのでしょう。SiteGuardのラインナップ比較を下表に示します。

	SiteGuard	SiteGuard for Server	SiteGuard Lite
配置方式	ネットワーク型	ホスト型	ホスト型
実装形態	Proxy	Proxy	Apacheモジュール
シグネチャ検査	○	○	○
ホワイトリスト検査	○	○
Cookie暗号化	○	○
セッション管理	○	○
クローキング	○	○
ライセンス費用	178万円	79万円	約30万円

SiteGuard Liteはシグネチャ検査に特化することで価格を下げた廉価版と言うことになります。

インストール

SiteGuard Liteは商用製品ですのでバイナリでの提供となります。Red Hat Enterprise Linux 4/5/6あるいはCentOS 4/5/6が動作可能ディストリビューションとなっています。筆者としてはUbuntu上でも動作確認してもらえるとありがたいと思いましたので、JP-Secure社にはそう要望しています。
rpmによるインストールは基本的には以下の3コマンドです。

# rpm -Uvh siteguardlite-1.00-beta.i386.rpm
# cd /opt/jp-secure/siteguardlite/
# ./setup.sh

最後のsetup.shはApacheの各種パスなどを指定するものです。その他、SE Linux用のポリシーを必要に応じて適用します。
今回の検証では、Centos6.2を用いました。apacheをyumでインストールした環境では、上記setup.shの実行は、リターンキーを何回か押すだけで終わりました。

使ってみる

それでは、さっそくSiteGuard Liteを用いて各種の攻撃を防御してみましょう。防御対象には、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方」（以下、徳丸本）の脆弱なサンプル44-001.php(同書P120)を用いました。ファイル名はbooks.phpとしました。ソースの冒頭を以下に引用します。

<?php
  session_start();
  header('Content-Type: text/html; charset=UTF-8');
  $author = $_GET['author'];
  $con = pg_connect("host=localhost dbname=wasbook user=postgres password=wasbook");
  $sql = "SELECT * FROM books WHERE author ='$author' ORDER BY id";
  $rs = pg_query($con, $sql);
?>
// 以下略

このスクリプトにはSQLインジェクション脆弱性があります。それをSiteGuard Liteで防御してみましょう。
以下は、徳丸本のP121に登場する「個人情報を盗み出す」攻撃です。

http://example.jp/books.php?author='+and+cast((select+id||':'||pwd+from+users+offset+0+limit+1)+as+integer)>1--

以下のようにブロックされています。

しかし、これは典型的な攻撃だから当然のようにブロックするでしょうね。以下、いくつかのトピックスを見てみましょう。

(1)ApacheKillerとhashdosはデフォルトで防御
ApacheKillerとhashdosのexploitをかけてみたところ、デフォルト設定でブロックしました。


(2)「完璧なWAF」はどうか
一頃、WAF業界で話題になった「完璧なWAF」に出てくる攻撃についても評価しました。

仮にscriptをブラックリストに指定したとしましょう。それでもまだ不十分です。<IMG>タグでXSSが発動することをご存じでしょうか？プログラムなどでは<IMG>タグは画像添付に必須であり、WAFで禁止することは難しいのが実情で、ブラックリスト方式の課題となっています。

という箇所についてですが、XSS Cheat Sheetに出てくるimg要素によるXSSの攻撃パターンのうちの一つが以下です。

http://example.jp/books.php?author=jav%09ascript:alert('XSS');

これについても、きちんとブロックしています。
次に、SQLインジェクションについてはどうでしょうか。「完璧なWAF」からunion selectに関するくだりを引用します。

SQLインジェクション対応の駄目な例として挙げられるのは、複文などの直接攻撃しか考慮していないケースです。簡単に言うと、master..execなどの直接攻撃のみ禁止しているWAFは甘く、union selectなどのunionインジェクションを考慮したWAFはまだマシであると言えます（攻撃者の観点が分かっているという意図でマシと記載しました）。
このブラックリストを通り抜けるにはコメントを使用します。たとえば、union/**/selectではどうなるでしょうか? 残念ながらほとんどのWAFは通り抜けてしまいます。

マシなWAFは「union select」は考慮するが、「union/**/select」はほとんどのWAFは通り抜けるということですが、SiteGuard Liteはどうでしょうか。
試してみると、

• union select      　… 通り抜ける
• union/**/select   … ブロックする

あれあれ、「完璧なWAF」とは逆の結果となりました。でも、この方がいいですね。「union select」は普通の英文にも出てきそうなのでブロックすることは不適切で、一方「union/**/select」は通常の英文にはまず出てこないと思われ、攻撃目的である可能性が高いからです。


(3)ライザムーン(LizaMoon)攻撃は防げるか
次に、これも一頃話題になった「新しいタイプのSQLインジェクション攻撃」であるライザムーン攻撃ではどうでしょうか。ライザムーンの特徴である(1)数値型項目に対するシングルクォートを用いない攻撃、(2)MS SQL Serverに対するセミコロンのない複文の特徴を持つ以下のパラメータで試しました。

author=17871+update+employee+set+number%3DREPLACE(cast(

このパターンでも、SiteGuard Liteはブロックしました。

ModSecurityとの比較

ここで、SiteGuard LiteのライバルとなるであろうModSecurityとの比較を試みます。ModSecurityの最新版2.6.3とCore Rule Set(CRS)2.2.3の組み合わせと比べてみました。
実は、今まで挙げてきた攻撃パターンは、ModSecurity（+CRS）もすべてブロックします。こう書くと、「では、無償のModSecurityでもよいのではないか」と思いそうですが、そうではありません。ModSecurityは「止めるべきでない」リクエストも止めてしまいます。つまり、過剰検知(False Positive)が多いのです。
たとえば、ModSecurityは「union select」という並びが入力にあるとブロックしますが、それだけでなく、「unionselect」や「unionAAAselect」もブロックします。すなわち、unionという単語の後のどこかにselectがあると、ブロックされます。
そのような例としてGoogle検索で適当に探した文を以下に示します。以下を入力として与えても、ModSecurityはブロックします。

Providing a credit union is a valuable benefit, and at Southern Select CCU, it will not cost your company a thing.

出展: http://www.southernselectccu.com/JoinUs.aspx (won'tをwill notに変更)

次に、ライザムーン攻撃についてもModSecurityはブロックしますが、以下の単純なパターンでもModSecurityはブロックしてしまいます。

author=17871+update

極めつきとして、ModSecurityは以下もブロックします。

author=夏目漱石

CRSには標準で「英数字以外が4文字連続するとブロック」というルールがあるからです。
さすがにこれでは使えないので、ModSecurityのチューニングとして、過剰検知のルールを無効化してみましょう。
まず、上記をブロックしているルールをModSecurityの監査ログから探します。以下が該当します。

SecRule "ARGS" "@rx \\W{4,}" "phase:2,log,capture,t:none,t:urlDecodeUni,block,id:960024,rev:2.2.3,msg:'SQL Character Anomaly Detection Alert - Repetative Non-Word Characters',logdata:%{tx.0},setvar:tx.anomaly_score=+%{tx.warning_anomaly_score},setvar:tx.sql_injection_score=+1,setvar:tx.msg=%{rule.msg},setvar:tx.%{rule.id}-WEB_ATTACK/RESTRICTED_SQL_CHARS-%{matched_var_name}=%{tx.0}"

このルールをコメントアウトしてもいいですが、別の方法として、id=960024を無効にすると言うルールを追加しましょう。この方が、ルールのメンテナンス性が良くなります。

SecRuleRemoveById 960024

このチューニングは、後述の性能評価のために必要でした。

一方、SiteGuard Liteでも同様のチューニングが必要になるケースはあり得ます。その場合、WebのGUIからログを確認して、対応するルールの無効化や監視のみへの変更も、Web GUIから可能です。今回の評価では、SiteGuard Liteのチューニングはせず、デフォルト設定で使用しています。

さて、前述のように、ModSecurityとCRSの組み合わせは防御能力は高いように見えるものの、過剰検知が多いのでチューニングなしには使えないのです。過剰検知が多いのはModSecurity本体というよりはCRSの問題ですが、さりとて、CRSを使わないとなるとルールを買ってくるか、自分で作ることになります。すなわち、ModSecurityは無償とはいえ、導入には手間が掛かるということです。

一方、ModSecurityのメリットはなんでしょうか。ことカスタマイズに関しては、ModSecurityの方が優れています。ModSecurity自体はWAFを作るための開発ツールととらえることができます。たとえば、アカウントロック機能をModSecurityで実現することも可能です。しかし、ModSecurity上の複雑なルール作成は大変ですし、ModSecurity本体のバージョンアップに伴い従来動いていたルールが動かなくなる可能性もあります。そのようなModSecurityのバージョンアップの大変さについては、IPAが公開している「WAF読本」のP70～P71にも記載されています。
ということで、ルールの自由度という点ではModSecurityが優れていますが、その自由度を使いこなすのは中々大変であると考えます。

性能評価

次に、性能の評価をしてみました。サーバーマシンのスペックを以下に示します。4年前に19,800円で購入した格安サーバーです。

DELL PowerEdge/SC440
CPU:Pentium Dual-Core 2GHz
メモリ 3.6Gバイトを割り当て
VMware Server上で評価

負荷テストにはApache Benchを用い、以下のコマンドラインを用いました（同時接続=50、リクエスト数=1000）。WAFに負荷をかけるために、余分なパラメータを追加しています。

ab -c 50 -n 1000 "http://example.jp/books.php?author=Shakespeare&zip=113-8663&addr=%E6%9D%B1%E4%BA%AC%E9%83%BD%E6%96%87%E4%BA%AC%E5%8C%BA%E6%9C%AC%E9%A7%92%E8%BE%BC2-28-8&tel=03-1234-5678"

結果を以下に示します。

	WAFなし	SiteGuard Liteあり	ModSecurityあり
秒間リクエスト数	30.05	29.94	27.56
相対性能	100%	99.6%	91.7%

ModSecurityが少し遅いものの、あまり差はありません。その理由は、アプリケーションが遅いため、相対的にWAFの遅延が見だたなくなっているからと予想されます。
そこで、先のスクリプトをチューニングすることにします。ボトルネックは、DB接続をコネクションプールしていないことと予想されるため、pg_connectをpg_pconnectに変更してabをかけました。
結果を以下に示します。高速化されたため、リクエスト数を1万にしています。

	WAFなし	SiteGuard Liteあり	ModSecurityあり
秒間リクエスト数	365.34	284.85	127.80
相対性能	100%	78.0%	35.0%

スクリプトが10倍以上高速になったことにより、WAFのオーバーヘッドが目立ち始めましたが、それでも2割ちょっと遅くなるだけで済むというのは、許容できる範囲ではないかなと思いました。4年前の2万円弱のサーバーで280リクエスト/秒出せるのであれば、通常の応用には十分ですし、アプリ側が遅い場合は、1番目の例で見たようにWAFのオーバーヘッドはさらに目立たなくなるからです。ModSecurityはCRSを全部有効にしているために遅いとも考えられるため、性能という観点からもルールのチューニングが有効でしょう。ただし、Webサーバーの性能に余裕がある場合には、上記性能劣化は許容できると思います。

他のWAFとの使い分けの考察

SiteGuard Liteの購入を検討する際にもっとも比較されるのは、SaaS型のWAFサービスでしょう。
単純に価格だけ見れば、SiteGuard Liteの方が安く見えます。SaaS型のWAFサービスの相場は、初期設定10万円程度、月額3万～という感じだと思いますが、初年度で元が取れそう…というのは錯覚で、SaaSの方は導入費と運用費が込みですので、単純に比較するわけにはいきません。
また、SaaS型WAFサービスだと応答の遅延を気にされるユーザが多いようですが、SiteGuard Liteのようなホスト型のWAFは、遅延の影響はもっとも受けにくい形態になります。
このように、性能上の特徴とトータルコストを勘案して、導入するWAF製品・サービスを選定することになります。

守るべきWebサーバーの数が非常に多い場合は、複数台のWebサーバーを一台のWAFで守れるならば、SiteGuard Liteではなく、ネットワーク型のSiteGuard（フル版）の方が安くなる可能性があります。

感想

私は3年半前に「三重苦を乗り越えてWAFが普及するための条件とは」という記事を書いて、以下のように結論づけました。

実運用に影響を与えない程度の控えめなブラックリストをチューニングして、それを全パラメータ共通で使用する。そうすれば、手間も掛らないし、機械化されたSQLインジェクション攻撃程度であれば十分な効力がある。それでも運用に影響が出るパラメタもある(ブログや掲示板など)が、そのパラメタだけはブラックリスト検査を除外して、その代わりしっかり脆弱性検査をして対策もアプリ側でとっておけばよい。【中略】
また、WAFの低価格化は必須だ・・・というより、ホワイトリスト機能を使わないのであれば、安いWAFで十分だ。

SiteGuard Liteは、3年半に出現を予告した製品が、ようやく世の中に出てきたように私には見えましたw

そんな訳で、弊社（HASHコンサルティング株式会社）は今までセキュリティ製品の販売は手がけていませんでしたが、SiteGuard Liteは初めて「この製品なら売りたい」と思いました。

まとめ

SiteGuard Liteのβ版について評価しました。
SiteGuard Liteはシグネチャ検査に機能を絞った廉価版WAFですが、XSSやSQLインジェクションについては十分な防御性能と速度を持ちます。
インターネットがとても物騒な状況にある今、とくにSQLインジェクション対策としてWAFの導入は有効であり、その有力な選択肢としてSiteGuard Liteが挙げられると考えます。


[PR]
WAFの選定・導入に関する相談はHASHコンサルティング株式会社まで。
「安全なWebアプリケーションの作り方」DRMフリーのPDFによる電子版もあります。

10月14日YAPC::ASIA Tokyo2011でトークしました

YAPC::ASIA Tokyo2011トーク資料

日付	2011年10月14日（金曜日）
時間	13時40分～14時20分
場所	東京工大大岡山キャンパス
演題	Webアプリケーションでパスワード保護はどこまでやればよいか

Webアプリでパスワード保護はどこまでやればいいか

View more presentations from Hiroshi Tokumaru

YAPC::ASIA Tokyo2011のベストトーク賞3位を頂戴しました。ありがとうございました。

9月10日PHPカンファレンス2011で講演しました

PHPカンファレンス2011講演資料

日付	2011年09月10日（土曜日）
時間	16時30分～17時10分
場所	大田区産業プラザ PiO
演題	徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011

徳丸本に学ぶ 安全なPHPアプリ開発の鉄則2011
View more presentations from Hiroshi Tokumaru.




PDF形式のダウンロード
USTREAMによる講演録画


※リンク、ブックマーク等は、PDF直接ではなく、このページにお願いします。

WAS Forum Conference 2010講演資料

WAS Forum Conference 2010講演資料

日付	2010年05月22日（土曜日）
時間	10時00分～18時00分
場所	コクヨホール
演題	ケータイ2.0が開けてしまったパンドラの箱

ケータイ2.0が開けてしまったパンドラの箱

View more presentations from Hiroshi Tokumaru.

「かんたんログイン」DNSリバインディング耐性のチェック方法

このエントリでは、ケータイ向けWebサイトがDNSリバインディング攻撃に対する防御耐性があるかどうかをチェックする方法を説明します。ケータイ向けに「かんたんログイン」機能をもつWebサイトをチェック対象とします。

基本的な前提として、検査対象のWebサイトの管理者が自ら検査することを想定しています。

用意するもの

• チェック対象のWebアプリケーション(かんたんログイン機能あり)
• 携帯電話（かんたんログイン可能なもの）
• インターネット接続されたパソコン

ステップ0:IPアドレスの調査

検査対象のWebサーバーのIPアドレスを調べます。一例として、検査対象サーバーのホスト名が mobile.example.com の場合、以下のコマンドでIPアドレスを調べることができます。

C:>nslookup mobile.example.com
サーバー:  ns.example.com
Address:  192.0.2.1

権限のない回答:
名前:    mobile.example.com
Address:  115.146.17.185
C:>

上記の例では、WebサイトのIPアドレスは、115.146.17.185になります。

ステップ1:数値IPアドレスでログイン画面を閲覧

ケータイWebアプリケーションのログイン画面のURLに対して、ホスト名を数値IPアドレスに変更したもので、携帯電話ブラウザを使用してアクセスします。上の例では、ログイン画面のURLがhttp://mobile.example.com/login?guid=ONの場合、http://115.146.17.185/login?guid=ONにアクセスすることになります。

この結果、403 Forbiddenなどのエラーでログイン処理が継続できなくなった場合はチェックを終わります（耐性あり）。画面が正常に表示された場合はステップ2に進んでください。

ステップ2:かんたんログインの実行

携帯ブラウザ上でかんたんログインボタンを押下（あるいはリンクを選択）します。

この結果、403 Forbiddenなどのエラーが表示された場合はチェックを終わります（耐性あり）。ログインが正常終了し、ログイン後の画面が表示された場合はステップ3に進んでください。

ステップ3:URLのチェック

携帯ブラウザの機能を利用して、現在表示されている画面のURLをチェックします。ホスト名が数値IPアドレスのままになっている場合は、DNSリバインディング攻撃に対して脆弱です。アドバイザリを参考に対策してください。数値IPアドレスではなく、本来のホスト名に変更されている場合はステップ4に進んでください。

ステップ4:数値IPアドレスでのコンテンツ閲覧

先ほど確認したURLに対して、ホスト名を数値IPアドレスに変更したものでコンテンツを閲覧します。コンテンツが正常に表示された場合、DNSリバインディング攻撃に対して脆弱です。エラーになった場合は、DNSリバインディング攻撃への耐性がある可能性が高いと予想されます。

以上の内容をフローチャートにまとめました。

まとめ・注意事項

かんたんログインのDNSリバインディング脆弱性をサイト運営者が自らチェックできる方法を説明しました。この方法はあくまで簡易検査であり、疑わしい状況である場合や、対策方法が分からない場合は専門家に問い合わせることを推奨いたします。ステップ4まで進んではじめて結果が出た場合も不確かである可能性があるため、専門家に相談されることを推奨します。HASHコンサルティングへの問い合わせはこちらから。

免責

この情報は、読者の便宜のために、HASHコンサルティング株式会社が現状のあるがままの状態で提供するものです。この検査の引き起こす結果等について、HASHコンサルティング株式会社はいかなる保証もしません。また、この情報は事前連絡なく改定される場合があります。

また、この検査方法は、あくまで自分が管理するWebサイトについてのみ実施してください。

追記（2010/03/21）

水無月ばけらさんのはてなブックマークコメントにて、指摘を頂戴しました。

ほとんどの場合はこれでOK。しかし、「数値だと蹴られるが、でたらめな Host: だと受け入れる」という設定が実在するので油断大敵。

ご指摘ありがとうございます。当方で確認した範囲では、ModSecurity（Apacheのモジュールとして動作するWebアプリケーションファイアウォール）を導入している場合に、「数値だと蹴られるが、でたらめな Host: だと受け入れる」設定となる事象を再現できました。以下に、ModSecurity導入状態で、数値IPアドレスによるリクエストがエラーになっている画面例を示します。

すなわち、数値IPアドレスによるリクエストでエラーになる状況には以下の二通りがあることになります。

1. ホスト名が本来のものでないことによるエラー
2. 数値IPアドレスをエラーにしている

上記1の状況であれば問題ありませんが、2の状況であれば、DNS Rebindingに対して脆弱である可能性があります。携帯電話の画面内容から、上記の区別をつけることは簡単ではない場合があるため、正確な検査を実施するには、正式なドメインとは別に検査用のドメインが必要になります。

このような検査用ドメインを用意することが難しいお客様のために、HASHコンサルティング株式会社では、無償で検査用のドメインをご提供することに致しました。お問い合わせフォームより、「検査用ドメイン希望」とご連絡ください。以下に注意事項を記述いたします。

• 検査対象サイトのホスト名(FQDN)をお知らせください
• 弊社が所有する検査ドメインのサブドメインに、検査対象サイトのIPアドレスをセットしてお伝えします
• ドメインの所有権を譲渡するわけではありません。
• IPアドレスは固定です。DNS Rebindingそのものの再現はできませんが、脆弱性の簡易検査用途には十分です
• 検査対象サイトの正当な管理者であることをメールアドレスのドメインなどを元に確認させて頂きます
• 検査作業は上記手順によりお客様にて実施頂くことを原則としますが、お客様合意の元に、弊社からも簡単な検査を実施させて頂く場合があります
• 検査作業や結果の判定、脆弱性の詳しい解説などをご希望される場合は別途ご提案させて頂きます
• 検査用ドメインの提供は、原則として1社につき1サイトとさせていただきます。多数のサイトを検査希望される場合は別途ご提案させていただきますので、その旨ご連絡ください
• 本サービスは予告なく応募を締め切る場合があります

別途キャンペーンとして告知したいと考えておりますが、サービスの提供は即日開始いたします。不明な点はお問い合わせください。