運営元のロゴ Copyright © 2007-2024 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
補足 この記事は旧徳丸浩の日記からの転載です(元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2)。 備忘のため転載いたしますが、この記事は2007年12月6日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 最近、画像ファイルを用いたクロスサイト・スクリプティングが注目されている。本稿では、画像を悪用したXSSについて説明した後、対策方法について解説する。 画像によるXSSとはどのようなものか Internet Explorer(IE)の特性として、コンテンツの種類を判別する際に、レスポンスヘッダ内のContent-Typeだけでなく、コンテンツの内容も判断基準にしている。このため、Content-Typeが例えばimage/gif(GIF画像)となっていても、中身がHTMLであればHTMLと解釈して表示する。
Internet Explorer の悪名高い Content-Type: 無視という仕様を利用すると、Atom や RDF/RSS を利用してXSSを発生できることがあります。条件的に対象となるWebアプリケーションは多くはないと思いますが、それでもいくつか該当するWebアプリケーションが実在することを確認しました。以下の例では Atom の場合について書いていますが RDF/RSS でも同様です。 例えば、http://example.com/search.cgi?output=atom&q=abcd という URL にアクセスすると、「abcd」という文字列の検索結果を Atom として返すCGIがあったとします。 GET /search.cgi?output=atom&q=abcd Host: example.com HTTP/1.1 200 OK Content-Type: ap
UTF-7を利用したXSSは、charset が指定されていない場合に発生すると考えられていますが、少なくとも Internet Explorer においては、これは大きな間違いです。正しくは、Internet Explorer が認識できる charset が指定されていない場合であり、charsetが付加されていても、IEが認識できない文字エンコーディング名である場合にはXSSが発生します。 例えば、次のような HTML は(HTTPレスポンスヘッダで charset が明示されていない場合)IEが文字エンコーディング名を正しく認識できないため、その内容からUTF-7と解釈されるためにスクリプトが動作します。"utf8"という表記はUTF-8の慣用的な表現ではありますが、ハイフンが抜けており正しい表記ではありません。 <html> <head> <meta http-equiv="Co
■ MacユーザはIPv6を切るかnet.inet6.ip6.use_tempaddr=1の設定を Mac OS Xの初期設定の危険性 私の周囲に物理的に近づくことのできる人は、私が使っているノート型コンピュータの無線LANインターフェイスのMACアドレス*1を知ることができる。たとえば、セミナー等で私が講演している会場に来れば、講演中に私が無線LANのスイッチを切り忘れていたなら、無線LANのパケットを傍受することで私のMACアドレスを知るだろう*2。それだけでは他の人のアドレスと混じって区別できないだろうが、別の場所で再び同じことをすれば、両方に存在したものが私のMACアドレスだ。 これはもう隠しようがないので、先に自ら暴露してしまおう。「00:1f:5b:d1:ec:bd」は私のMACアドレスだ(図1)。 これを暴露するのはリスクのある行為であり、お薦め出来ない。また、仮に他人のMA
水色の四角は画面を表し、白抜き実線枠の四角はボタンを表す。 これを、Webアプリという実装手法を選択する場合に特化すると、図2のような遷移図が描ける。 実線矢印はブラウザが送信するHTTPのrequest(ヘッダおよび、POSTの場合はボディを含む)を表し、黄色の丸がサーバ側での1アクセスの処理を表し、点線がその処理結果を返すHTTPのresponse(ヘッダおよび、HTML)を表す。responseの上の文はHTMLの内容を説明するものである。黄色の丸の中の文は処理内容の説明であり、ここから複数のresponse矢印が出ている場合、処理の結果によって遷移先の画面が異なる場合であることを表し、破線の白抜き四角がその分岐の条件を概説している。 この図で例に用いているのは、ECサイトやblogサービスなどに見られる典型的な「登録個人情報変更」の機能である。「メインメニュー」画面の「登録情報変更
ANSER WEBというASPサービスでインターネットバンキングを提供している金融機関が、EV証明書を導入した理由は、「NTT DATA CORPORATION」という社会的信頼の高い企業による運営であるという表示によって、利用者に本物サイトであることの確認手段を提供したことにあるのだから、これらの金融機関は、利用者が「NTT DATA CORPORATION」という名称さえ見てくれればいいことを前提としている。 しかし、もし、図3のように、ドブログのようなサイトでまで緑色で「NTT DATA CORPORATION」と表示されるような世の中になってしまったら、どうなのだろうか。 まず、少なくとも、EV証明書導入サイトがやってはいけないことがある。 もし、ドブログのユーザコンテンツ(つまりブログ)のページが、https:// でも表示できるようになっていたらどうか。どこの馬の骨ともわからな
HTTPリクエストヘッダの「HTTP_USER_AGENT」で取得できる、EMnet対応端末のユーザエージェント情報は下表の通りとなります。 【Japanese】 Mozilla/5.0 (Linux; U; Android 2.2; ja-jp; S31HW Build/FRF91) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 【English】 Mozilla/5.0 (Linux; U; Android 2.2; en-jp; S31HW Build/FRF91) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1 【Indonesia】 Mozilla/5.0 (Linux; U; Android 2
最近 OAuth だの OATH だの色々出てきているので, いわゆる「認証」について 『セキュリティはなぜやぶられたのか』(Beyond Fear) を教科書に少しおさらいしてみる。 いわゆる「認証」については, 前に読書禄でも紹介している。 いわゆる「認証」を考えるとき, 私たちは以下の3つの要素の組み合わせで考える。 識別(identification): あなたは誰? 認証(authentication): 証明しろ 許可(authorization): この範囲のことはしてもよい 例えば, 運転免許証番号は識別トークン, 運転免許証の顔写真は認証トークン, 運転免許証自体は許可トークン, といった具合である。 識別・認証・許可は必ずしもセットになっている必要はない。 『セキュリティはなぜやぶられたのか』 でも例示されているが, 乗り物の乗車券やコンサートのチケットは許可トークンだ
横浜で巨大グモを見た (04/18) アルファブロガー・アワード2008について二言いっとくか (12/25) いまさら気づいた (12/21) 931SHのPCメール機能はOP25B (12/03) こっ、この馬鹿者がっ! (11/29) ア・マ・ゾーン! (11/27) monitってさ… (11/20) ウザいアイブラスター広告ふたたび (11/20) 拝啓、古森オサマ義久さま:マケインは「ジョン・シドニー・マケイン3世」と書いてください (11/19) テケノレソバ一丁! (11/14) 「非正規雇用者の父」の二つ名をもつ奥田碩 (11/13) yahotter (11/12) The Economistがライバルか… (11/08) 擁護どころか惚れるだろ (10/28) USBメモリ>SSD (10/28) Windows Home Server評価版を注文するのと「日経Lin
■ Amazonはやっぱり怖い そろそろ使うのをやめようと思う 今は朝6時。数時間前、寝ようとしたころに大騒ぎになっていた。 密かな趣味が全公開--Amazonのウィッシュリスト、改め「ほしい物リスト」に注意?, CNET Japan Staff BLOG, 2008年3月12日 これはひどいことになった。HATENA Co., LTD. では暗号解読の本をお求めのようだった。 幸い私は、ウィッシュリストを空にしていたので、何も見られることはなかったが、自分のAmazon登録メールアドレスを入れると、氏名と「茨城県」などの情報が表示された。(メールアドレスも非公開のものを使っているが、ワイルドカード指定もできたようなので、どうなっていたかわからない。もっとも、私は実名を隠していないが。) そもそも何年か前、この「ウィッシュリスト」なるサービスが始まったとき、やたらウイッシュリストへの登録が
こんにちは! Amazonほしい物リスト、すごい話題になってますね! なんでも、メールアドレスで検索すればAmazonに登録してある本名がでてくる (ケースもある) とか…。 で、さっそくぼくも試してみたよ! ほしい物リストサーチ! これって、いま話題になっているのは、誰かのメールアドレスを手がかりにして ウィッシュリストや本名、下手すると住所まで知られてしまうってところだよね。 それだけでも面白いんだけど、 あまり注目されていない機能として、こんなものがあったよ。 友だちにほしい物リストについて知らせる これ。 自分のほしい物リストを誰かにメール送信できちゃう機能らしいね! じゃあ試しにメール送信時のリクエストを確認してみると… http://www.amazon.co.jp/gp/registry/send-nudge.html?ie=UTF8&type=wishlist&__mk_j
Amazon.co.jpに「ほしい物リスト」という機能がある(3月8日よりウィッシュリストから名称変更)。自分の欲しいAmazon.co.jpの商品を登録し、友人などに知らせることができるというものだが、この機能を利用するにあたっては注意が必要だ。 というのも、ほしい物リストは作成時に非公開設定にしない限りウェブに公開される仕様となっており、さらにAmazon.co.jpのサイト上から名前またはEメールアドレスで検索できるため、不特定多数のインターネットユーザーに自分の欲しい商品が見えてしまうからだ。 「ほしい物リスト」の検索画面(クリックして拡大) 試しに、検索窓に思い当たる人名や会社名などを入力してみると、まったく知らない人や団体のほしい物リストが次々と表示される。表示されている名前をクリックすると、欲しがっている商品までわかってしまう。 「会社」というキーワードで検索した結果 Ama
■ ジャストシステムはどこへ向かっているのか ジャストシステムが、ユーザの安全確保よりも、何らかの別の目標*1に向かっているらしいことは、次の事例で一目瞭然だろう。 こんな言い回しは他で見たことがない。 脆弱性情報を公表することの目的が、まだ修正版の存在を知らされていないユーザに対してアップデートの必要性を周知することにあるということは、(ユーザの立場で考えれば)誰でもわかるはずだ。それなのに、ジャストシステムは、まず先に、「ご安心ください」と言う。(図1の1つめの矢印部分。) Kaspersky Internet Security 6.0 および Kaspersky Anti-Virus 6.0のVista対応版プログラム以前の製品(バージョン 6.0.0.306)で5つの脆弱性が発見されています。この問題に対する修正は、3月14日より無償でダウンロード提供しているVista対応版プログ
■ デイリーポータルZ 記者の家を探しに行く 5月27日の日記「PlaceEngineのプライバシー懸念を考える」では次のように書いた。 つまり、家庭の無線LANアクセスポイントのMACアドレスを誰かに知られることは、住所を知られることに等しい。そのような事態をPlaceEngineサービス(および類似のサービス)が新たに作り出したことになる。 「MACアドレスは個人を特定するものではない」と言えるだろうか?もし、別のネットサービスで、何らかの目的で家庭の無線LANのMACアドレスを登録して使うサービスが始まったとする。そのサービスもまた、「MACアドレスから個人が特定されることはありません」と主張するだろう。このとき、PlaceEngineとこのサービスの両者が存在することによって、わからないはずの住所が特定されてしまう事態が起きてくる。 PlaceEngineなどのサービスが存在する現
UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く