yohgaki's blog

Link: http://ha.ckers.org/blog/20071014/web-application-scanning-depth-statistics/

NTOSpider, AppScan, WebInspectとメジャーなWebアプリスキャナの性能を比較した方がいるようです。結果のPDFは以下のURLです。

http://ha.ckers.org/files/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により観測されている、と記載されていました。パッチが必要なシステムは早めにパッチを適用した方が良いと思います。

Link: http://itpro.nikkeibp.co.jp/article/COLUMN/20070910/281585/?ST=oss

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

Link: http://labs.cybozu.co.jp/blog/kazuho/archives/2007/09/re_server_sig.php

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

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

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

Link: http://www.theserverside.com/patterns/thread.tss?thread_id=20936

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パターン」のせいなのかな?

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

Link: http://wiredvision.jp/news/200710/2007101020.html

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

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

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

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