高木浩光＠自宅の日記 - 飾りじゃないのよCAPTCHAは 〜前代未聞のCAPTCHAもどき, CAPTCHA機能の発注仕様をどうするか
■ 飾りじゃないのよCAPTCHAは 〜前代未聞のCAPTCHAもどき CAPTCHA*1が基本的に荒らし対策目的で使用されるものであることは以前にも書いた。ユーザビリティの犠牲が少ないものは早いうちに破られるし、改良してもイタチごっこになることも目に見えている。それでもなお活用する意義があるのは、使用目的が荒らし対策だからだ。新規ユーザ登録や、ログインなしでできるコメントやトラックバックなど、元々自由に利用させる機能である限り、完全に防ぐことはできないのであり、たとえ将来破られる可能性があろうとも何もしないよりはましだというわけだ。（荒らしがよりハードルの低いところへ行ってくれることを期待できる。） そのようなCAPTCHAは、日本ではあまり普及していないようだ。荒し行為が英語圏での状況ほど深刻なものになっていないためか、あるいは、イタチごっこになることが目に見えている技術の採用を嫌う国
高木浩光＠自宅の日記 - CSRF対策に「ワンタイムトークン」方式を推奨しない理由
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest（ヘッダおよび、POSTの場合はボディを含む）を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse（ヘッダおよび、HTML）を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
高木浩光＠自宅の日記 - Mozillaで弱い暗号を使わない設定と銀行サイトで利用可能な暗号
■ Mozillaで弱い暗号を使わない設定と銀行サイトで利用可能な暗号 以下は、昨年10月16日に書き始めたものの、頓挫していた日記ネタである。書き終わっていないが、ワケあって今日、取り急ぎ放出する。以下の表にある調査内容は、昨年10月16日時点のものであり、現在もこの状態であるとは限らない。 職場では隣の席にいる大岩さんの自宅の日記に、Mozillaで弱い暗号の使用を無効にする方法が書かれている。 40ビット暗号の攻撃可能性 Mozilla Suite における弱い暗号化を無効化する設定 Mozilla Firefox における弱い暗号化を無効化する設定 私は9月8日の日記で、 サーバ側がSSL 2.0しかサポートしていないWebサイトにアクセスすると、弱いプロトコルで通信させられることになるので、ユーザの自衛策として、ブラウザの設定で「SSL 2.0を使用する」をオフにしておいた方がよ
高木浩光＠自宅の日記 - 適切な脆弱性修正告知の習慣はなんとか広まらないものか, 「はてなツールバー」がHTTPSサイトのURLを平文のまま送信していた問題,..
■ 適切な脆弱性修正告知の習慣はなんとか広まらないものか 2日の日記の件について、伊藤直也さんからトラックバックを頂いた。話は2つに分ける必要がある。1つ目は、一般にソフトウェア開発者・配布者が、配布しているソフトウェアに脆弱性が見つかって修正版をリリースしたときに、ユーザに伝えるべきことは何か、また、どのような方法で伝えるべきかという話。2つ目は、JVN側の改善の余地の話。 1つ目の話 はてなは以前から、Webアプリに脆弱性の指摘があって修正した場合、それを「はてな○○日記」で事実関係を公表してきた*1。これは、他のWebサイトの大半がそうした公表をしていない*2のと比べて、先進的な対応であると言える。 しかし、今回のはてなツールバーの脆弱性は、Webアプリの脆弱性ではなく、「ソフトウェア製品の脆弱性」である*3。一般に、Webサイトの脆弱性は、修正した時点でその危険性は解消するという性
高木浩光＠自宅の日記 - 要約版：「サニタイズ言うなキャンペーン」とは
■ 「逆」にしたERBが登場 27日の「（略）とかERBとか、逆だったらよかったのに」の件、大岩さんが、逆にしたERB改造版を作ってくれた。 自動quoteつきERBの実験, おおいわのこめんと (2005-12-29) さて、使い勝手はどうだろうか。 ■ 要約版：「サニタイズ言うなキャンペーン」とは 27日の日記「『サニタイズ言うなキャンペーン』とは何か」は、いろいろ盛り込みすぎたせいか思ったよりわかりにくいものになって いるらしいので、結論から順に整理しなおしてみる。 結論: まず「サニタイズ」という言葉を使うのを避けてみてはどうか。正しく説明することの困難から逃げようとしないで。 例外1: 万が一に脆弱性があるかもしれないことを想定しての保険として、CGIの入力段階でパラメタを洗浄することを、サニタイズと言うのはかまわない。 例外2: 既存のシステムに応急手当としてCGIの入力段階で
高木浩光＠自宅の日記 - ASPとかJSPとかPHPとかERBとか、逆だったらよかったのに
■ プログラミング解説書籍の脆弱性をどうするか 印刷されて流通する書籍に脆弱性がある、つまり掲載されているサンプルコードにズバリ脆弱性があるとか、脆弱性を産みやすいコーディングスタイルを身につけさせている解説があり、それが脆弱なプログラマを生産し続ける根源になっている問題は、「なんとかしないといけないねえ」と以前から言われてきた。 ソフトウェア製品の脆弱性は、指摘があればパッチが提供されたり修正版に差し替えられたりするが、書籍の脆弱性はどうか。正誤表が差し込まれるとか、回収する措置がとられるかというと、それは望めそうにない。言論には言論で対抗すればよいということになるだろうか。 久しぶりにいくつかの書籍について調べてみた。先月園田さんの日記などで比較的評判良く紹介されていた2冊を読んだ。 山本勇, PHP実践のツボ セキュアプログラミング編, 九天社, 2004年6月 GIJOE, PHP
高木浩光＠自宅の日記 - Phishing対策ツールバーなんていらない！ 元々あるIEの機能を使う
■ Phishing対策ツールバーなんていらない！ 元々あるIEの機能を使う 安全なWebサイト利用の手順 シンプルな安全確認ルールとそれに則ったサイト作りを〜産総研高木氏講演, INTERNET Watch, 2005年12月2日 の講演で述べた「シンプルな安全確認ルール（手順）」というのがどういうも のかというと、まず、次の2つの状況によって手順を分ける。 初めて訪れたサイトを利用しようとするとき 既に何度か使ったことのあるサイトを利用しようとするとき 初めて訪れたサイトでは、サーバ証明書の内容を読んで、書かれている会社名 や住所が、自分が今使おうと想定している相手なのかどうかを確認し、間違い なければ利用を開始し、次回に備えてそのドメイン名を暗記しておく――(A)。 既に使ったことのあるサイトに訪れたつもり（偽サイトかもしれない状況で） のときは、アドレスバーに表示されたドメイン名を
高木浩光＠自宅の日記 - ウイルスバスター2006はトレンドマイクロの定義で言うところのスパイウェアである
■ ウイルスバスター2006はトレンドマイクロの定義で言うところのスパイウェアである 星澤さんがウイルスバスター2006のスパイウェア疑惑について、11月2日から書いていらしたが、18日になってもト レンドマイクロから回答が得られないとお困りのご様子だったので、21日 の午前、私も聞 いてみることにした。 一般的に、ユーザからの問い合わせが多くなる商品を販売している会社では、 この種の重要事項の問い合わせ（たとえば脆弱性の指摘など）が、ユーザの一 般的な質問に紛れ込んでしまい、判断のできる肝心な担当者へ情報が伝わらな いということが起きがちなものだ。そこで、大代表に電話をし、個人情報保護 担当者と電話で話したいと伝えた。 （トレン ドマイクロの個人情報保護方針にはメールアドレスしか書いてない。） すると「システムの都合でここから個人情報保護担当者には電話をつなげない」 と言われるわけだが、
高木浩光＠自宅の日記 - ITmediaが利用規約から無断リンク禁止条項を撤廃
■ ITmediaが利用規約から無断リンク禁止条項を撤廃 Webメディア御三家、つまり、INTERNET Watch、ITmedia（旧ZDNet JAPAN）、 日経IT Proと言えば、日本のWeb文化をリードしてきた新時代のマスメディアだ。 旧態新聞会社達が決して扱うことのなかった話題を、いつも期待を裏切ること なく報道してくれた頼れるメディアだ。たとえばこんな報道があったのも Webメディアならではと言えよう。 文化庁、「ディープリンクを拒否するつもりはない」, ITmediaニュース, 2002年7月10日 旧態マスメディアの主要な何社かが、記事ページへの無断リンク*1を禁止すると定めているところ、 そのナンセンスさはこれまでにも幾度となく議論されてきた。 しかし、実はITmediaが利用規約で無断リンクを禁止しているというのは、 知る人ぞ知る事実であったものの、あまり積極的に語
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか
■ クロスサイトリクエストフォージェリ（CSRF）対策がいまいち進まなかったのはなぜか 4月27日の日記「クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法」で、 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古くから存在したこの問題がなぜ今まであまり注目されてこなかったかについて考えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 と書いた。あれから2か月以上が経ってしまったが、今書いておく。 端的に言えば、「CSRF対策は所詮、荒らし対策にすぎない」 と考えられてきたためではないか。 荒らし対策をするしないは運営者の自由 あるサイトに脆弱性を発見した者が、その運営者に対してその脆弱性を直して 欲しいと希望することが、どのくらい妥当かというのは、その脆弱性によって 生じ得る危険性の種類によって異なる。 たとえば、IPA の脆弱性届出状
高木浩光＠自宅の日記 - クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法
■ クロスサイトリクエストフォージェリ（CSRF）の正しい対策方法 「クロスサイトリクエストフォージェリ」がにわかに注目を集めている。古く から存在したこの問題がなぜ今まであまり注目されてこなかったかについて考 えているところだが、引越しやら転勤やらでいまひとつ日記を書く時間がない。 しかし、 @ITの記事などのように混乱させる解説も散見されるので、一点だけ対策 方法について書いておくとする。 クロスサイトリクエストフォージェリ――Cross-Site Request Forgeries (CSRF)を防止する簡潔で自然な解決策は以下のとおりである。 前提 ログインしていないWeb閲覧者に対するCSRF攻撃（掲示板荒らしや、ユーザ登 録を他人にさせる等、サイト運営者に対する業務妨害行為）はここでは対象と しない。 ログイン機能を持つWebアプリケーションの場合、何らかの方法でセッション 追
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
