Ryuzee.com

[どうでもよいこと]対応が甘いんじゃないか？ 

ECサイトから65万人の情報漏洩 20人が70時間，不眠不休で対応

直ちにFTPサーバーを停止。中島氏と相談し，Webシステム上のカード情報をバックアップして消去し，サイトでのカード決済を停止した。
(略)
コンテンツ担当の4人が中心となって3万本のプログラムをチェックしていく。夜が明けても作業は終わらない。結局，実際に使われているファイルを3000本にまで絞り込めたのは，作業開始から22時間30分たった同日午後11時だった。

対応が甘いよね。

• 実際にサーバ上で動いているプログラムの本数がちゃんと管理できていないなら、変なプログラムが１つしかないなんてどうやって保証するの？
• FTPサーバにログインされた、ってことは全サーバがログインされた可能性がある。
• aspxって書かれているからWindowsサーバってことになるけど、レジストリや各種設定が改ざんされていないかの確証を取らなければならない。普通はOSから再インストールすべし。
• スパムの発信元や他所への攻撃に踏み台になっている可能性もある。
• そういう意味で変なプログラムがサーバで見つかった時点で、サイトは一旦クローズしないといけない。
• 中途半端に決済だけとめてサービスを継続するのは得策では無い。ウィルスを配布されたりする可能性もゼロではない。
• ということでF/Wがあったなら、アウトバウンドは全部とめたり、インバウンドも全部とめる。サーバをネットワークから切り離す。
• たぶんあんまりモジュール化せずにアプリケーション作ったんだろうなー、って想像がつくんだけど、将来への負債をかかえているよね。脆弱性対応をやるのは良いけど、本来的にはコードベースが古いってことで作り直した方が良い。
• 個人的な経験則としては、やたらとモジュール数が多いっていうのは、似たようなモジュールがコピペで粗製乱造されていて品質が悪いことが多い。
• ここがどうなのかは分からんけど。

ちなみに今サイトを見てみたが、まだ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

[Firefox][セキュリティ]XSSテスト用プラグインXSS Me 

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回程のリクエストをサーバに送信するのでしばらく待つ。
• 完了すると下記のような結果画面を表示する。
  

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

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

JAVAScriptのメモ 

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

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

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

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

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

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

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

まとめると

結論としては、

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

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

mod_securityの対応結果 

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で対応することにした。

Got Root : mod_security rules

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

構成は以下の通りだ。

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

＠ITのPHP記事突っ込みどころ満載 

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

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分
→入力値のチェック部分から甘～い香りが漂ってくる。眠らされてしまった。

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

Webアプリがまともかどうかを判断する超簡単な方法 

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

昨年は連続５日間ほぼ寝ずに仕事が出来たが、今年はそうもいかず、連続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なんて使っているのだろ？複雑怪奇な
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 情報共有