Mac miniがCore2Duoに

クライアントサイドでのXSS対策

詳しくはリンク先を見て頂くとして、XSSは

• クライアントサイドで発生する
• 通常JavaScriptで発生する

と言う点着目してスクリプトにサインを付けクライアント側でもXSSを検出しようと言う話です。フェイルセーフ対策としては有用だと思います。Flash, PDF, Javaなどのオブジェクトにもサインすればより良いと思います。サインさえ付けておけばあとは決まったJavaScriptコードを全てのページに追加するだけなのでそれほど難しい対策ではありません。

カラーレザープリンタの印刷物に埋め込まれたコード

コピーすると「COPY」と印刷されてしまう機能は有名です。
コピー機、PhotoShopの紙幣複製を防止する機能も知っていましたが

カラーレーザープリンターで印刷されたものには全てこのように肉眼では判別し難い黄色いピクセルをバーコード（大きさは8×15ピクセル）のように印字することによって、プリンターのメーカー名、機種名、シリアル番号、印刷された日時の4つの情報を合計15バイトの情報としてコード化して埋め込まれているという。

プリンタ、コピー機業界では常識なのかもしれませんが知りませんでした。
# どこかで聞いたことがあるような気もしますが覚えてませんでした。

このバーコード、日本国内で販売されているカラーレーザープリンターでも印刷物にブラックライト（紫外線ランプ）を当てて丹念に調べれば肉眼で確認することができるという。

ブラックライトを持っていないので確認できません…

この機能、全うな目的で印刷する人には何の問題もありませんが不正な目的で印刷しようとする人を思いとどまらせる為に役立つかも知れません。印刷ログを残しておけば時間とプリンタでユーザまで特定できます。すべてのプリンタ、コピー機に入れても良いと思いますがどうでしょう？似たようなセキュリティソリューションを購入する必要もなくなります。

この機能、やはりカラープリンタそれもカラーレーザープリンタ向きの機能だと思うので、問題は全てのプリンタをカラーレーザープリンタにするのは導入とランニングコストがかかり過ぎることくらいでしょうか？

白黒コピー機でコピーしてもこのコードは読めるのかどうか気になります。多分読めないとは思いますが。

BIND9のDNSキャッシュ汚染

BIND9にDNSキャッシュ汚染の脆弱性だそうです。

The paper shows that BIND 9 DNS queries are predictable – i.e. that the source UDP port and DNS transaction ID can be effectively predicted. A predictability algorithm is described that, in optimal conditions, provides very few guesses for the “next” query (10 in the basic attack, and 1 in the advanced attack), thereby overcoming whatever protection offered by the transaction ID mechanism. This enables a much more effective DNS cache poisoning than the currently known attacks against BIND 9. The net effect is that pharming attacks are feasible against BIND 9 caching DNS servers, without the need to directly attack neither DNS servers nor clients (PCs). The results are applicable to all BIND 9 releases [1], when BIND (the named daemon) is in caching DNS server configuration.

まだ中身を見れていないのですが、最適な条件であれば基本的な攻撃で10回、高度な攻撃で1回で次のトランザクションIDを推測できる、としています。最適な条件がどれくらいあるのか？は読んでみないとわからないです。

All stable versions of BIND 9 to date (except the ones released simultaneously with this paper) are vulnerable, i.e. BIND 9 versions 9.4.0-9.4.1, 9.3.0-9.3.4, 9.2.0-9.2.8, 9.1.0-9.1.3 and 9.0.0-9.0.1.

とあるので、BIND9の最新版では問題は修正されているそうです。 http://www.isc.org/index.pl を見ると確かに今月リリースの9.xが紹介されています。

CVEはこれ
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-2926

BIND8, BIND4には影響がないとされています。

$intval * 1でサニタイズ…

たまたま見たPHPのコードでSQL文中の整数値を

$intval * 1

として整数型にするサニタイズがありました。この方法をお薦めするわけではありませんが、以前のエントリ

http://blog.ohgaki.net/index.php/yohgaki/2007/07/04/example_1428_a_best_practice_query

でsprintf()の%dを使う方法よりはましです。

$ php -r “echo ‘99999999999999’ * 1;”
99999999999999

実行したマシンは32bitのLinuxシステムですが浮動小数点型に自動変換されるので2^31を越える値でも正しく表示されます。一方、PHPマニュアルの方法だと

$ php -r “printf(‘%d’, ‘99999999999999’ * 1);”
276447231

となってしまいます。最近のDBは大きなモノも珍しくないのでこの程度でオーバーフローするようでは安心できません。もっとも*1方式でもあと一桁増やすと

$ php -r “echo ‘999999999999999’ * 1;”9′ * 1);”
1E+15

と指数表記になるのでこれで十分とは言えません。しかし、マニュアルのベストプラクティスよりは良いです。printf系で処理するなら

$ php -r “printf(‘%1.0f’, ‘99999999999999’ * 1);”
99999999999999

これで十分なDBも多いとは思いますが、ダイナミックにSQL文を生成するのであれば文字列として渡してエスケープしてしまうと確実です。