アジャイル,Trac,オープンソースなどの話。認定スクラムマスター。Twitterは@ryuzee
ECサイトから65万人の情報漏洩 20人が70時間,不眠不休で対応
直ちにFTPサーバーを停止。中島氏と相談し,Webシステム上のカード情報をバックアップして消去し,サイトでのカード決済を停止した。
(略)
コンテンツ担当の4人が中心となって3万本のプログラムをチェックしていく。夜が明けても作業は終わらない。結局,実際に使われているファイルを3000本にまで絞り込めたのは,作業開始から22時間30分たった同日午後11時だった。
対応が甘いよね。
ちなみに今サイトを見てみたが、まだIISのままだな。ってかシグネチャ隠しなよ・・・。404用のページもIIS標準じゃない奴用意しようよ・・・。
HTTP/1.x 200 OK
Content-Length: 271
Content-Type: image/gif
Last-Modified: Thu, 17 Apr 2008 09:47:33 GMT
Accept-Ranges: bytes
Etag: “109d72f70a0c81:688d”
Server: Microsoft-IIS/6.0
Date: Fri, 03 Jul 2009 05:50:09 GMT
Connection: Keep-Alive
XSS MeはFirefoxの拡張で、現在表示している画面から入力項目(テキスト、リストボックス、ボタン、hidden)を抽出し、クロスサイトスクリプティングが存在しないかどうか確認するプラグイン。最新版は0.3.0ベータ。入手はこちらから。
使い方
ここではテスト用でまったくサニタイジングをしないアプリケーションを用意してみた。なので警告がちゃんと出ている。
ちなみに、このツールを使って自分のものではないアプリケーションに対してチェックをかけてはいけないので注意が必要だ。
こんなことをして嵌った。
で、これは何故か失敗します。ちょっと以下の通り試してみてください。
例えば、デスクトップに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) | 成功 |
結論としては、
ということのようだ。なるほどねぇ。
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で対応することにした。
上記のサイトから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を使うべきだ。
次に2ページ目。
しかし、本連載ではコードの可読性を重視するため、JavaScriptによるチェックを主に用いています。
ダウト。どうせ似たようなコード量になる。なぜここまで分かっていてPHP側でやらないのか?意味不明。
あーあ。なんだかなー。
ある人から作ったアプリを見て欲しいってなことを言われ暇なので見てみた。
一応、オープンソース含め色々ソース見てるし勘所はあるし。
開始0分
→全てのソースで何もPearライブラリがrequireされていない。著しい不安を覚える。
開始1分
→数10本のソースをgrepしてもclassという文字が見つからない。この先が魔界であることを悟る。
開始2分
→PHPのソース中にechoで1行毎にhtmlが大量に出力されていた。この時点でDQN認定。
開始3分
→どうもDBアクセスが全てSQLベースであり、しかもbindメカニズムが何も使用されていないことが分かる。早く動かしてSQLInjectionしたい衝動に駆られる。
開始5分
→入力値のチェック部分から甘~い香りが漂ってくる。眠らされてしまった。
つうことで作り直し推奨。これぢゃ品質担保できる気がしない。
このソースはかわいそうだが赤点だろ。
とりあえず移行が終わってほっと一息。色々問題もあったが(まだある?)、とりあえずってところ。
昨年は連続5日間ほぼ寝ずに仕事が出来たが、今年はそうもいかず、連続40時間くらい起きてただけで、その後に疲労が残っている。
SE35年定年説っていわゆる体力の問題なんだなw。
最近わかってきたんだが、Webアプリのソースの品質を図る方法で一番簡単なのは、
「ソースの先頭近くで入力値のチェックを行って、変数に代入しているかどうか」
で見れば良い。これ出来てないソースはその後見る価値なし。基礎が出来ないのに応用できるわけなし。
使う際につどチェックするのは個人的には反対。一箇所でやんないと忘れるし、見通し悪い。
ソースの1000行目とかで突然
if(check($_GET['param'])){ hoge_func($_GET['param']); }
とかやられても困るぜぃ。
だいたいビジネスロジックを先に作って、入力値のチェックは後で作ろう!とか考えるセンスに萎えるね。
自分で作るほうが楽だなぁ・・・。
#まぁeasyにやるなら、とりあえず鯖にmod_securityとかのApplication Firewallを突っ込んでおいて予防線は張るって手もある。もちろん開発者にはそれは伝えないけどw
なぜか専門家かどうかわからんのだが、最近セキュリティ関連案件が多い。なんでだろ。
直近のWeb上での危機といえば、フィッシングだが、これ防ぐの簡単だと思われ。
だめかな?たぶん2が一番はやそうなんだけど。やらない理由はなんなんだろね?
既に攻撃用のコードも出回っているので、いまだにsendmailを使っている人は放置しておくと悲しいことになるかもしれない。
でもさ、何故わざわざsendmailなんて使っているのだろ?複雑怪奇な
sendmail.cf(慣れればどってことないが)使い、過去に不具合の多いもん選択するかな?うちの会社のグループでは基本的によほどの事情が無い限りqmailかpostfixです。
ftpのデーモンがproftpdからvsftpdに世代交代したみたいにいい加減sendmailも隠居でいいのでは??
日記 PHP オープンソース インストールマニアックス IIS Trac MySQL Perl Linux Agile・生産性向上 wordpress フリーソフト 自宅サーバ 書評 ブックマーク phpMyFaq TraM Plugin 早起き Delphi apache CakePHP Firefox Ruby eclipse セキュリティ プラグイン アジャイル mojavi Subversion Ajax/Web2.0 SQLServer Zope サーバ フレームワーク phpBB 仮想化 PostgreSQL OpenVZ scuttle CMS 文字化け 自宅 翻訳・日本語化 ApacheDS LDAP Excel 生産性向上 CodeIgniter XAMPP hacks taskfreak 修正 言語ファイル Ajax SBM ダウンロード HTML::FillInForm mod_security 情報共有