クロスサイトスクリプティングを防ぐための10のTipsをgihyo.jpのブログに載せました。
Webサーバの設定になるので書いてませんがApacheなどでも明示的に文字エンコーディングを指定した方が、誤って違った文字エンコーディングで静的コンテンツを書いてしまった場合でも分かるのでよいと思います。
AddDefaultCharset utf-8
などとhttpd.conf/仮想ホストの設定ファイル、.htaccessなどに記述すると静的なコンテンツにも文字エンコーディングをHTTPヘッダレベルで指定できます。
あまりやらないと思いますが11番目を追加するなら「VBScriptを動的に生成する場合に注意を払う」あたりだと思います。
追記: 攻撃が目的の改竄だった模様です。
http://blog.ohgaki.net/index.php/yohgaki/2007/12/16/squirrelmail-1
—-
http://squirrelmail.org/index.php
によると、12/8にSquirrelMail 1.4.12のコードが改竄されていたようです。
While we believe the changes made should have little impact, we strongly recommend everybody that has downloaded the 1.4.12 package after the 8th December, to redownload the package.
The code modifications did not made it into our source control, just the final package. We are currently investigating older packages to see if they were also compromised.
攻撃用のコードは含まれていなかったようです。攻撃コードが含まれなかったのであれば、攻撃者は「パッケージを改竄してどの程度で改竄された事実が判明するかを検証する」等の目的を持っていたのだと思われます。
GNUのFTPサーバがクラックされた事例を思い出します。MD5などのシグニチャは必ずチェックするようにした方がよいのは当り前ですが、MD5やSHA1ハッシュの重要性を再認識してもらうにはよい機会かもしれません。
混乱を避けるためにSquirrelMail 1.4.13がリリースされています。
http://squirrelmail.org/download.php
新しいパッケージはGnuPGでもサインされています。
gpgでサインされた署名をチェックするには鍵を取得しなければなりません。gpg署名の確認方法を書いておきます。パッケージとそのパッケージに対応したgpg署名をダウンロードします。
[yohgaki@dev download]$ gpg –verify squirrelmail-1.4.13.tar.bz2.sig
gpg: 2007年12月15日 02時17分49秒 JSTにDSA鍵ID F8FD1F73で施された署名
gpg: 署名を検査できません: 公開鍵が見つかりません
鍵がないので署名が検証できません。鍵ID”F8FD1F73″で署名されているので取得します。
[yohgaki@dev download]$ gpg –keyserver pgp.nic.ad.jp –recv-key F8FD1F73
gpg: 鍵F8FD1F73をhkpからサーバーpgp.nic.ad.jpに要求
gpg: 鍵F8FD1F73: 公開鍵“Jonathan Angliss <jon @netdork.net>”を読み込みました
gpg: 最小の「ある程度の信用」3、最小の「全面的信用」1、classic信用モデル
gpg: 深さ: 0 有効性: 1 署名: 0 信用: 0-, 0q, 0n, 0m, 0f, 1u
gpg: 次回の信用データベース検査は、2009-02-05です
gpg: 処理数の合計: 1
gpg: 読込み: 1
この公開鍵を利用してもう一度チェックすると正しい署名であることが確認できます。
$ gpg –verify squirrelmail-1.4.13.tar.bz2.sig
gpg: 2007年12月15日 02時17分49秒 JSTにDSA鍵ID F8FD1F73で施された署名
gpg: “Jonathan Angliss <jon @netdork.net>”からの正しい署名
gpg: 別名“Valcor <valcor @netdork.net>”
gpg: 別名“Netdork Abuse <abuse @netdork.net>”
gpg: 別名“Netdork Sales <sales @netdork.net>”
gpg: 別名“Netdork Support <support @netdork.net>”
gpg: 別名“Jonathan Angliss <jon @squirrelmail.org>”
gpg: 別名“Netdork Security <security @netdork.net>”
gpg: 別名“Jonathan Angliss <jangliss @aaxchange.com>”
gpg: 警告: この鍵は信用できる署名で証明されていません!
gpg: この署名が所有者のものかどうかの検証手段がありません。
主鍵の指紋: 676A 1701 665B E343 E393 B8D2 2B83 E814 F8FD 1F73
警告が表示されているのは先ほど取得した公開鍵にサインしていないからです。「“Jonathan Angliss <jon @netdork.net>からの正しい署名」となっているので問題ありません。気になる場合は公開鍵を署名すれば警告メッセージは表示されなくなります。
公開鍵の署名は以下のリンクが参考になります。
http://homepage.mac.com/mio_rhapsody/gnupg/GnuPG_ShellScript.html#SignKey
http://www.securiteam.com/unixfocus/6N00D0AKKM.html
に解説されている脆弱性は基本中の基本です。
Most database query in WordPress uses escape() method to sanitize SQL string, which is essentially filtering input via addslashes() function. However addslashes() fails to consider character set used in SQL string, and blindly inserts backslash before any single quote, regardless of whether such backslashes will form another valid character or not.
addslashes()によるエスケープは行ってはならない、とよく言っていますがWordPressでさえaddslashes()を使っていたのですね。WordPressはUTF-8だけでなくGIB5とか使えるのですね。WordPressをSJISを使っている方は同じ脆弱性があるので要注意です。
本質的には私のブログでも指摘している脆弱性と同じ種類の問題です。
追記
CVEが出てます。
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-6318
(1) Big5, (2) GBK, or possibly other character set encodings that support a “\” in a multibyte character.
BIG5, GBKエンコーディングが影響を受け他の文字に¥が現れる文字エンコーディングにも影響があると思われる、と書いてあります。つまりSJISが該当します。
対策を書いておきます。
別の対策として、プリペアードクエリを利用する方法もあります。
壊れた文字エンコーディングの文字列を無理矢理扱えるようにする方法があります。しかし、壊れた文字エンコーディングを扱えるようにするとアプリケーションや環境に存在する未知の脆弱性により攻撃可能になるかもしれないリスクがあります。壊れた文字エンコーディングを扱えるようにするのではなく、既にあるデータは綺麗にして、新しい文字データは全て正しい文字エンコーディングであるように入力時にバリデーションすべきです。
パスワードの解読にも『PS3』が活躍
http://wiredvision.jp/news/200711/2007113023.html
PS3で米大統領選の結果を「正確に」予知?…実はMD5脆弱性への問題提起
http://slashdot.jp/security/07/12/02/1931233.shtml
PS3は演算処理性能が高くFoldings@HomeのClient statistics by OSをみるとPCの値に比べおよそ26倍の性能した。
「パスワードの解読にも『PS3』が活躍」の記事では100倍の性能を達成とあります。この100倍が意味するのはランダムな文字列の難しいパスワードを解読するのに100年かかっていたのが1年で済む、1000時間かかっていたのが10時間で済む、と言うことです。時間的にクラッキングが実用的ではなかった物が十分実用的になったと言えます。
「PS3で米大統領選の結果を「正確に」予知?…実はMD5脆弱性への問題提起」はアルゴリズムとハードウェアの向上により、数年前から予測されていた「同じMD5値を生成する事は簡単になる」状態になったことが実証された事になります。
Microsoft等のソフトウェア会社大手では随分前にMD5の利用を止めています。SHA1が同様な状態になるまではまだまだ時間が必要ですが時間の問題となってきたのかも知れません。
ところで、Webシステムの中にはいまだにパスワードをプレインテキストで保存している所が多数あります。メールで「パスワード」を教えてくれる大手サイトも少なくありません。最低限、SHA1ハッシュでパスワードは保存しましょう… できればsalt付きで。
パスワードの最大文字数が少なすぎるサイトも稀に見かけます。パスワード文字列が少なすぎるサイトなら簡単にクラックされる可能性があります。256バイトくらいは入力できるようにしておいた方が良いでしょう。数年前の研究結果だったと思いますがその論文によると、文章になっている長い文字列のパスワードの場合、辞書に載っている単語ばかりを利用していても十分な強度持っているとされていました。
PHPで実装されたベイズフィルタを見かけました。
http://www.atomicmpc.com.au/forums.asp?s=2&c=10&t=4466
ライセンスはGPLライセンスです。
ソースコードを見ると当然ですが半角スペースでトークンに分解しているので日本語では使えません。しかし、mecabなどを使用して使えるようにするのはそう難しくありません。もともとベイズフィルタは難しいアルゴリズムではないので読むと直ぐに理解できると思います。PHPで利用できる形態素解析モジュールは幾つかあります。
しばらく前には毎日数百のコメントスパムが送信されてきていました。b2evolutionデフォルト設定でコメントのモデレートが必須化されてから時間が経過してきたので今はかなり減ってきています。必要性は減ってきてはいますが時間があったら改善したい所です。
NTOSpider, AppScan, WebInspectとメジャーなWebアプリスキャナの性能を比較した方がいるようです。結果のPDFは以下のURLです。
クリックしてCoverageOfWebAppScanners.pdfにアクセス
Forty Tracerを使ってスキャン中のコード実行カバレッジを利用してアプリケーションスキャナの性能を評価しています。
結論はNTOSpiderがダントツの性能のようです。AppScan、WebInspectは同じ程度となったようです。いずれにせよWebアプリスキャナは「セキュリティを維持」する為のツールではなく「最低限のセキュリティが維持できているかチェック」する為のツールなので多少の性能差ならそれほど気にする必要はないでしょう。しかし、多少と言える性能差ではないのでIBMとHPには頑張ってもらいたい所です。
J2EEアプリが対象との事ですが脆弱性だらけ(NTOSpiderは200以上の脆弱性を見つけている）と判定されたOpenCMSとはどれの事なのでしょうね?
http://www.opencms.jp/
なのは確かだと思いますが、どのバージョンを使ったか書いていないようです。
ちなみにSecuniaのデータベースだとOpenCMSにはそれほど脆弱性が登録されていません。
http://secunia.com/product/6531/?task=advisories
単純に誰もセキュリティチェックしていないだけなのかも知れません。Javaアプリなので個人が気軽にCMS、といった形でなく企業が使っている可能性が高いと思われます。使っている方は念のために自分でチェックした方が良いかも知れません。
# JSPWikiといい、Javaベースのアプリにも問題が多い予感がします。
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5340
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5339
によるとThunderbird 2.0.0.8でDoS脆弱性が修正される、とされています。もうリリースされているのかな?
と思って
http://www.mozilla.com/en-US/thunderbird/
を見たのですがまだのようです。
DoSなので緊急性は低いはずです。Thunderbirdプロジェクトは独立するとさらにメンテナンス状態が悪くならないか心配です。OSXのMailにでも移行しようか、とも思いますがこれも今ひとつ信用できません。しばらくは様子見です。
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5380
Session fixation vulnerability in Rails before 1.2.4, as used for Ruby on Rails, allows remote attackers to hijack web sessions via unspecified vectors related to “URL-based sessions.”
これはお馴染みの問題です。
http://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-5379
Rails before 1.2.4, as used for Ruby on Rails, allows remote attackers and ActiveResource servers to determine the existence of arbitrary files and read arbitrary XML files via the Hash.from_xml (Hash#from_xml) method, which uses XmlSimple (XML::Simple) unsafely, as demonstrated by reading passwords from the Pidgin (Gaim) .purple/accounts.xml file.
これもよくある問題です。
RoRには幾つか脆弱性が報告されているので少なくとも1.2.4にはバージョンアップした方が良いです。
PCを乗っ取れる脆弱性がある、とされていたAdobe Reader/Acrobatですがパッチがリリースされた模様です。
Adobe Acrobat
http://www.adobe.com/support/downloads/product.jsp?product=1&platform=Windows
Adobe Reader
http://www.adobe.com/support/downloads/product.jsp?product=10&platform=Windows
• Close a potential security vulnerability on Windows® XP computers that have Internet Explorer 7 installed (CVE-2007-5020); see the Adobe Security Bulletin (APSB07-18) concerning this issue
• Address several PDF forms-related issues
• Provide additional stability
APSB07-18
Critical vulnerabilities have been identified in Adobe Reader and Acrobat that could allow an attacker who successfully exploits these vulnerabilities to take control of the affected system. This issue only affects customers on Windows XP with Internet Explorer 7 installed. A malicious file must be loaded in Adobe Reader or Acrobat by the end user for an attacker to exploit these vulnerabilities. It is recommended that affected users update to Adobe Reader 8.1.1 or Acrobat 8.1.1. This is an update to resolve the issue previously reported in Security Advisory APSA07-04.
重要な箇所はWindows XPでIE7を利用しているシステムのみ影響するとしている部分です。VistaユーザやXP+IE6なら影響ないとされています。
# RedHatによるとRHELなどのLinux環境にも影響が無いとされています。
CVSS2.0のスコアを見てわかるように非常に危険なセキュリティ上の問題とされています。
CVE-2007-5020
CVSS Severity (version 2.0):
CVSS v2 Base score: 9.3 (High) (AV:N/AC:M/Au:N/C:C/I:C/A:C) (legend)
Impact Subscore: 10.0
Exploitability Subscore: 8.6
とりあえずハンドラの問題を回避する方法は
http://isc.sans.org/diary.html?storyid=3477
既知の問題が全部直っているのかな?と思ったら根本的な原因は以下
http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-3896
にあるような感じです。
ところでRealPlayerをインストールしている方は少ないと思いますが、0day攻撃されているようです。ほとんど必要ない物なのでアンインストールしておきましょう。
追記：
ZDNetによるとこの脆弱性を利用しWindowsファイアーウォールを無効にする攻撃がSymantecにより観測されている、と記載されていました。パッチが必要なシステムは早めにパッチを適用した方が良いと思います。
ちょっと気になったので…
記事はコラム形式だったので書いていないだけだと思いますが2つ問題があります。
1. 識別可能なフォームの数に限りがある
セッション変数を利用しているため変数名でフォームを識別する必要があり、ユーザが複数のフォームを利用した場合、正しく動作しない。この制限をなくす事もできますが、その場合セッション変数が大きくなりすぎた状態に対処するようにしないとならくなります。（ガーベッジコレクションの実装が必要）
2. レースコンディションによる2重投稿の可能性がある
コードを見て分かる通り
if (isset($_POST['submit_button'], $_SESSION['ticket'], $_POST['ticket']) && $_SESSION['ticket'] === $_POST['ticket']) {
unset($_SESSION['ticket']);
セッション変数の状態チェックと状態の変更がアトミックに行えないため、稀なケースとは言えますが、レースコンディションにより2重送信の可能性があります。
この様な変数の状態の確認と変更はアトミックな処理が必要になります。
Webサーバが一つならセマフォを使えますが、複数のWebサーバを利用する場合、トランザクションをサポートしたDBサーバを利用します。（APサーバ間でトランザクション、と言う方法もありますがDBサーバを利用した方がスケーラブルです）
私のPHPの本、セキュリティの本でもこの方法を2重送信・CSRF対策として紹介しています。
敵国の通信ネットワークに侵入して敵軍のセンサーが見ているものを見ることができるほか、システム管理者を偽装してシステムを乗っ取り、センサーを操作して、接近する航空機の姿を見られないようにすることができるという。
敵側の送信機の位置を正確に突き止め、偽ターゲットや、虚偽のメッセージ・アルゴリズムをシステムに流し込んで、システム制御をはじめとするさまざまな活動を可能にすることも可能だ。
そんなに簡単に制御できてしまう物なのか？と思ってしまいますが。ネタとして。
yohgaki’s blog – サーバシグニチャは隠すのが当たり前
http://blog.ohgaki.net/index.php/yohgaki/2007/09/04/a_ma_fa_a_ma_da_a_a_pa_me_na_a_ra_af_a_a
に対するコメントを見つけました。このブログに対するご意見は探したことがないので、たまたま見つけたこのブログが初めてくらいだと思います。「サーバシグニチャは隠さないのが当たり前」とするご意見です。
なぜサーバのバージョン情報を公開する必要があるのか。それは、クライアント側で、サーバのバグや規格解釈の相違に起因する問題を回避するためです。
「当たり前」とするには理由が弱いと思います。サーバ側はサービス提供者が自由にコントロールできる要素です。サーバがオプションとして送信する特定のヘッダを送信しようとしまいと正しく処理できるようにするのはブラウザの責任です。最悪の場合、サーバは攻撃用のヘッダを送信してくるかも知れません。サーバシグニチャが100KBもあるヘッダなどが送信されても問題が発生しないようにするのはブラウザ側の責任であるのと同じです。
クライアント側で「サーバのバグや規格解釈の相違に起因する問題を回避」している場合があるは知っていまたが決定的と言える問題ではありません。Pipelineは使えないと多少効率が落ちるだけです。（サーバ側では別にPipelineをサポートしないからといって、負荷が軽減するものでもありません。）Pipelining以前に、より多くのクライアントに安全にデータを送信するためにKeepAliveさえ無効に設定しているサイトもまだまだ多いでしょう。(i.e. HTTP Response Splitting) Pipeliningは一例かと思いますが、これを持って「サーバシグニチャは隠さないのが当たり前」とするには不十分だと思います。もしかすると私が知らない決定的な問題があるのかも知れませんが、その場合は教えていただけると有難いです。
クライアント側がユーザエージェントヘッダを「送信するのが普通」だと思いますが、送るのが「当たり前」だとは思いません。それはユーザの自由です。同じように「JavaScriptを無効」にするのもユーザの自由です。「最近JavaScriptが有効なのが当たり前」なサイトが増えていますが、全てのWebサイト開発者はWCAGをよく読むべきです。WCAGはJIS規格にも採用されています。ユーザビリティだけの問題でなく、より安全にWebを利用するためにJavaScriptを無効にするのはずいぶん当たり前になりつつあります。
画像を表示できないテキストブラウザでWebサイトを参照するのも自由で有るべきです。文字を表意しない音声ブラウザでWebサイトを参照するのも自由で有るべきです。たとえ十分に利用できない可能性があっても「あなたのブラウザでは参照できません」と門前払いをすべきではありません。
とにかく、サーバシグニチャを隠すのも、インストールされている全てのモジュールのバージョンまで含めて隠さないのもサーバ管理者の「自由」です。
http://memo.hirosiki.jp/article/54026897.html
結論：
サーバシグニチャを出さないことでは確かにウノウの言うようなセキュリティレベルの向上は“それほどは”得られないが、だからといって出さないことがクソだのタコだの言うのはバカ。
多少言葉は悪いですが、両方の意見に対してかかれたこのブログのメリット・デメリット、結論は理解できます。
サーバシグニチャに詳しいサーババージョンを書かないのはセキュリティレベルを向上させると言うよりは「犯罪者のデータベース作成に協力しない」ことが私としては1番目の目的です。この対策は役に立たないかも知れませんが、役に立つかも知れない、といった対策です。採用するかしないかは管理者（またはセキュリティポリシー）次第です。攻撃され辛くする対策は根本的なセキュリティ対策とは言えないかもしれませんが、多くの場合それで十分である事も事実です。例えば、家の玄関ドアの鍵を2つにする、割れにくい窓ガラスにする、などは泥棒（攻撃）対策に有用であるとされています。完璧なセキュリティ対策でなくても十分有効に機能する例は多くあります。
ちょっと脱線します。UserAgentを参照し、IE, Fireforxの各バージョンの脆弱性に合わせた攻撃を行い、脆弱性がないUserAngetの場合攻撃を行わないWebサイトも実存します。ブラウザのUserAgentを送信しない、または正しいUserAgentを送信しないのは普通とは言えませんが、実際にこうした攻撃が有る以上、「送信するのが当たり前でしないのはNG」とするのは問題があると思います。余計(?)なヘッダ情報は実際に攻撃に利用されているのです。
クライアント（ブラウザ）を作る人、Webアプリを作る人、はそれぞれサーバ、クライアントには「十分な自由度」があるように作らなければならないと考えています。
「うちのサイトはIEのみでVBScriptが有効なブラウザしか使えない仕様」にするのもサイト運営側の自由です。万人向けでは無いサイトを作るのも自由ですが、広く一般に公開しているサイトであるにも関わらず万人向けサイトではない無い場合、そのことを明記するべきです。特に責任ある企業のサイトなら尚更です。
話を戻しますが、Webサーバとモジュールの安全性に100%の自信があれば詳しいサーバ構成を記述したヘッダを送信することに異論はありません。 安全性に不安を持っている（100%の信頼を持っていない）システム管理者であれば「(特に懇切丁寧な）サーバシグニチャは送信しないのは当たり前」だと思っているだけです。私のブログからも分かるように私の立場は「100%信用していないのでシグニチャは隠すのが当たり前」と考えています。
最近は攻撃の高度化、ステルス化が進んでいます。昔のように手当たり次第で直ぐ分かるような攻撃は少なくなり、システム管理者が気が付かない方法で攻撃してきます。仮に自分が犯罪者でWebサーバやそのモジュールの脆弱性を利用して乗っ取れる0Day攻撃手法を発見した場合、手当たり次第に攻撃するのではなく、できるだけサーバ管理者に気づかれないように細心の注意を払って攻撃します。その攻撃に利用する重要な情報の一つがサーバシグニチャです。サーバを乗っ取った後、カーネルレベルルートキットをインストールするためにフィンがープリンティングでサーバが利用しているOSとそのバージョンも調べるでしょう。カーネルレベルルートキットをインストールすれば、ルートキットのファイル・プロセス・ネットワーク接続が参照できなくなるのでIDS/IPSをゲートウェイなどにインストールしていなければ検知するのは極めて困難になります。水際で攻撃を防止する重要性はますます増加しています。
ほとんど全てのセキュリティ対策にはメリットとデメリットがあります。セキュリティポリシーはそのバランスをどこに設定するのか決めるものです。便利なシステムを利用している以上、リスクは受け入れなければなりません。どのリスクを受け入れ、どのリスクを軽減し、どのリスクを排除するかはセキュリティポリシーで決めます。
# 正しくリスクを識別すること（リスクアセスメント）がセキュリティ対策
# では非常に重要です。リスクを識別できなければ、組織やサービスが必要
# としているセキュリティポリシーは策定できません。
# Pipelineとかは本来はプロトコルバージョンで判別できれば良い機能だと
# 考えています。現実的にはHTTP/1.1.1とかすると誤作動するソフトウェアが
# 山ほど有るので無理ですが。サーバソフトの種別で判別するべき機能ではあ
# りません。時間が解決するのでそれまでpipelineは使わなければ良いだけの
# 機能です。ブラウザにはそういった機能は山ほどあります。E4X、CSS、DOM
# とか。
# そういえば最近Citrixのおかげで筒抜けになっているサイトが多数ある、と
# 話題になっていましたね。別問題と言われるかもしれませんが、べつにどう
# でもよいサーバシグニチャを隠すくらいの気遣いをする管理者であれば、
# こんな間違いは起きなかった可能性が高かったのではないか、と思っています。
#「JavaScriptを有効にしておくくらい当たり前」とユーザに強制するのであれ
# ば「100%安全なWebサイトを提供するのが当たり前」と言われても仕方ありま
# せん。100%安全性は絶対に保証できないので「どのようなクライアントでアク
# セスしても、必要最小限はナビゲーションできて当たり前」と考えています。
# 少なくとも「このサイトはJavaScriptを利用しているのでJavaScriptを有効
# にしてください」とメッセージを表示すべきです。noscriptタグを入れるの
# が面倒だとは思えません。
「あたり前」論には少なからず主観が含まれます。「あたり前」とか「常識」は主観無しにはあり得ないからです。従って、一つの「あたり前」には反対の「あたり前」もあります。どれを「あたり前」とするか、もしくはしようとするかは個人のセンスだと思います。
書かない日記のはずがつい書きすぎてしまいました。書きたい事は山ほどある
のですが、今日はこの辺で。
私が知らなかっただけかもしれませんが、これにはかなり驚きました。いろんな所で問題が指摘されていますが、ECMAScriptにXML機能を追加したのはどうなんでしょうね…. 確かにかなり便利なのですが以下のコードでスクリプトが実行されることはほとんど知られていないでしょうね。
<script>
123[”+<_>ev</_>+<_>al</_>](”+<_>aler</_>+<_>t</_>+<_>(1)</_>);
</script>
好むと好まざる関係なくFirefox 1.5から使えるのでWeb開発者は知っておかなればならないです。
日本語訳
http://www.ne.jp/asahi/nanto/moon/specs/ecma-357.html
原文
http://www.ecma-international.org/publications/standards/Ecma-357.htm
しかし、E4Xのアッタクベクタは色々ありそうですね。
追記：新しくより安全なバージョンはこちらです。
hoshikuzuさんのページに書いてあるJavaScript文字列のエスケープ方法です。（元ネタのメールアーカイブは文字が欠落）
http://d.hatena.ne.jp/hoshikuzu/20071011#p1
1. 「¥」を「¥¥」に置換する
2. 「”」を「¥”」に置換する
3. 「’」を「¥’」に置換する
4. 「/」を「¥/」に置換する
5. 「<」を「x3c」に置換する
6. 「>」を「x3e」に置換する
7. 「0x0D（CR)」を「¥r」に置換する
8. 「0x0A（LF）」を「¥n」に置換する
SmartyのJavaScirpt文字列のエスケープ方法です。
CVS版：2007/10/12
case ‘javascript’:
// escape quotes and backslashes, newlines, etc.
return strtr($string, array(‘\\’=>’\\\\’,”‘”=>”\\'”,'”‘=>’\\”‘,”\r”=>’\\r’,”\n”=>’\\n’,'</’=>'<\/’));
strtrで置換しているので元々文字エンコーディング攻撃に脆弱ですが、クローズタグだけ考慮している部分、/、<、>の取扱いが異なります。<, >はHEXで表記した方が安全ですね。
文字エンコーディングの問題は随分前から気づいていましたが、この手の修正は受け入れられる可能性が低いですからね…（文字エンコーディングが壊れていなければほとんどの文字エンコーディングで大丈夫なはず。例外はSJISかな）いずれにせよJavaScriptをダイナミックに生成するのはお勧めしません…
JavaScriptはクライアントサイドなので、確実かつ安全なエスケープ方法、は簡単ではありませんから。
リンク先のフォーラムによるとページ改竄が可能なWebサイトのAdSenseを自分のIDに改竄してしまう、という直接的な攻撃が行われ始めたようです。
小規模なサイトなら「自分の広告が表示されている、と思っていたら他人の広告だった」と気がつくまでには1カ月くらいは必要かもしれないので多数のWebサイトに仕掛ければ小銭稼ぎくらいはできるかも知れません。実際、実験用にこのブログにもAdSense広告を張り付けていますが、広告収入がどれくらいなのかほとんどチェックしていません。（というよりチェックしたくなるほどの広告収入にはなりません）
小銭、といっても月数万円にほどになれば発展途上国ではクラックする十分な動機になります。日本の場合、言語障壁が高いので欧米に比べればリスクは高くは無いと考えられます。
日本でもこの手の被害は発生しているのかな?