月: 2007年10月

Webアプリスキャナの性能

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ベースのアプリにも問題が多い予感がします。

Thuderbird 2.0.0.8は何時リリースされる?

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にでも移行しようか、とも思いますがこれも今ひとつ信用できません。しばらくは様子見です。

RoR CVE

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にはバージョンアップした方が良いです。

Adobe Reader/Acrobatのパッチ公開

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重送信の防止…

ちょっと気になったので…
記事はコラム形式だったので書いていないだけだと思いますが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対策として紹介しています。

Parallels Desktopインストール後にVistaが起動しない場合の対処

BootcampのVistaのVMを訳あってVMWare FusionからParallels Desktopに切り替えようとしたのですが、VMからブートしなくなりました。VMWare Toolsは予めVMWare Fusionで起動中に削除しています。Parallelsが入力をトラップしてしまうのかOSXのマウスも

Bootcampで直接Windows Vistaを起動しようとすると、BUGCODE_USB_DRIVERとかいうメッセージがブルースクリーンなって出ていました。その後もう一度Bootcampからブートしようとするとprlfs.sysを読み込んだ時にブルースクリーン…

Parallels関係っぽいドライバなのでセーフモードのコマンドプロンプトからc:\windows\system32\drivers\prlfs.sysを削除するとブートできるようになりました。(とりあえずParallelsからブートして、Bootcampでのブートは試してません)

別に電源ボタン長押しで切っても大丈夫だと思いますが、Vistaにもshutdownコマンドがあるのでshutdown /sなどとするとシャットダウンできます。

コマンドは以下の通りです。システム管理者アカウントで実行

cd c:\windows\system32\drivers
del prlfs.sys
shutdown /s /t 0

ParallelsでWindows Vistaを起動後、Parallels Toolsを再インストールすると正常に動作すれば良いのですが、また同じ症状になりました。

最初にParallelsをインストールしたときも素直には動作しませんでした。VMWareに比べていろいろやり過ぎている(?)のか気の利いたツールや機能は多いのですが、VMWare Fusionと比べると安定性にはかなり劣る気がします。

防空システムをハッキングか

敵国の通信ネットワークに侵入して敵軍のセンサーが見ているものを見ることができるほか、システム管理者を偽装してシステムを乗っ取り、センサーを操作して、接近する航空機の姿を見られないようにすることができるという。

敵側の送信機の位置を正確に突き止め、偽ターゲットや、虚偽のメッセージ・アルゴリズムをシステムに流し込んで、システム制御をはじめとするさまざまな活動を可能にすることも可能だ。

そんなに簡単に制御できてしまう物なのか?と思ってしまいますが。ネタとして。

サーバシグニチャは隠さないのが当たり前?

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タグを入れるの
# が面倒だとは思えません。

「あたり前」論には少なからず主観が含まれます。「あたり前」とか「常識」は主観無しにはあり得ないからです。従って、一つの「あたり前」には反対の「あたり前」もあります。どれを「あたり前」とするか、もしくはしようとするかは個人のセンスだと思います。

書かない日記のはずがつい書きすぎてしまいました。書きたい事は山ほどある
のですが、今日はこの辺で。

いろいろ変わったXSSがありますが…

私が知らなかっただけかもしれませんが、これにはかなり驚きました。いろんな所で問題が指摘されていますが、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のアッタクベクタは色々ありそうですね。

JavaScript文字列のエスケープ

 

追記:新しくより安全なバージョンはこちらです。

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はクライアントサイドなので、確実かつ安全なエスケープ方法、は簡単ではありませんから。

IEの脆弱性

CVE-2007-3896は例のIEのバグでなくて呼び出し側のFirefoxの問題云々の件です。

The URL handling in Windows XP and Windows Server 2003, with Windows Internet Explorer 7 installed, allows remote attackers to execute arbitrary programs via invalid “%” sequences in a mailto: or other URI handler, as demonstrated using mIRC, Outlook, Firefox, Adobe, Skype, and other applications. NOTE: this issue might be related to other involving URL handlers in Windows systems, such as CVE-2007-3845.

結局、mIRC、Outlook(これ以外のMS製品もあったはず)、Firefox、Adobe(Readerの事だと思います)、Skypeなどあまりにも多いのでIEの脆弱性にしてしまおう、と言うことなのだと思います。

基本的には呼び出し側が問題なく動作するデータを送るようにするべき、つまりIEの脆弱性でなく他のアプリの問題である可能性が高いと思います。(確信するにはリサーチが必要)

Cとバッファオーバーフローの関係と似ていると思います。余計分かり辛い??
基本的にはデータのセキュリティ対策の責任はCalleeでなく、Callerにある。SQLにヘンな文字列が入っていてSQLインジェクションされないようにする対策はDBサーバ(Callee)でなく、プログラム(Caller)にあるのと同じ事だと思います。

ただし、DBサーバ側(Callee)でも簡単に不正なデータであることがチェックできるような入力(例えば、壊れた文字エンコーディング)であっても処理してしまうと問題の責任はCalleeにあります。

どっちなんでしょうね。

MomongaLinux4でCanon iP7500を使う

Canon iP7500をMomongaLinuxから利用するには

http://www.canon-sales.co.jp/drv-upd/bj/bjlinux260.html

に掲載されているフィルタをインストールしてCUPSのプリンタ設定ページからドライバを選択すれば利用できるようになります。

バイナリrpmを入れても良いのですが、以前にうまく動作しなかった事があるのでSRPMからインストールすることにします。

このcnijfilter-commonはlibxml(obsoleteなパッケージです)が必要なので、どこかから適当なSRPMを拾ってきます。rpmbuildコマンドでビルドするとlibtoolでエラーが発生するので/usr/sbin/libtoolで上書きします。書き換えていれば問題無くビルドできました。

次にcnijfilterのビルドですが、まずcups-devel, gtk+1-develをインストールしておきます。他にも必要な開発用パッケージがあるかもしれません。必要な物はインストールします。

%installセクションの

install -c -s -m 755 ${PR_ID}/database/* ${RPM_BUILD_ROOT}%{_libdir}/bjlib

の-sオプションを削除します。ライブラリでもないファイルに-s(stripオプション)が付いているのでエラーになります。後はrpmbuildでビルドして出来上がったrpmを全部インストールします。

CUPSは再起動しないと新しいドライバを読み込まないので再起動します。その後、プリンタメーカでCanonを選択するとcnijfilterがサポートするプリンタ(Canon PIXUS iP4200 / PIXUS iP6600D / PIXUS iP7500 / PIXUS MP500)が一覧に表示されるようになります。

サポートディストリビューションはSUSE Linux 10.0、Turbolinux FUJIとなっていますが同じ手順でFedoraなどにもインストールできると思います。ここにRedHat系のOSが載っていないのはサポート負荷軽減の為?と勘ぐりたくなります。Libxml2を使うように書き換えればもっと簡単に多くのディストリビューションで使えるようになると思います。

Canonのページを見るとUSBからの接続しかできないような記述になっていますがネットワークプリンタとして接続できればLPDでもIPPでも印刷できます。

MomongaLinux3以来のインストールでしたが以前よりインストールが簡単になっていました。以前はインストール済みのライブラリ(確かlibpngとか)を強制的に別バージョンに見せてインストールしたと思うのですが今回はそのような荒技を使わなくても普通にインストール出来ました。

Mac OSXにはiP7500用のドライバがあるのですがこのドライバはMacのUSBポートに直接iP7500が刺さっていないと動作しない代物です。OSXもCUPSを使っています。CUPSのフィルタならOSXでも使えるはずなので余裕があるときにインストールしてみたいと思います。

追記:
とりあえずビルドした物を公開しました。よろしければどうぞ。
http://wiki.ohgaki.net/index.php?Momonga%20Linux%2FCanon%20Printer

PRGパターンって不必要…

PRGパターンって不必要…というより有害な気がします。

追記/訂正:
普通に実装するとこの後に書いている問題は発生しないので、別の実装が「戻る」ボタンで戻れない原因の様です。普通にリダイレクトすれば302でブラウザに返すので前のページまで戻ります。態々別のリダイレクトをしているPRGパターンが有害と言う事なのかも知れません。今度戻れないページにあったら調べてブログに書きます。(あまり突くと攻撃と見なされるかもしれないので問題ですけど… 役に立つ対策ではないですがもしかすると重複ポスト対策なのかも知れません。不特定多数向けアンケートなどだと安直にリダイレクトで制限だけしてOKとしているのかも知れません。幾つかのパターンがありそうなので調べてみる価値はありそうです)私はデータのやり取りが増え、かつGETを利用することにより汎用性が劣るこの方法でなく普通(?)に内部で処理をルーティングしています。この方法でStrutsでMVCを奇麗に書くと言うのも理解できない事は無いです。微妙な気がしますが、少なくとも普通のPRGパターンは有害、とまでは言えないです。

フォームをポストしてリダイレクトさせ、結果をGETで取得させるのでPRGパターンだそうです。

* First a user-filled form is sent to the server using either POST or GET method. Server stores the information, updates the database and business model data, and replies with REDIRECT response for a View page.
* Browser loads View using GET, no user data is sent to the server at this point.

「え?」と思わせる実装に出会う事があります。PRGパターンもその一つです。ざっと斜めよみなので勘違いしているかもしれないですが。

はっきり言って不親切な実装だと思います。リロードしたら「送信済みです」と表示され、「戻る」で普通に前のページに戻れる方が直感的でわかりやすくユーザビリティが高いと言えると思います。戻るやページのリロードでデータの再送信が行われないようにする事が目的らしいですが、別の方法でごく普通にこのように動作させることが出来ます。重複送信問題もなくCSRFを気にする必要もない実装で可能です。
# 2003年の記事なので割り引いて考えても優れた方式とは言えません。
# 私は2000年の頃からフォームに予測不能な一意なIDを付ける実装を
# 行っています。
# そもそもリンク先のページでは、重複とかCSRFの事を書いていない
# ので、これらは別に対処(or 全く考慮してない)と言うことだと思いま
# す。MVCが綺麗に書けるより、ユーザが使いやすい方が重要だと思い
# ます。

PRGパターンを利用していると思われるWebサイトで「戻る」で戻れなくてフラストレーションが溜まった経験があるのは私だけとは思えません。「戻る」を連続クリックしたり、ヒストリーからしか前の方のページに戻れないサイトが多いのもこの「PRGパターン」のせいなのかな?

Webサイト改竄の新傾向? AdSenseの乗っ取り。

リンク先のフォーラムによるとページ改竄が可能なWebサイトのAdSenseを自分のIDに改竄してしまう、という直接的な攻撃が行われ始めたようです。

小規模なサイトなら「自分の広告が表示されている、と思っていたら他人の広告だった」と気がつくまでには1カ月くらいは必要かもしれないので多数のWebサイトに仕掛ければ小銭稼ぎくらいはできるかも知れません。実際、実験用にこのブログにもAdSense広告を張り付けていますが、広告収入がどれくらいなのかほとんどチェックしていません。(というよりチェックしたくなるほどの広告収入にはなりません)

小銭、といっても月数万円にほどになれば発展途上国ではクラックする十分な動機になります。日本の場合、言語障壁が高いので欧米に比べればリスクは高くは無いと考えられます。

日本でもこの手の被害は発生しているのかな?

PHP 5.3とPHP 5.2

ちょっと前にPHP 5.3のブランチが作られた、と書きましたが今度は前のマイナーバージョンもしばらくメンテナンスされます。どれくらいメンテナンスされるかは分かりませんが、メンテナンスされるのは良い事です。

PHP 5.3とPHP6の位置づけですが、基本的にPHP6 = PHP 5.x(最新版)- Unicodeサポートという形で合意が形成されているでPHP 5.xのマイナー版は機能追加が行われる予定です。

PHP 5.3がリリースされても慌ててPHP 5.2から5.3にアップグレードする必要はありません。ただし、PHP 5.2のサポートはそれほど長くはないので次々とPHP 5.xへとアップグレードする必要性がなくなる訳ではありません。

PHP 5.3は来年の第一四半期にリリース予定です。