Ryuzee.com

XSS MeはFirefoxの拡張で、現在表示している画面から入力項目(テキスト、リストボックス、ボタン、hidden)を抽出し、クロスサイトスクリプティングが存在しないかどうか確認するプラグイン。最新版は0.3.0ベータ。入手はこちらから。

使い方

• XSS Meのサイドバーを表示させる
• テスト対象の画面をブラウザで表示する
• これで、ページになる入力フィールドが全て表示されるはずだ。

  

• テストしたい項目にチェックを入れて、「Test all forms with all attacks」（全部のテストを実行）もしくは「Test all forms with top attacks」（よくあるパターンのテストを実行）を選択する。
• 自動的にブラウザがリクエストを送信し始める。全テスト実行の場合は1項目あたり158程度、よくあるパターンのテストの場合1項目あたり18回程のリクエストをサーバに送信するのでしばらく待つ。
• 完了すると下記のような結果画面を表示する。
  

  ここではテスト用でまったくサニタイジングをしないアプリケーションを用意してみた。なので警告がちゃんと出ている。

ちなみに、このツールを使って自分のものではないアプリケーションに対してチェックをかけてはいけないので注意が必要だ。

こんなことをして嵌った。

• 開発していたのは、ローカルファイルシステムで
• JAVAスクリプトで他のサイトをwindow.openを呼び出して
• 呼び出したウィンドウを操作

で、これは何故か失敗します。ちょっと以下の通り試してみてください。

例えば、デスクトップにparent.htmlという名前で以下のようなファイルを作ります。

これを実行すると、結果はこうなります。

次にファイルシステム同士で実行してみます。(googleはローカルに配置できないので、
同じフォーム要素を持ったファイルを作ってください)
呼び出し元と呼び出し先をファイルシステム同士に配置した場合、これはうまくいきます。

さらに、今度は呼び出し元を違うサーバに配置し、呼び出し先をローカルのIIS以下に配置してみます。
これはうまくいきません。

まとめると

呼び出し元	呼び出し先	項目操作 できるか
ファイルシステム	ファイルシステム	成功
ファイルシステム	内部サイト(http://localhost)	失敗
ファイルシステム	外部サイト	失敗
内部サイト(http://localhost)	ファイルシステム	失敗
内部サイト(http://localhost)	内部サイト(http://localhost)	成功
内部サイト(http://localhost)	外部サイト(http://192.168.1.54)	失敗
外部サイト(http://192.168.1.54)	ファイルシステム	失敗
外部サイト(http://192.168.1.54)	内部サイト(http://localhost)	失敗
外部サイト(http://192.168.1.54)	外部サイト(http://192.168.1.54)	成功

結論としては、

• Window.openはどのサイトでも開けるが、
• 画面項目の操作については、Window.openを呼び出したページと、
  Window.openによって呼び出されたページのドメインが同一である必要がある

ということのようだ。なるほどねぇ。

mod_security対応強化の結果

こんな感じで拒否した件数調査。

# cat /var/log/httpd/error_log | grep "[error]" | 
grep "[Wed Mar 21" | grep mod_security | wc -l

3/21（水）
1473

3/20(火)　639

3/19(月)　1671

ということで結構良好。但しあまりに数が多いせいで、サーバに負担が掛かっている。Zope＋Ploneだからなぁ。

ブラックリストを作ったり色々しているが、トラックバックスパムが減らない。かなり鬱陶しい。

ということでmod_securityで対応することにした。

Got Root : mod_security rules

上記のサイトからmod_securityのポリシーファイルをダウンロードして設置すればよい。

構成は以下の通りだ。

設定ファイル	役割
apache2-rules.conf	一般的なアプリケーション用のルール
badips.conf	拒否するIPアドレスリスト（足りない分は自分で追加すること）
blacklist.conf	コメントスパム防止
blacklist2.conf	経由したプロクシやリクエスト元による拒否
exclude.conf	SQLインジェクションの拒否
jitp.conf	色々なアプリケーションの脆弱性への対応
proxy.conf	Proxyとして利用されることを拒否する
recons.conf	よくわからん・・・
rootkits.conf	rootkitによるアクセスを拒否する
rules.conf	アプリケーション保護のルール
useragents.conf	変なユーザエージェントをはじく（存在しないもの、一文字違いとか）

これで、スパムが減ると良いねぇ。

相も変わらず酒を飲んだあとで戯言をたれてみる。

2/23に公開されている@ITの「PHPプログラミングの基礎を学ぼう(1/2)」という記事を見た。

内容は・・・・これやばいです。この通り素人プログラマがプログラムを書くと、セキュリティ上問題がある。とりあえず気がついた点で指摘してみる。

PHPは、HTMLテキストのデザインを崩すことなくコード埋め込むことができるため、プログラマーだけでなく本格的なプログラミング経験がないWebデザイナーなどからも支持されています。

ダウト。HTMLテキストのデザインを崩すことなく、ということを求めるのであればテンプレートエンジンを求めるべきで、例示されているhtmlタグの中でprintするのはおかしい。

<?php
print $_POST["input1"];
print $_POST["input2"];
?>

ダウト。これ絶対真似してはいけません。入力画面でhtmlタグを入れられるとそのまま通過してそいつが表示されます。ユーザが入力してくるデータは常にチェックを行うべきで、それを習慣にしないといけない。

また、データ内容を簡単に盗み見ることができるため、通常はPOSTメソッドの使用をお勧めします。

こいつもダウト。GETでも単なる定型のデータ検索処理などではまったく問題ではない。またデータの盗み見はパケットキャプチャリングなのか、その他の方法なのかに関しての記述がない。重要なデータをGETで渡した場合の問題は、リファラなどでパラメータの内容が外部に流出すること、アクセスログなどに機密情報が記載されることであるので、その旨記載すべきであろう。なお本質的な対応であれば、POSTにした上でSSLを使うべきだ。

次に２ページ目。

しかし、本連載ではコードの可読性を重視するため、JavaScriptによるチェックを主に用いています。

ダウト。どうせ似たようなコード量になる。なぜここまで分かっていてPHP側でやらないのか？意味不明。

あーあ。なんだかなー。

ある人から作ったアプリを見て欲しいってなことを言われ暇なので見てみた。
一応、オープンソース含め色々ソース見てるし勘所はあるし。

開始0分
→全てのソースで何もPearライブラリがrequireされていない。著しい不安を覚える。

開始1分
→数10本のソースをgrepしてもclassという文字が見つからない。この先が魔界であることを悟る。

開始2分
→PHPのソース中にechoで1行毎にhtmlが大量に出力されていた。この時点でDQN認定。

開始3分
→どうもDBアクセスが全てSQLベースであり、しかもbindメカニズムが何も使用されていないことが分かる。早く動かしてSQLInjectionしたい衝動に駆られる。

開始5分
→入力値のチェック部分から甘～い香りが漂ってくる。眠らされてしまった。

つうことで作り直し推奨。これぢゃ品質担保できる気がしない。
このソースはかわいそうだが赤点だろ。

とりあえず移行が終わってほっと一息。色々問題もあったが（まだある？）、とりあえずってところ。

昨年は連続５日間ほぼ寝ずに仕事が出来たが、今年はそうもいかず、連続40時間くらい起きてただけで、その後に疲労が残っている。

SE３５年定年説っていわゆる体力の問題なんだなｗ。

最近わかってきたんだが、Webアプリのソースの品質を図る方法で一番簡単なのは、

「ソースの先頭近くで入力値のチェックを行って、変数に代入しているかどうか」

で見れば良い。これ出来てないソースはその後見る価値なし。基礎が出来ないのに応用できるわけなし。

使う際につどチェックするのは個人的には反対。一箇所でやんないと忘れるし、見通し悪い。

ソースの1000行目とかで突然

if(check($_GET['param'])){　hoge_func($_GET['param']);　}

とかやられても困るぜぃ。

だいたいビジネスロジックを先に作って、入力値のチェックは後で作ろう！とか考えるセンスに萎えるね。

自分で作るほうが楽だなぁ・・・。

＃まぁeasyにやるなら、とりあえず鯖にmod_securityとかのApplication Firewallを突っ込んでおいて予防線は張るって手もある。もちろん開発者にはそれは伝えないけどｗ

なぜか専門家かどうかわからんのだが、最近セキュリティ関連案件が多い。なんでだろ。

直近のWeb上での危機といえば、フィッシングだが、これ防ぐの簡単だと思われ。

1. co.jpドメインやne.jpドメインを利用する
2. サイトは総SSL化する
3. メールは送らない

だめかな？たぶん２が一番はやそうなんだけど。やらない理由はなんなんだろね？

既に攻撃用のコードも出回っているので、いまだにsendmailを使っている人は放置しておくと悲しいことになるかもしれない。
でもさ、何故わざわざsendmailなんて使っているのだろ？複雑怪奇な
sendmail.cf(慣れればどってことないが)使い、過去に不具合の多いもん選択するかな？うちの会社のグループでは基本的によほどの事情が無い限りqmailかpostfixです。
ftpのデーモンがproftpdからvsftpdに世代交代したみたいにいい加減sendmailも隠居でいいのでは？？

相も変わらず色々アプリを書いている。いまは仕事でPHPなんだが、以前お願いして協力会社に作ってもらったソースはXSSだらけ～（ただし認証配下かつF/Wでアクセス元限定）。

なので、これはアプリケーションファイヤーウォールでも入れないといかんな、と思いとりあえず自宅鯖でmod_securityの実験してみた。

これを入れると、要は入力パラメータ(正確にはクライアント側からapacheへ送信されるもの全て)を途中でチェックし、問題がある場合はロギングしたり、エラーとして以降の処理を止めたり出来る。
httpd.confまたは.htaccessまたはincludeファイルに予め以下のようなルールを記載しておく。

SecFilter "<[[:space:]]*script.*>"
SecFilter "<[[:space:]]*style.*>"
SecFilter "<[[:space:]]*link.*>"
SecFilter "<[[:space:]]*body[[:space:]]*>"
SecFilter "javascript:"
SecFilter "vbscript:"
SecFilter "about:"
SecFilter "expression("
SecFilter "&{.*};"
SecFilter "onError"
SecFilter "onUnload"
SecFilter "onBlur"
SecFilter "onFocus"
SecFilter "onClick"
SecFilter "onMouseOver"
SecFilter "onMouseOut"
SecFilter "onSubmit"
SecFilter "onReset"
SecFilter "onChange"
SecFilter "onSelect"
SecFilter "onAbort"
SecFilter "document.cookie"
SecFilter "Microsoft.XMLHTTP"

色々な攻撃手法が次々と出てくるが、この定義ファイルに記載することでより安全には出来る。
性能上の問題はあるかもしれないが、性能とセキュリティどっち取りますか？って聞かれればセキュリティ取る俺なので問題なし。

ちなみに先日Yahooは何故PHPを採用しているのかを示す英語文書を読んだが、やはりアプリケーションファイヤーウォールを併用しているようだ。いくら気をつけてもアプリからXSSの脆弱性はなくならないしな。

参考：＠IT

« 前の記事 

日記 PHP オープンソース Linux Trac Perl wordpress フリーソフト Agile 自宅サーバ phpMyFaq Plugin 書評 Delphi apache プラグイン Subversion アジャイル mojavi セキュリティ Ruby Firefox Ajax/Web2.0 eclipse サーバ Zope フレームワーク CakePHP 文字化け scuttle OpenVZ 自宅 phpBB CMS 翻訳・日本語化 Excel ApacheDS 生産性向上 仮想化 hacks CodeIgniter XAMPP LDAP SBM taskfreak Ajax 修正 言語ファイル mod_security ダウンロード HTML::FillInForm 情報共有 格安 メンテナンス 移転 アンケート レンタル PhpScheduleIt 翻訳 API