10月30日作成のページですが今みました。
結構笑えます。（英語のプレゼンテーションビデオです）
これではどのサイトも信用できないです。
追記：
ビデオの見なくても良いように一番重要な点だけ書きます。
SSLの公開鍵・秘密鍵がデフォルトのまま使っているサイトが多くある、というくだりです。銀行などのサイトでも「ありえない」と思える割合のサイトがデフォルトのキーペアを使っていて暗号化の意味がなくなっている！！！のだそうです。（詳しくはビデオを参照）
キーはサイト毎に生成するになぜこんな事が起きる？と思われる方もいるかもしれません。ハードウェア系のSSLソリューションには静的に生成されたデフォルトのキーペアが設定されている場合があるのですが、なんとそのキーを使っているサイトが多数存在する、とこのプレゼンで言っています…
笑うに笑えないですが、不謹慎にも笑ってしまいました。
教訓 ‐ デフォルトパスワードだけでなくデフォルトの鍵も使わない！
(当たり前すぎです…)
SPAMMERからのページ改ざんや作成が日を追うごとに増えてきているので、wikiを管理が行いやすいMediawikiに乗り換える事にしました。まとめて移行する時間はないので段階的に移行する事になります。
「あれ凍結したはずのページが改ざん?」と思ったら大文字を小文字に変えて新しいページを作っていました。
しかし、SPAMMERも色々考えますね。
# こんな事に時間を使うより、書きたい事は沢山あるので、
# コンテンツをマシにしたいのですけどね…
# タイポをよくするので親切な方から直接直して頂いてい
# たりしたのですが認証なしで編集は時代遅れですから
# 仕方ありません…
パスワードを平文で保存するのは論外で、MD5やSHA1でハッシュ化するのは当たり前です。しかし、SHA1を2000倍早くクラックする方法などが発見され「SHA1は脆弱だ」（ちなみにMD5はもっと危険）とされてからしばらく経ちます。アメリカ政府や大手企業はSHA1は使わない、としています。
参考：
技術評論社の新サイトで「なぜ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アプリの脆弱性レポートがあったのですね。
「Macworldサイトのハッキングでジョブズ氏講演の優待席を無料ゲット 」したハッカーがいるらしい。なんと認証がクライアント側で行われていたそうです。
ありえない…
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で作り直しを行っています。スパムメールと同じですね。
GmailでJavaScriptのソースとしてコンタクトリストデータを埋め込んでいたため、第三者がコンタクトリストを盗めてしまう、という問題が話題になっています。
まだ詳しく調べていませんがsrc属性に指定されたソースは誰でも（どのサイトからでも）取得できるブラウザの仕様を利用したものだと思います。
比較的早くからsrc属性で他のサイトのJavaScritpが指定できる仕様のリスクは指摘されていました。Gmailでさえ重要なデータをJavaScriptのソースに埋め込んでいるのですからAjaxアプリケーションの多くに同じ脆弱性があるような気がします…
手っ取り早く不完全な方法で修正するにはリファラチェック、きちんと修正するならJavaScriptのリクエストに鍵を付けてチェックする、といった方法で対策可能です。
http://example.com/javascript_contains_sensitive_data.js?key=123456789
と言った感じです。
# 鍵を付ける場合、セッションIDを鍵にしてはいけません。
# セッション変数にランダムな鍵を設定してチェックすると良い
# です。
経済産業省は、同省が管轄する経済産業分野の個人情報ガイドラインについて見直しを実施し、現在パブリックコメントを実施中だ。
SecurityNEXTでも報じているが、注目される点としては、事故発生時の事業者対応について負担軽減を盛り込まれたことが挙げられる。
たとえば、高度な暗号化などが行われている場合や、速やかに紛失した個人情報が回収された場合など、二次被害など本人に被害が及ぶ可能性が小さければ、本人への通知や公表などを省略可能としている。
最低ラインとして公表は必須でしょう…. 高度な暗号化とは? コピーされた後速やかに回収されたら?本人に被害が及ぶ可能性は誰が判断する? まだ読んでいませんがとにかく問題がある原案のようです。時間がある方は是非コメントを。
パブリックコメント：2007年1月31日締切
http://search.e-gov.go.jp/servlet/Public?CLASSNAME=Pcm1010&BID=595106051&OBJCD=&GROUP
個人情報保護関連
http://www5.cao.go.jp/seikatsu/kojin/index.html
http://www5.cao.go.jp/seikatsu/kojin/gaidorainkentou.html
参考
高度ＩＴ人材育成のための施策のあり方についての意見募集の結果について
http://search.e-gov.go.jp/servlet/Public?ANKEN_TYPE=3&CLASSNAME=Pcm1090&KID=595206030&OBJCD=100595&GROUP=
これを見ると
２．御意見の提出件数
３４件
３．御意見の内訳
・ 個人 ２３件
・ 企業 ８件
・ 団体 ３件
なようです。個人情報保護のガイドラインも多かれ少なかれ似たような結果になると思います。（つまり、影響力はある程度期待できるかも!?）
SkypeにWormが発生しているらしい。ただし、脆弱性を利用した攻撃ではなく、大規模な感染も発生していないようです。チャットで問題のある「バイナリ(sp.exe等）をダウンロードして」とメッセージが送られ、ダウンロード&実行すると感染するそうです。（亜種あり）
Skypeに脆弱性か!と思いましたが脆弱性を使った攻撃ではないようです。チャットメッセージからダウンロードしたファイルから感染するのであれば日本では問題にならないでしょう。
以下、F-Secureのブログから
* There is something spreading on Skype, but only in limited numbers
* It is not exploiting a vulnerability in Skype but simply sending chat messages asking you to download and run the infected executable
しかし、Bot作りも大変ですね。この手のWormでそれほど多くのBotが作れるとは思えないのですが… Botではなく別の目的かな?
# ところで、これワームと言うよりトロイの木馬ですよね。
QuickTimeを利用してXSSを行えることはMySpaceのWorm
http://www.f-secure.com/v-descs/js_quickspace_a.shtml
で有名になりました。
http://www.gnucitizen.org/blog/backdooring-quicktime-movies/
はQuickTimeを利用したXSSの手順を解説しています。
XSSのサンプル
http://www.gnucitizen.org/blog/backdooring-quicktime-movies/sample_backdoored.mov
上記のリンクを開くとJavaScriptのダイアログ（Windows XP SP2 + Firefox2.0）が開きます。NoScript拡張等、JavaScriptを無効にしている場合はダイアログは開かない
# b2evolutionのHTML解析正規表現に不具合があるようでリンク
# が正しく表示されないので自動リンク（URLだけ書いてリンクにする）
# にしています。イメージを貼り付けた事が原因かな?
TTLが短いとDNSキャッシュサーバがドメイン権限を持ったDNSサーバにクエリに行く機会が増える（当たり前ですがDNSキャッシュサーバはTTLで指定された時間だけレコード情報をキャッシュしてドメイン権限を持つDNSサーバにクエリしない）ので危険と言う話。1秒に一回キャッシュを更新するほうが1時間に一回キャッシュを更新するよりDNSキャッシュ汚染が行いやすくなる、という当たり前の事です。DNSキャッシュが汚染可能である事、その汚染の仕組みを知らない方には思いがけないリスク増加かもしれません。
7ページ目に記載されている数式だけではどれが何だか分かりませんが、Nはポート数を表しているはずです。ポートが固定されていると16^2の組み合わせしかない、と言う話は良く知られていると思います。DNSを管理している人なら誰でも知っていると思いますが
にも記載されている通りBINDはポートが固定されていたのでdnscache（djbdnsのDNSキャッシュサーバ専用のプログラム）に比べてかなり脆弱だったのは有名な話です。
# 最近はBINDを使ってないので今のBIND9の実装がどうなっている
# か知りません。
気にした事が無かったですがTTLを短くした場合、ネームサーバを増やすのは良い考えですね。DNSはラウンドロビンでIPアドレスを返すのでネームサーバが増えた分だけ細工したパケットでDNSキャッシュ汚染できる確立を低下できます。そのうちネームサーバが100個登録されているドメインとか出てくる(?)かも知れません。そうなるとBINDのNOTIFY/AXFERではちょっと困りますね。djbdnsのrsync方式の方が信頼性が高い&直ぐに同期できるのでBINDではちょっとやりづらいと思います。
ここで余談を一つ。djbdnsには昔から面白い機能があります。データセンターの変更などでWebサーバ等のIPアドレスが変更される場合があります。移行前にTTLを短くしておくなどの対処を行いますが、djbdnsには「指定した時間になったらIPアドレスを変更する」機能があります。この機能はtinydns(djbdnsのDNSサーバ）は指定されたtai64n形式の時間（qmail等でも利用されている厳密に時間表記が行える表記形式)に合わせてリクエストがくる度に自動的TTLを変更することによって実現されています。データセンターの変更だけでなくWebサーバのメンテナンスにも便利です。
参考：
更に余談をもう一つ。少なくとも先月はYahoo! BB、DoCoMoのMTAはネームサーバが停止しているとメールが送れない場合があったようです。ネームサーバは1台でも稼動していれば名前解決ができるのですが、Yahoo! BB、DoCoMoのMTAは稼動していないネームサーバのIPアドレスを引いてしまうと名前の解決に失敗した旨のエラーでメール送信に失敗していたようです。単なる想像ですがDomain Keyと関連があると思っています。
# ネームサーバを増やすと思わぬリスクを増やすかも
# と言う話でした。
クロスサイトスクリプティングに利用可能なテキストハックが簡潔にまとめられている。
目新しかったのはUnicodeのBidi機能（テキストの記載方向が異なる言語、たしかアラビア、イスラエルなどの言語）を使ってWindowsの拡張子をごまかせる事です。
# 他のOSでも問題になるかも。もし同じ問題があったとしても、UNIX系
# OSの場合は実行ビットが有効でないと実行バイナリであっても実行さ
# れないので影響は少ないですが。
ファイルマネージャ、コマンドラインなどはBidi機能はロケールのみよって有効・無効を設定できるようになっていないとセキュリティ上問題です。
文書の途中で「アラビア語の文字列を書く」必要がある場合もあると思うのでシステム全体としてBidiを無視することは良くありません。しかし、文書中でBidiが有効になっていてファイル名にBidiが混じっていてそのファイルをクリックすると意図しないバイナリを実行、という攻撃方法もアプリケーションによっては行えそうです。とにかく気を付ける（ってどうするの、という話もありますが）しかないです。
備考：名無しさんの指摘でタイトルを変更、一部本文を修正しました。（IEとFFの立場を入れ替えました）
少なくとも2006年1月ころのMozilla系ブラウザには簡単に設定できるべきでないクッキーが設定できてしまう問題がありました。最悪なのはco.jp等、ccTLDの属性ドメインに対してクッキーが設定できてしまう動作ですが、手元のFirefox 2.0で試したところHTTPのSet-Cookieヘッダではco.jpには設定できなくなっています。しかし、この修正が中途半端でJavaScriptからdocument.cookieにco.jpにクッキーを設定できてしまいます。（名無しさん、情報ありがとうございます）
example.co.jpとwww.example.co.jpに同じ名前のクッキーを設定するとexample.co.jpのクッキーが返ってきます。下位ドメインによるクッキーの上書きが出来ないのは従来どおりのようです。（複数のクッキー値がドメイン毎に設定される）明示的にwww.example.co.jpドメインからexample.co.jpドメインのクッキーを上書き/削除できるのも従来どおりのようです。host1.example.jpからhost2.example.jpのクッキーが設定できるのも従来どおりのようです。
# 上位ドメインのクッキーを設定できるのに同じレベルのドメイン
# クッキーが設定できなくてもあまり意味が無いです。
# PHPユーザの場合、my-server.hosting.jpの様なドメインを
# 持つサイトの場合、余計なクッキーの削除と外部からのセッ
# ションIDを受け入れないように注意が必要ということ意味し
# ます。
KHTML（Safari、Konqurer）は2004年くらいにこの問題（ccTLDのクッキー）には対応済みと思います。
IE6/7では今のFFと同じでほかの上位ドメイン等のクッキーの上書き/削除は同じ動作をするようです。
もう少し調査が必要ですが、とりあえずccTLDに関しては最新ブラウザを使っていれば大丈夫なようです。まだまだ最新ブラウザでも安心できないようです。
参考：
Multiple Browser Cookie Injection Vulnerabilities
Client Side State – HTTP Cookies
HTTP State Management Mechanism (RFC2109)
HTTP State Management Mechanism (RFC2965)
RFC2109（Cookie1）はNetscapeクッキーの後追い標準なので仕方ないですが
* A Set-Cookie from request-host y.x.foo.com for Domain=.foo.com
would be rejected, because H is y.x and contains a dot.* A Set-Cookie from request-host x.foo.com for Domain=.foo.com would
be accepted.* A Set-Cookie with Domain=.com or Domain=.com., will always be
rejected, because there is no embedded dot.* A Set-Cookie with Domain=ajax.com will be rejected because the
value for Domain does not begin with a dot.
と親ドメインへのクッキー設定は標準です。example.co.jpでco.jpにクッキーを設定できないとは書いてありません。
Cookie1の定義では
cookie = “Cookie:” cookie-version
1*((“;” | “,”) cookie-value)
cookie-value = NAME “=” VALUE [“;” path] [“;” domain]
cookie-version = “$Version” “=” value
NAME = attr
VALUE = value
path = “$Path” “=” value
domain = “$Domain” “=” value
とパスとドメイン情報を送信することになっていますが、IEもFirefoxも
Cookie: var=FOO;var=BAR\r\n
という感じでパスもドメイン情報も無しで、複数の値を送ってきます。IE,Firefox共に先に親ドメインの値を設定するようになっているようです。
パス設定が行われている場合は最適なクッキーから順番に書くようになっている
If multiple cookies satisfy the criteria above, they are ordered in
the Cookie header such that those with more specific Path attributes
precede those with less specific.
のですが、ドメインの方は
Ordering with respect to other attributes (e.g., Domain) is unspecified.
と未指定です。IE,Firefox共にここはRFC仕様と同じでパスが指定されているときは一致度が高いクッキーから順番に返し、ドメインは上位ドメインから順番に返してきます。
PHPの場合、先に設定された値が$_COOKIEに入るので複数のPATHが指定された場合は期待通りの動作をしますが、複数のDOMAINが指定された場合はホストのクッキーではなくドメインのクッキーが使われてしまいます。
このため余計なクッキーが設定されないようにクッキーを設定する場合、setcookie/setrawcookie関数のラッパーを書いてドメインのクッキーを削除してからクッキーを設定するようにしないと問題となる場合があります。
# セッションIDが設定されている事によるDoSやSessionIDの固定化を
# 防ぐにはsetcookie(‘PHPSESSID’,”,0,path,domain);
# 等とします。pathはパス、domainはドメインを指定する文字列。
どちらにしてもRFCに記述されている$Version, $Path, $Domainは無視しているのでIE,Firefox共にいわゆるOldクライアントとして動作していることになります。IE, Firefox共にSet-Cookie2:ヘッダは無視しています。Web黎明期の仕様はあまりセキュリティを考慮しておらず今でもその仕様に従わざるを得ないのは仕方ないです。下を見て比べても有意義ではありませんがSMTPよりはマシかな…
しかし、ドメイン指定で複数の値がある場合にホストと完全に一致したクッキーから順番に返してこないのはNetscapeの動作がそうなっていたからなのでしょう。コーディングした人は「順番なんてどちらでも良いや」くらいに思っていたと推測できます。（それともNetscapeクッキーの仕様では親ドメインのクッキー優先?）ドメイン、パスを明記するRFCのクッキー仕様通りならサーバ側で意図通りの値のみを使用する事も可能ですが、IE,Firefox共にパスやドメイン情報を返してきません。複数のパス、ドメインに一致するクッキーは
Cookie: var=v1;var=v2;var=v3;var=v4;
と、どれがどれだか全く判らない状態で値を返してきます。(パスだけ設定されている場合はパスの一致度が高い物から先に値が設定されます）当然ですがこの動作だとパスとドメインで一致度が高いクッキー値をサーバ側で判別不可能です… 自衛策としては上位ドメインで設定されたクッキーを明示的に削除するしかありません…
PHP 5.2.0がリリースされていますが少なくとも2つ重要なセキュリティフィックスがあります。5.1/4.4ユーザが5.2.0にアップグレードするには時間が必要と思うのでWikiどのパッチが必要か書いておきました。PHP4はこちらです。
PHP4.4にはありませんがPHP5.1にはecalloc（メモリ確保関数）に整数オーバーフロー脆弱性があります。この脆弱性は随分前にPHP4で修正されたバグですがPHP5ブランチにマージされ忘れていた、という代物です。最も簡単に攻撃可能なケースはserializeされたPHP変数をフォームやURLに埋め込みそれをunserializeで処理しているケースです。
htmlspecialchars()/htmlentities()のヒープオーバーフローのPoCは見かけていませんがパッチを見ればどのような入力でオーバーフローするのか見る人が見れば直ぐ分かると思います。
Google Source Codeで自動的にバグ（らしきもの）を見つけるページ
http://www.cipher.org.uk/projects/bugle/BugleAutomated.php
古いコードも一緒に検索されたりしますが「Package Name」オープンソースのプロジェクト名（ソースのtar玉のパッケージ名の部分など）を入力すると自動で怪しいコード見つけてきてくれます。