高木浩光＠自宅の日記 - 暗黙的に形成する事実標準の話と回避策の話を混同してはいけない
■ 暗黙的に形成する事実標準の話と回避策の話を混同してはいけない 「ぼくはまちちゃん」 ――知られざるCSRF攻撃, 上野宣, @IT, 2005月4月27日初版、2006年11月8日修正版 ●リファラーで発信元をチェック HTTPリクエストを受けたとき、そのリクエストがどこのWebページから発行されたものかを示すリファラー（REFERER）と呼ばれる情報を得ることができる。この情報を活用し、本来意図したWebページ以外からのリクエストを拒否することで、CSRFによる外部からのリクエストを防ぐことができる。 ただし、ユーザーがリファラー情報を出力しないブラウザを使っている場合、このチェックを導入すると正当な操作でも受け付けなくなってしまう。 懸念されるリファラー情報偽装に対する問題だが、以前はリファラー情報を発行するのは攻撃を踏んでしまった自分自身なので、リファラー情報を偽装する動機がなく
高木浩光＠自宅の日記 - 駄目な技術文書の見分け方 その1
■ 駄目な技術文書の見分け方 その1 はてなブックマークのホッテントリを見ていたところ、300を超えるユーザに登録された以下の記事があった。 今夜分かるSQLインジェクション対策, 上野宣, @IT, 2006年11月2日 また上野宣か。顔見知りなのでズバリいくことにする。 しかし、その対策はまだ本当に理解されていないように思える。 へえ。 終わりの方を見てみると、 Webアプリケーションの対策 入力値のSQLの特殊文字を適切にエスケープ 入力値＝プログラム（プロセス）に外部から入ってくるもの シフトJISの場合には1バイト文字を整理 SQLの記述をなくすためにO/R（Object/Relational）マッピングを活用 攻撃者に役立つ情報を与えないために、不要なエラーメッセージ（データベースが出力するエラーなど）の表示を抑止 対策に「準備された文」(prepared statement)
高木浩光＠自宅の日記 - ログイン前Session Fixationをどうするか
■ ログイン前Session Fixationをどうするか 21日の日記「Session Fixation脆弱性の責任主体はWebアプリかWebブラウザか」で、ブラウザベンダはCookie Monster問題をどうするのだろうかということについて書いたが、Firefox 2.0 について調べてみたところ、解決していなかった。また、IE 7 も解決していない。 そのような状況では、セッション追跡がcookieだけによって行われている場合であっても、Session Fixation攻撃に対して配慮せざるを得ない。 これまで、Session Fixation対策といえば、ログイン後の状態をセッションハイジャックされることの防止のみが語られることが多かったが、ログイン前についてはどうだろうか。 たとえば、ログイン前から使えるショッピングカートに対してSession Fixation攻撃が行われると
高木浩光＠自宅の日記 - ワンタイムパスワードは何のためにあるのか
■ ワンタイムパスワードは何のためにあるのか 先月、ジャパンネット銀行から「SecurID」が送られてきた。RSAセキュリティのワンタイムパスワード生成器（以下「トークン」）だ。ジャパンネット銀行は全口座の利用者に対してこれを配布している。 届いた郵便物には図1の案内状が入っていた。 ここに書かれていることは事実でないので、信じてはいけない。 2. トークンはスパイウェアに監視されないので安全です。 トークンはパソコン、携帯電話などと一切の通信を行いません。万が一パソコンや携帯電話がスパイウェア（不正プログラム）に感染しても、トークンに表示されたワンタイムパスワードが監視されることがなく安心です。 これを読んだユーザは、「今後はダウンロードした .exe ファイルを安心して実行できる」と思ってしまうかもしれないが、トロイの木馬（不正プログラム）を実行してしまっては、たとえこのワンタイムパス
高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
高木浩光＠自宅の日記 - 日記予告
■ おススメの本 その1 実家の件は幸い良い結果で済みそうになったので東京に帰ってきた。 溜まった仕事の処理で引き続き時間がない状況。 病院での夜は何もすることができないので読書した。 これならわかる不正アクセス対策入門の入門, 萩原佳明著, 山田祥寛監修, 翔泳社, 2006年1月17日発売 この本はなかなかよい。 Webアプリの脆弱性の話が（だいたい）網羅的に紹介されている。CSRFや Session Fixationの話も含まれている。 「入門の入門」というだけあって、詳細な解決策の提示は十分でないにしても、 初心者Webプログラマが、Webのセキュリティがどういうものであるのかの全体 像を大まかに把握するのに効果的そうだ。そのうえ、肝心な論点がたくさんお さえられている。 また、出版社の編集者の経歴を持つ著者だけあって、文体は適切であるし、論 理に飛躍もないし、中途半端な結論を言っ
高木浩光＠自宅の日記 - しばらく日記をちゃんと書けそうにない
■ しばらく日記をちゃんと書けそうにない 先々週から実家の都合で、東京と実家を行ったりきたりしている。先週と来週 は、打ち合わせや講演や取材をドタキャンさせていただいており、各方面には 大変ご迷惑をおかけしてまことに申し訳ないこととなってしまった。 そんな折、 PHP : 「プログラミング解説書籍の脆弱性をどうするか」への反論のようなもの1, PEAK XOOPS サポート&実験室 PHP : 「プログラミング解説書籍の脆弱性をどうするか」への反論のようなもの2, PEAK XOOPS サポート&実験室 というコメントを頂いた。しかし、しばらくの間、じっくり日記を書くことは できそうにない。とりあえず、簡単に書けるところだけ書いておく。 JavaScriptによる連続自動POSTをされるようなサイト（悪意があるサイトというより、脆弱なサイト）にセッション継続中に訪問することがある、という前
高木浩光＠自宅の日記 - 続・「サニタイズ言うなキャンペーン」とは
■ 続・「サニタイズ言うなキャンペーン」とは 「サニタイズ」という言葉はもう死んでいる サニタイズ言うなキャンペーンがわかりにくい理由, 水無月ばけらのえび日記, 2006年1月5日 というコメントを頂いた。まず、 これは「サニタイズという言葉を使うな」という主張ではありません。「そもそもサニタイズしなくて済むようにすべきだ」という主張です。言い方を変えると、「サニタイズせよと言うな」という主張になります。 「サニタイズ言うなキャンペーンがわかりにくい理由」, 水無月ばけらのえび日記, 2006年1月5日 とある。「サニタイズせよと言うな」キャンペーンでもよいのだが、 その場合は次の展開が予想される。 「サニタイズせよと言うな」を主張する際の具体例として、XSSやSQLインジェ クションのケースを挙げた場合、正しいコーディングは、「その場の文脈でメ タ文字となる文字をエスケープすること」と
高木浩光＠自宅の日記 - ぜひ買いたいこの一冊（脆弱性コードレビュー練習用その1）, JPCERT/CCの判断力も蝕む サニタイズ脳の恐怖
■ ぜひ買いたいこの一冊（脆弱性コードレビュー練習用その1） ジュンク堂本店の「PHP」コーナーで一番目に付く位置に飾られていた本を読 んでみた。 改訂新版 基礎PHP, 山田祥寛監修、 WINGSプロジェクト（本田将輝、山葉寿和、斉藤崇、森山絵美、渕幸雄、青島裕、山田奈美）著, インプレス, 2004年10月1日初版発行 2005年12月11日第1版第5刷発行 帯の宣伝文句はこうだ。 PHP5で作るWebアプリケーション 待望の改訂版登場！ 最新機能まで踏み込んだ内容と、必要な環境を収録したCD-ROMで、着実に学ぶ 着実に……ですか。 最初の動くサンプルコードはこうなっている（p.72）。 <html> <head><title>hello_world.php</title></head> <body> <?php $var_str="Hello World"; print ($var
高木浩光＠自宅の日記 - 要約版：「サニタイズ言うなキャンペーン」とは
■ 「逆」にしたERBが登場 27日の「（略）とかERBとか、逆だったらよかったのに」の件、大岩さんが、逆にしたERB改造版を作ってくれた。 自動quoteつきERBの実験, おおいわのこめんと (2005-12-29) さて、使い勝手はどうだろうか。 ■ 要約版：「サニタイズ言うなキャンペーン」とは 27日の日記「『サニタイズ言うなキャンペーン』とは何か」は、いろいろ盛り込みすぎたせいか思ったよりわかりにくいものになって いるらしいので、結論から順に整理しなおしてみる。 結論: まず「サニタイズ」という言葉を使うのを避けてみてはどうか。正しく説明することの困難から逃げようとしないで。 例外1: 万が一に脆弱性があるかもしれないことを想定しての保険として、CGIの入力段階でパラメタを洗浄することを、サニタイズと言うのはかまわない。 例外2: 既存のシステムに応急手当としてCGIの入力段階で
高木浩光＠自宅の日記 - ASPとかJSPとかPHPとかERBとか、逆だったらよかったのに
■ プログラミング解説書籍の脆弱性をどうするか 印刷されて流通する書籍に脆弱性がある、つまり掲載されているサンプルコードにズバリ脆弱性があるとか、脆弱性を産みやすいコーディングスタイルを身につけさせている解説があり、それが脆弱なプログラマを生産し続ける根源になっている問題は、「なんとかしないといけないねえ」と以前から言われてきた。 ソフトウェア製品の脆弱性は、指摘があればパッチが提供されたり修正版に差し替えられたりするが、書籍の脆弱性はどうか。正誤表が差し込まれるとか、回収する措置がとられるかというと、それは望めそうにない。言論には言論で対抗すればよいということになるだろうか。 久しぶりにいくつかの書籍について調べてみた。先月園田さんの日記などで比較的評判良く紹介されていた2冊を読んだ。 山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, 2004年6月 GIJOE, PHP
高木浩光@自宅の日記 - ウハ、三井住友銀行の素晴らしいセキュリティ教室
■ ウハ、三井住友銀行の素晴らしいセキュリティ教室 昨日の日記でリンクした「シンプルな安全確認ルールと……」の講演では、「本当に伝えるべきことを誰も伝え ていない」という趣旨のことを述べたのだったが、なんと、民間事業者が 既にそれを伝えていたことを知った。 簡単！ やさしいセキュリティ教室 金融犯罪に遭わないために, 三井住友銀行 すばらしい。ほぼ完璧の出来栄えだ*1。いつから公開されていたのだろう？ 少なくとも10月31日には既にあったようだ。 ぼやぼやしているうちに仕事を一つ先に取られてしまった。 以下、ハイライトシーン。 そもそも「アドレスバーがない」なんて論外 簡単！やさしいセキュリティ教室, 三井住友銀行 うはは。 三井住友銀行では、このような画面によるログイン方法を提供しません 簡単！やさしいセキュリティ教室, 三井住友銀行 うひひ。 偽メールの例3 ただいまアクセス集中により
高木浩光@自宅の日記 - SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも, クレジットカード業界は最もWebセキュリテ..
■ SSLを入力画面から使用しないのはそろそろ「脆弱性」と判断してしまってよいころかも 24日のIT Proの記者の眼に「なぜSSL利用をケチるのか」という記事が出ていた。筆者の阿蘇氏には勤務先でWebアプリケーションセキュリティについて取材を受けたことがある。この記事の主張はこうだ。 Webサイトはログイン画面からSSLを使い，利用者はログイン時に鍵マークを確認するのが常識。 阿蘇和人, なぜSSL利用をケチるのか, 日経IT Pro記者の眼, 2005年11月24日 正しい。より正確には「ログイン時」というのは、パスワードを入力する前にということだろう。ただ、その根拠としてこの記事は、フィッシング対策としてサイトが本物かを確かめるためという点だけを挙げているが、その根拠はやや弱い。 SSLをパスワード送信先の画面からではなく、入力画面から使わなくてはならない理由のもうひとつの重大な理由
高木浩光＠自宅の日記 - 攻撃者視点ではなく開発者視点での解説を
■ 攻撃者視点ではなく開発者視点での解説を 8月に@ITに「機密情報に合法的に近づけるWebアプリケーションを守れ」という記事が 出ていた。 タイトルからして意味がわからない。「合法的に近づける」とは何だ？ 英文 の直訳か何かか？ その連載第2回「多様化するWebアプリケーションへの攻撃」が今日掲載されたのだが、問題を正しく理解し ないまま書かれた記事と言わざるを得ない。例えば次のように書かれている。 この例では、「userid=-20298745283」がクエリストリング にあたる。クエリストリングはURL内に含まれているため、誰でも見ることが できる。従って、ユーザーのちょっとした出来心やいたずら（例えば 「この数字の最後を1つだけずらせばどうなるかなー？」） によって、脆弱性が露見することも多い。 この例であれば、誰が見ても明らかなように、「userid」のパラメー タがユーザー管理
高木浩光＠自宅の日記 - CSRF対策は進んでいるか
■ CSRF対策は進んでいるか 7月3日の日記で「クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか」というのを書いたが、 ようするに、CSRF攻撃によってどんな被害が起きるのかが、各サイトの各ペー ジごとに異なり、その差が大きいため、一律に対策が必要ということは誰にも 言い出せなかったためと思われる。日記で、 たとえば、4月19日の「水無月ばけらのえび日記」などにも書かれているように、パスワード変更機能で旧パスワードの同時入力がないと、CSRFによってパスワードを強制的に任意の文字列に変更されてしまうという脅威があることになる。変更したパスワードで不正アクセスされれば、それによって起きる被害は、ユーザに降りかかってくる。 他にも、ログイン中のWeb操作で変更が可能な設定項目によって、公開か非公開かを変更できるようなシステムの場合、非公開にしていたはずのコン
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか
■ クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか 4月27日の日記「クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法」で、 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古くから存在したこの問題がなぜ今まであまり注目されてこなかったかについて考えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 と書いた。あれから2か月以上が経ってしまったが、今書いておく。 端的に言えば、「CSRF対策は所詮、荒らし対策にすぎない」 と考えられてきたためではないか。 荒らし対策をするしないは運営者の自由 あるサイトに脆弱性を発見した者が、その運営者に対してその脆弱性を直して 欲しいと希望することが、どのくらい妥当かというのは、その脆弱性によって 生じ得る危険性の種類によって異なる。 たとえば、IPA の脆弱性届出状
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法
■ クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃（掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為）はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
