Winnyやりてぇー！ 初心者のための「ファイル共有入門」, 英知出版, 2005年12月発売
の内容すごすぎです。しかも、2005年12月出版という事は昨年末ではないですか、古い本かと思いました… システム管理者は本を買わなくても、せめてリンク先は参照するべきです。とにかく必見です。（ちなみ私は買いません。リンク先の内容だけでも十分…）
エンドユーザがこのような書籍を参考にしているかと思うと夜も眠れなくなるかも?!
国土交通省電子申請システムにも英知出版みたいな記述が
これ地方の電子申請でも同じような感じですよね…
バージョンチェックしているのも有るようだし…
# リンク先はrubyがクラッシュ(?)しているのか最初のアクセスでは空ページ
# になってしまいます。リロードすると表示されます。
CSSを文字列として見れないようにしたMSの対策は不十分だったようですね… と言うよりリンク先の情報からすると確信犯で直していなかった（直っていなかった）ようです。
ということで、ユーザは自衛として他のブラウザを使う、サイト運営者はバグがあるブラウザに対するCSRF対策も行う必要がありますね…
Firefox/Mozilla/SeaMonkeyユーザのアップデートをお忘れなく。使えるMozillaプロジェクトの製品はFirefox 1.5.0.2、1.0.8およびSeaMonkey 1.0.1です。
http://www.mozilla-japan.org/projects/security/known-vulnerabilities.html#firefox1.5.0.2
ちなみにOperaは危険な脆弱性が有るので8.54が使えるバージョンだそうです。
http://www.itmedia.co.jp/enterprise/articles/0604/14/news069.html
WindowsマシンとLinuxマシンの両方を標的とする悪意のあるソフトが新たに出現した。
同ウイルスは、LinuxのELFフォーマットとWindowsのPEフォーマットの両ファイルへの感染力を持つ
だそうです。
To infect ELF files, the virus uses INT 80 system calls and injects its body into the file immediately after the ELF file header and before the “.text” section. This changes the entry point of the original file.
Infected files are identified with a 2-byte signature, 7DFBh, at 0Bh.
The virus uses the Kernel32.dll function to infect systems running Win32. It injects its code to the final section, and gains control by again changing the entry point. Infected PE files contain the same 2-byte signature as ELF files; the signature is placed in the PE TimeDateStamp header.
昨日の夜7時のNHKニュースで山田オルタナティブウィルスの件が報道されていました。IPAの方（多分IPAの方）が「基本に立ち返る必要があります。出所が不明なファイルを開いてはなりません」と言われていました。何故今頃このような報道が?と思ったら、1日300台のペースで感染が広がっているいるようです…
PCがWebサーバになってしまってHDDの中身が丸見えになる様子、リモートデスクトップ機能を無条件に許可して操作状態がわかってしまう様子が報道されていました。
ところで今山田オルタナティブの感染が拡大しているのは「ウィルスに感染しないためにはWinnyをPCにインストールしない」という対策を啓蒙した事が原因で
「WinnyをPCにインストールしなけれウィルスに感染しない」
↓
「WinnyをインストールしていないPCでファイルを開けば安全！」
と勘違いしたユーザ増えた?!という事なのかも知れませんね。
少しコンピュータに詳しい方には笑い話なのですが、ブラックボックスとして使用している方がどう対応する可能性があるか理解した上でセキュリティ教育をしなければならない良い例なのかもしれません。
【追記】
数日前（4/11ごろ）の朝のNHKニュースで「映画等の不正コピーの90%以上はWinnyではなくShareで行われている」と報道していました。これを見て「Shareに乗り換えよう」と思った人も多いのではないでしょうか…. この報道も「なんだかなぁ」と思わされました。
追記：このブログを記載する理由となったURLを記載された方が内容を削除されたようです。「間違っている」と言われるのは心外である、と思ったことは確かですがページの内容が削除されるのは私の本意ではありません。書かれていた情報はとても役に立つ情報だと思います。非常に残念なので再度掲載されることを望みます。（本当
—–
セキュリティ対策ではよくあることですが、条件の見落としによりセキュリティ対策を行っていても脆弱性が発生することがあります。「Webアプリセキュリティ対策入門」に書かれているCSRF対策にも「クロスドメインのHTML読み取り(IEのバグ）」の問題が修正されていない為、書籍に記載した対策を行ってもバグを持つIEに対してはCSRFに脆弱になります。
しかし、このバグの影響を持って「Webアプリセキュリティ対策入門」のCSRF対策を「間違った対策」と書かれても困ります。妥当な表現はバグがあるブラウザに対して「不十分な対策」ではないでしょうか。
このブログを書くきっかけは以下のURLです。
http://www.jumperz.net/texts/csrf.htm
問題点を整理してみます。（IEのCSSXSSバグ問題として知られる問題）
IEはスタイルシートとしてCSS以外のファイル、例えばHTMLファイル、を外部サイトから読み込めてしまうバグがある。
↓
つまり、HTML等に埋め込まれた情報は第三者のサイトから盗む事が可能となる。
↓
つまり、HTML等に秘密情報（トークン等）が記載されていると意図しないフォーム送信（CSRF)を行える。
同じくIEのバグが原因のXST(Cross Site Tracing)に似ている問題と言えると思います。
汎用性（複数のページを開いている場合）の考慮はされていませんが
http://www.jumperz.net/texts/csrf.htm
に利用可能な対策が紹介されています。重要なのは以下の2つです。
この2つを実行することでIEのバグを回避し、CSRFを防止することがWebサイト側で可能になります。
ところで、この問題の本質はセキュリティの基本中の基本であるCIAをブラウザが守れない事に原因があります。(Confidentiality, Integrity, Availavility – の内のConfidentiality(機密性）が守られていない。)マイクロソフトも直すつもりはあるようで
http://d.hatena.ne.jp/hoshikuzu/20051204#P2005204MATANGILLON
に、直すつもりがある旨が記載されています。実際現在のIEはCSSファイルのように見えなければHTMLの中身が読み取れない状態らしく半分直した(?)ような状態になっているようです。（前にSJISは使わない方が良い、とブログで書きましたがこの件でもSJISをページのエンコーディングに使うのは危険なようです）
jumperz.netの対策はバグを持つIEユーザ向けCSRFの対策としては使用できますが、ページに表示されている情報を盗み見れて困るのはCSRF（CSRFの場合、hiddenタグのトークン情報）だけではありません。様々な情報には他人に見られるだけでも困る物も多くあります。例えば、メールや銀行／証券／保険会社の口座情報を広く公開しても気にしない、と言う人は少ないと思います。
セッションIDをページに記載する手法は、キャッシュ制御をしっかりしないとプロキシ等のキャッシュ（どんなヘッダを送ってもキャッシュする、しないはプロキシ次第ですが）にセッションIDが記録されるので簡易な対策として紹介しています。この方法はCSRF対策を行っていないアプリが、普通のブラウザと環境においてCSRF対策を行う場合、問題も少なく、最も対策が簡単だからです。
本来外部サイトのHTMLページはコンフィデンシャルな情報であり、それが守れない状態であるIEが根本的な問題です。重要な情報をページに表示できないのであれば、重要な情報を表示するアプリはインターネットに公開する事はできません。
CSRFだけ考えても、数え切れないほどの開発者が開発しているWebサイトより、MSが開発しているIEのバグを直す方が速いのは明らかと思います。この手のバグに対する対処は仮りに書籍に書くとしても注意事項として小さく書く程度が限界かと思います。出版した頃にはもう解決済みの問題となっている可能性も高いですから。このあたりは紙メディアの限界ですね。
マイクロソフトはPassportアカウントのメールアドレスがvbscriptでどのサイトからでも参照できるバグを長期間放置していた実績があり、今回のバグが長い間放置される可能性も少なくありません。もしかしてIE7では直っている、とアドバイザリを出すつもりなのかも知れません?!火が付けばパッチ出す!?と言うことで、広く知れた事なので騒ぐが勝ちかも知れません。
とは言っても、MSは昨年に分かっていた問題に対して未だに完全なパッチを提供していない事は事実なようです。このような状況ではWebサイト側でも対策しないとMSがいつ対応してくれるか分かりません。情報を盗み見られるも困りますが情報を改竄される方が大きな被害である事に議論の余地は無いと思います。jumperz.netにはクッキーとJavaScriptを使った対策が紹介されていますが、これにはもう少しスマート（汎用的）なやり方もあります。
JavaScriptの使用を前提とするなら「Webアプリセキュリティ対策入門」書かれているフォームID(フォームのトークン – hiddenタグに記載）とセッションID(クッキーに保存）でMD5でメッセージダイジェストを取り、フォームにセットして送信します。サーバ側ではCSRFが行われていないかメッセージダイジェストを比較するロジックを追加するだけでOKです。この手法の場合、複数のページを同時に開いても問題無く処理でき、同じフォームの複数回送信も防げます。
作業量はさておき、この変更自体は簡単ですよね? フォームの方はhiddenタグの追加と簡単なJavaScriptを追加するだけ、サーバ側はMD5の値を作って追加されhiddenタグと値を比べるだけです。hiddenタグの値が無い場合は、CAPTCHAまたはパスワード入力方式にfallbackしても良いかも知れません。本を読んだ方でこの説明で対処方法がよく解から場合はコメントをお願いします。
# MD5関数はJavaScriptにはありませんが、探せば沢山実装が見
# 付かります。
#
# 個人的には、自前のフォームクラスを使っているアプリの場合、
# 上記の修正を加えるにはを少しフォームクラスを修正するだけ
# で対応できました。
#
# ところで.NET ASPで作ったWebサイトはViewState等の為(?)
# このIEのバグによるCSRFの影響は受けないのでしょうか?
# MSの腰が重い理由はこのあたりあるのかな?と疑いを持って
# いる次第です。識者の方、コメント頂ければ幸いです。
Web開発者としては過去のブラウザバグまで考慮して開発するのは困った物です。ユーザとしてもJavaScriptとクッキーを使ったフォーム送信がデフォルトになるとFirefoxのNoScript拡張を使っていると面倒が一つ増えます、IEでもActiveScriptを無効に設定している人も同じ面倒が増えます。仮りにIEのバグが直ったとしてもまた同じ問題が他のブラウザや新しいIEでも発生する事も考えられます。直したハズの問題がまた表れるのもよくある事です。
多分少しするとIEのバグも修正されると思います。JavaScriptとクッキーを使ったCSRF対策を次の書籍等の著作物に入れるべきなのか、省略すべきなのか、悩ましい所です。
蛇足：
Session IDのクッキーに非標準のHttpOnly属性を使いたい方は、Sessionを初期化する場合に別のCSRFチェック用のHttpOnly属性無しクッキーを初期化して使用します。
蛇足2：
時々「IEを使うのは止めときましょう」と、このブログにも書いていますがこの問題もIEを使わない理由の一つですね。2004年はIEが安全に使えた日は7%日しかなかったという調査もあります。2005年は多少まし(?)かも知れませんが、2006年は2004年に似たような数値になるのかも知れませんね。
蛇足3：
PHPの透過的セッション管理（trand_sid）は利用しない、といつも言っていますがtrans_sidを行っているサイトの場合、フォーム送信ページをリクエストする事によりセッションIDを簡単に盗まれます… セッションIDをフォームに記載したCSRF対策も同様にセッションIDを盗まれます。念のため。
ちょっと古いネタなのですが古いPEAR AUTHにはSQLインジェクションに対して脆弱です。Blogに書くか迷ったのですがPEARのサイトにはセキュリティ情報のページが無いので書いておきます。PEARをアップデートして使っていれば大丈夫なのですが、運用環境で理由無くライブラリをアップデートしながら使う、と言うことは考えられません。
私はPEARライブラリのヘビーユーザではなく詳しくPEARのセキュリティ情報を収集していませんが、気になったPEARの脆弱性情報はWikiの
に記載しています。このリストには漏れが沢山あると思います。正確なセキュリティ情報がどこかにまとめてあった方が良いですね。でないと知らない間に重要なセキュリティ上の修正があるようでは怖くて使えませんよね。
# Wikiへ変更箇所はメールで受け取っています。
# 追加・修正はご自由に行っていただいても構いません。
# と、いうよりWikiとはそういう物なのでよろしくお願
# いします。
GoogleのAdWordsにおかしな広告が載っている、という話。
確かに日本ではあまり話題になっていなかったです。本当にAdWordsに掲載する方法は振り込め詐欺にも似た感じを持ちます。Googleも全ての広告主がまっとうな広告主なのか、低コストで、検証する方法は無いでしょうからおかしな広告主がいる事は簡単に予想できます。あまりに酷いと「不正な広告主をレポート！」の様な仕組みを作るかもしれませんが、このような機能は心無い競争相手により悪用されてしまう事が容易に想像できます。難しいですね。
ところでスパイウェアの中にはWebページのAdWords広告を書き換える物もある、と聞いた事があります。こちらの場合は丸っきり書き換えているのでGoogleとは関係ありません。
Web Application Security ConsortiumがWeb Hacking Incidents Database (whid)のアナウンスがありました。Defacement（ページ改ざん）データベースで有名なZone-Hとは異なるアプローチのデータベースです。全てのインシデントを記録する、と言うよりメンテナが気になった（気が付いた?）問題を記録しているようです。例えば、2006年のエントリではGoogleのHTTP Response Splitting問題は記載されていますがgmailのXSS問題は記載されていません。コントリビュータが2人となっているので単なるリソース不足が問題のような気がします。興味がある方はコントリビュータとして立候補されてはいかがでしょうか?
前に書いたSendmail脆弱性の攻撃コードだそうです。
急いでいるとは思いますがSendmailを使っている方は早くアップグレードをしないとならないです。
OSVDBに1983年に登録されたとされる”SendmailのUnspecified Overflow“のエントリ他3つが更新されていたので、またSendmailにセキュリティホールかな?と思っていたら色々なディストリビューションからアドバイザリが出始めました。sendmailのホームページにもアドバイザリが記載されています。
任意コマンド実行など危険性が高いセキュリティホールなのでsendmailを使っている方は直ぐにアップグレードが必要です。
# Sendmail 8.13.6 is available (2006-03-22); it contains a fix for a security problem discovered by Mark Dowd of ISS X-Force. Sendmail urges all users of sendmail 8 to upgrade to sendmail 8.13.6.
If you cannot upgrade to 8.13.6, then you can apply a patch to 8.13.5, or a patch for 8.12.11. Note: these patches do not apply cleanly to older versions; moreover, they may not even work properly due to other changes that have been made in the latest versions. Hence we strongly suggest all users of sendmail 8 to upgrade to sendmail 8.13.6.
For those not running the open source version, check with your vendor for a patch. If you use the commercial version from Sendmail, Inc. then please see their advisory.
出展： http://www.sendmail.org/
Sendmail.comのアドバイザリ：
http://www.sendmail.com/company/advisory/index.shtml
ちなみに私はqmail派です。qmailはアップグレードの必要が無いのでその意味では楽です。
RFIDを使ってSQLインジェクションという話題があるようですが、ID3やEXIFなどのタグ情報を使った攻撃は既知の問題です。バッファオーバーフローを使ったウィルス感染の危険性も指摘されていますが、バッファオーバーフローも既知ですね。セキュリティ上の問題に気が付くか（気を付ける?）は簡単な基礎知識を持っているか持っていないかによって違いが出る例です。
普通に作れば直接SQLインジェクションは確実に防いていると思いますが、セカンドオーダSQLインジェクション（間接SQLインジェクション）を防ぐにはプログラマが意識して入力確認を確実に行わないと問題が発生します。
私の環境だけなのかも知れませんが、WindowsXP+FirefoxにFlash Player 8のバージョンアップがインストールできません。自己解凍EXEをダウンロードしたのですが解凍したあとインストーラが起動せずに終了しているようです。ウィザード画面も開かず勝手にインストールが終了した(?)ようです。Firefoxを再起動すると8.0.22->8.0.24にバージョンアップされていました。（勝手にインストールしたのではなくてENTERキーが押せたのかな??そのうち別のXPでも試して見ますが勝手にインストールするのも良くないですし、再インストールしたらインストール済みであることを表示してほしいです。）
Critical vulnerabilities have been identified in Flash Player that could allow an attacker who successfully exploits these vulnerabilities to take control of the affected system.
http://www.macromedia.com/devnet/security/security_zone/apsb06-03.html
とあるように、コンピュータを乗っ取られる可能性があります。Flash Player 8.0.22以前のユーザはバージョンアップの必要があります。
それにしてもこのような情報は判りやすい所に書くべきと思いますが、Macromediaのセキュリティ情報は分かりづらいところにあります。分かりづらいというより普通のユーザは絶対に見ない(?)Developerのページからさらに2クリック必用なところにセキュリティ情報が記載されています。普通のユーザはサイトを見ていても更新の必要があることさえ気が付かないと思うのですが… Adobeに買収されたので改善を期待したいところですが、Adobeのセキュリティ情報の公開方法も親切とは言いがたいので期待できないかも知れませんね…
追記：CSRFの件、以下に記載しています。
http://blog.ohgaki.net/index.php/yohgaki/2006/04/02/a_ma_sa_sa_a_ia_ca_sa_rhtmleosa_ia_a_iea
よろしければどうぞ。
—-
新しい書籍で紹介した本がもうアマゾンで予約できるようになったようです。早い…
Webアプリケーションのセキュリティ対策の入門書を執筆させていただきました。
タイトルは「Webアプリセキュリティ対策入門」です。
手っ取り早くセキュリティ対策を済ませてしまいたい方には向いていません。「プログラミングはできるんだけどWebアプリには自信がない」と思われている方には適していると思います。Webプログラミングをこれから始める方にも是非読んで頂きたいです。Webアプリのセキュリティ対策を十分知っている方は立ち読みしてください。（笑
サンプルプログラムはPHPですがPHP専用ではなく、対策など内容はより一般的に利用できるように心がけました。「具体的な対策が少ない」とコメントを頂くかもしれませんが、私はセキュリティ対策で最も重要なことを1つだけあげるとすれば「姿勢」と答えます。どのような「姿勢」で設計・実装するのか理解していただければ、具体的な対策（コード）が少なくてもセキュアなWebアプリケーションを構築できると考えています。本書では小手先のテクニックや知識に頼らなくても安全なアプリケーション構築ができるように執筆しました。
基礎編、概念編、実践編の3部構成になっており、基礎編ではセキュリティ対策の基礎、概念編ではWebアプリケーションの代表的なリスク、実践編ではPHPコードを交えてより具体的な対策を解説しています。
Web開発に関わる方の一助になれば幸いです。
参考：Wikiのこの書籍のページ。以下目次の一部
第1 部基礎編―――セキュリティ対策の基礎知識
CHAPTER:1 セキュリティ対策とは?
1-1 セキュリティ対策の基礎知識
1-2 セキュリティ対策の現状
1-3 セキュリティ確保―――何をどのような脅威から守るのか?
1-4 2 つのセキュリティ対策のモデル
1-5 フェイルセーフ（Failsafe）
1-6 多重のセキュリティ
1-7 攻撃可能な箇所の削減
1-8 脆弱性とセキュリティホール
CHAPTER:2 Web サイトセキュリティの基礎知識
2-1 Web サイトで100% 安全なサービスを提供できるか?
2-2 間違った認識の例―――SSL/TLS の安全性、クッキーの弊害、
ソフトウェアキーボード、暗号表
2-3 安全性と利便性
2-4 Web サイトは最も危険なサービスの一つ
第2 部概念編―――脆弱性対策の基礎知識
CHAPTER:3 Web システムの脆弱性
3-1 プログラムの不具合のよる脆弱性
3-2 アプリケーション設計の不具合による脆弱性
3-3 システム管理の不具合による脆弱性
3-4 システム環境の不具合による脆弱性
CHAPTER:4 固有の名称を持つWeb サイトの攻撃手法
4-1 クロスサイトスクリプティング（Cross Site Scripting XSS）
4-2 SQL インジェクション（SQL Injection）
4-3 HTTP レスポンススプリッティング（HTTP Response Splitting）
4-4 クロスサイトリクエストフォージェリ（Site Request Forgery CSRF）
4-5 バッファオーバーフロー（Buffer Overflow）
4-6 LDAP インジェクション（LDAP Injection）
4-7 XML インジェクション（XML Injection）
4-8 XPath インジェクション（XPath Injection）
4-9 パラメータ改ざん（Parameter Manipulation）
4-10 隠しフィールドの改ざん（Hidden Field Manipulation）
4-11 クッキーの改ざん（Cookie Manipulation）
4-12 クロスサイトトレーシング（Cross Site Tracing XST）
4-13 ディレクトリ遷移（Directory Traversal）
4-14 パスの漏洩（Path Disclosure）
4-15 ヌルバイト（Null Byte / Null Character）
4-16 強制ブラウズ（Forceful Browsing）
4-17 セッションハイジャック（Session Hijack）
4-18 コマンドインジェクション
（Command Injection / Command Insertion）
4-19 プログラムの実行（Code Execution）
4-20 サービス不能（Denial of Service DoS）
4-21 その他の攻撃手法
CHAPTER:5 Web サイトの脆弱性
5-1 入力の確認不足
5-2 フィルタ処理の不備
5-3 ファイルの不正参照
5-4 アクセスコントロールの不備
5-5 セッション管理の不備
5-6 エラー処理の不備
5-7 設定管理の不備
オライリーのONLampにURIのデコード回数を検知する仕組みを紹介したA Canary Trap for URI Escapingですが、セキュリティ的には良いプラクティスとは言えませんね…
このような仕組を取り入れるより、アプリケーションを正しく作り、正しくエンコード・デコードされるようにするべきです。このような事が一般的になれば、IPSによる保護がさらに難しくなります。
コメントを書いておこうか、と思ったら先にもう書いている人がいますね。
誓約書は
（１）公務に使うパソコンやフロッピーディスクなどを許可なく外部に持ち出さない
（２）私物パソコンであってもファイル交換ソフトを入れないの２項目。
この2項目のだけだとすると、突っ込みどころ多数です。
ニュースに流す（？）くらいならセキュリティと法律の専門家に相談してから誓約書を作った方がよいのではないでしょうか…
警察はプロの犯罪者に狙われやすい職業と思われますが、この誓約書からすると許可があれば私物パソコンを業務に使っていると思われます。自衛隊でさえ私物パソコンで機密資料を参照しても良いようなので普通に行われているのでしょう。
2項目にするなら
-許可無くデータのコピーは作成しない
-認定したコンピュータ以外ではデータを参照しない
といった感じでしょうね。こんな誓約書にすると業務がまわらなくなるから本当に困るのでしょうけど。