b2evolutionバージョンアップ
セキュリティ問題の修正を含むアップグレード版がリリースされています。
http://b2evolution.net/news/2007/01/22/b2evo_1_8_7_and_1_9_2_released
「意味がある形での攻撃は難しいだろう」と書いてありますがアップグレードしておいた方が良いと思います。
正規表現がおかしてくリンクが正しく表示されない問題は直っていないですね。
Windows税の返金?
少し古いですがLinux.comに「Windows税の返金をDELLから受けた」といった記事が載っています。
私はWindowsも使うのでサーバ以外であれば返金して欲しい、と思わないですが日本でも可能なのかと少し気になります。何時間もかけて$52.50の返金だったので著者自身も勧めてはいません。
Tipsとして
- 返金してもらう資格がある（日本の法律ではどうなんでしょう?）
- すべて(やり取りを）記録する
- (時間の浪費や面倒なやり取りを）覚悟しておく
- 礼儀正しく
- 粘り強く
- 愛想よく
と記載されています。コールセンター構築に関わっていた事があるので「礼儀正しく」「愛想よく」と書いてある点には好感が持てます。
しかし、メーカーサイドとしてはこの手のリクエストは厄介ですね。バンドルしたソフトなどの返金を求められても困りますね… しかし、LinuxやBSDが代替OSとして利用可能なのでOS無しでの販売もして欲しいです。個人的に困ったのは欲しいノートPCがWindows XP Homeしかバンドルしてなくて仕方なくWindows XP Homeを買わされたで事した。後でステップアップグレード版でHome->Professionalへアップグレードしました。Vistaでも同じような事で困るかも知れません。
SHA1でハッシュ化したパスワードは危険になった
パスワードを平文で保存するのは論外で、MD5やSHA1でハッシュ化するのは当たり前です。しかし、SHA1を2000倍早くクラックする方法などが発見され「SHA1は脆弱だ」（ちなみにMD5はもっと危険）とされてからしばらく経ちます。アメリカ政府や大手企業はSHA1は使わない、としています。
Slashdot.orgにまた載っているので更に高速化できた、ということか?
参考：
PostgreSQLでSHA1
MS Access 2003でSHA1を使おうと思ったらどうもうまく動作しませんでした。
.NETのmbcorlibにMD5,SHA1等のハッシュ関数が定義されていてVBからはMSDNに書いてるサンプルで動作するのですがMS AccessのVBAからはいろいろ試しても動作しませんでした。サンプル通りだとオブジェクトを生成する行でシンタックスエラーになり、多少変更しても動作しませんでした。
# 普段VBAでプログラミングはしないので私が無知なだけかもしれませんが…
# Windowsプログラマの方はハッシュはあまり使わない??
VBAでハッシュが使える方が良かったのですが、しかた無くPL/Pythonでハッシュ値を取得し返す関数を定義することにしました。
PL/Pythonの場合、
CREATE OR REPLACE FUNCTION SHA1HASH( TEXT ) RETURNS CHAR(40) AS ‘
import sha
hash = sha.new( args[0] )
return hash.hexdigest()
‘ LANGUAGE plpythonu;
言語を登録していない場合
CREATE LANGUAGE plpythonu;
を先に実行しておきます。8.0からplpythonはplpythonuに名前が変更されています。（Untrustedな言語なのでuが付く）
PL/Perlの場合は多分こんな感じ（こちらは試していません）
CREATE OR REPLACE FUNCTION SHA1HASH( TEXT ) RETURNS CHAR(40) AS ‘
use Digest::SHA1 qw(sha1);
return sha1($args[0]);
‘ LANGUAGE plperl;
同じようなコードでMD5, SHA256, SHA512等が簡単に作れます。
普通パスワードはハッシュ化したパスワードを保存するのでユーザ情報テーブルのパスワードフィールドはハッシュ値になっています。
SELECT * FROM user WHERE username = ‘USERNAME’ AND password = sha1hash(‘PASSWORD’);
といった感じでクエリできるようになります。アプリの言語側でハッシュが使える場合はアプリ側でハッシュ化する方が好ましいのですがVB等でライブラリが制限されている場合には便利かも知れません。
なぜPHPアプリにセキュリティホールが多いのか?
技術評論社の新サイトで「なぜPHPアプリにセキュリティホールが多いのか?」をテーマにブログ風の記事を掲載させていただく事になりました。第一回は「CVEでみるPHPアプリケーションセキュリティ」です。
http://gihyo.jp/serial/2007/php-security/0001
CVEをフォローしている方であればPHPアプリケーションの脆弱性レポートの多さが目立っていることはよくご存知と思います。何故CVEエントリが多いのか解説しています。よろしければご覧下さい。
技術評論社の須藤さんに編集していただいているので私が書いた文章より読みやすいです。
今、気が付いたのですが、SecurityForcusに次の様な記載がありました。
The problem is, PHP applications accounted for about 43% of the security issues in 2006, according to the National Institute of Standards and Technology (NIST).
http://www.securityfocus.com/columnists/427
数えると凡そ半分と言っても良いくらいPHPアプリの脆弱性レポートがあったのですね。
b2evolution 1.8.6にXSS脆弱性
このブログのb2evolutionは1.9.1なので、1.9.1のコードを確認してみたところ、1.9.1にも厳格な入力チェックが行われていないなど、確かに好ましくない処理が行われていました。XSSと言うよりHTTP Response Splittingに脆弱なコードになっていました。
攻撃を成功させるには幾つかの条件が必要でした。
- 普通のクロスサイトスクリプティングであるため、ログインするページを表示する場合に他人が用意した罠ページのログインリンクをクリックしないとならない
- その後、ログイン操作を実際に行わなければならない
- PHPのバージョンが古くheader関数が脆弱である
特に重要なのはPHPのバージョンが古くなければならない点です。PHP 4.4/PHP5.xなら問題ありません。このサーバで利用しているPHPも大丈夫なので対処は行っていません。
例えばRHEL 4はPHP 4.3なので攻撃が成功するかも知れません。(パッチを確認すれば脆弱性を攻撃できるか直ぐ分かるのですが未確認）いずれにせよ、公開用のPHPスクリプトを書く場合、比較的古いバージョンのPHPも広く利用されている事を前提にコーディングしなければならないです。
この脆弱性の危険度はCVEでHighになっていますが、SecuniaではLowになっています。どちらに設定するかは微妙なところです。環境が古ければ「非常に危険」と考える事もできますが、現在PHPプロジェクトが正式にサポートしているバージョンは4.4と5.2で両方とも影響を受けません。
話は変わりますがb2evolution 1.9.1は使わない方が良いかも知れません。正規表現に問題があるらしくアンカータグが正しく処理できない事がよくあります。本家サイト見るとサポートされているバージョンが1.8系と1.9系だけになっているのでバージョンアップを考えている方は1.8系を先に試す事をお勧めします。1.8.6で正しく表示されるかどうかは検証していませんが、少なくとも1.9.1は問題が多いです。
クライアントサイドで認証とは… 在りない事が起きるのがWebサイト…
「Macworldサイトのハッキングでジョブズ氏講演の優待席を無料ゲット 」したハッカーがいるらしい。なんと認証がクライアント側で行われていたそうです。
ありえない…
Adobe Readerは8にバージョンアップ
1月3日付けでAdobe Readerの脆弱性が報告されています（CVE-2007-0044、CVE-2007-0045、CVE-2007-0046、CVE-2007-0047）
Name: Adobe Reader Open Parameters XSS
Date first reported: 1/3/07
Vulnerable software: Adobe Reader plug-in versions 6 and 7 for Mozilla Firefox, Opera and Microsoft Internet Explorer.
What it does: Could allow denial of service (crash), remote access and execution of malicious code.
Recommendations: Upgrade to Adobe Reader 8
Exploit code available: Yes
Vendor patch available: Yes
詳し解説はリンク先を見ていただくとして、次のようなリクエストで任意のJavaScriptが実行できてしまうようです。
http://www.(domainname).com/file.pdf#whatever_name_you_want=javascript:your_code_here
としてどこのドメインでもXSSが可能になるようです。
# PDFが全くないサイトなら大丈夫とは思いますが…
サイト側では対処の方法がないように思えます。
# 相変わらず自分で検証する時間がない…
追記：
PDFとして処理させない事になりますが.pdf に対して application/octet-stream を指定すると大丈夫なようです。
プラグインつながりで、ついでに書くと最近色々見つかっています。
CVE-2007-0015
Buffer overflow in Apple QuickTime 7.1.3 allows remote attackers to execute arbitrary code via a long rtsp:// URI.
他にはIE7+FlashでDoS（CVE-2006-6827）、IE7+RealPlayerでDoS（CVE-2006-6847）が可能などが見つかっています。常々、プラグインは危ない、と言っていますが普通のユーザはあまり意識していないですね…
インストールされたプラグインを使って攻撃する方法は色々ありますが、Flashは結構攻撃使えるプラグインだと思います。本当のサイトをFalshで作り直してフィッシングするケースも見かけられるようになったそうです。フィッシングツールなどでページコンテンツの分析を回避する手法としてFlashで作り直しを行っています。スパムメールと同じですね。
JavaScriptのソースに重要なデータを埋め込むなんて….
GmailでJavaScriptのソースとしてコンタクトリストデータを埋め込んでいたため、第三者がコンタクトリストを盗めてしまう、という問題が話題になっています。
まだ詳しく調べていませんがsrc属性に指定されたソースは誰でも（どのサイトからでも）取得できるブラウザの仕様を利用したものだと思います。
比較的早くからsrc属性で他のサイトのJavaScritpが指定できる仕様のリスクは指摘されていました。Gmailでさえ重要なデータをJavaScriptのソースに埋め込んでいるのですからAjaxアプリケーションの多くに同じ脆弱性があるような気がします…
手っ取り早く不完全な方法で修正するにはリファラチェック、きちんと修正するならJavaScriptのリクエストに鍵を付けてチェックする、といった方法で対策可能です。
http://example.com/javascript_contains_sensitive_data.js?key=123456789
と言った感じです。
# 鍵を付ける場合、セッションIDを鍵にしてはいけません。
# セッション変数にランダムな鍵を設定してチェックすると良い
# です。