追記（19日）東洋経済オンラインの的外れ記事 / 高木浩光＠自宅の日記 - 治外法権のeLTAX、マルウェア幇助を繰り返す無能業者は責任追及されて廃業に追い込まれよ
■ 治外法権のeLTAX、マルウェア幇助を繰り返す無能業者は責任追及されて廃業に追い込まれよ ここ数年、不正送金の被害がインターネットバンキングの法人口座で急増しているという*1。その原因は今更言うまでもなく、Java実行環境（JRE）やAdobe製品の古いバージョンの脆弱性を突いてくるマルウェアである。しかしそれにしても、法人口座を扱うパソコンがなぜ、Java実行環境やAdobe製品をインストールしているのだろうか。インストールしなければ被害も起きないのに……。 その謎を解く鍵が、eLTAX（地方税ポータルシステム）にあるようだ。eLTAXでは、インターネットバンキングの口座を用いた納税ができることから、インターネットバンキング用のパソコンでeLTAXの利用環境も整えるということが普通になっていると思われる。そのeLTAXが、昨日までは、Java実行環境のインストールを強要していた。eL
総務省｜報道資料｜ウェブサービスに関するID・パスワードの管理・運用実態調査結果
総務省は、この度ウェブサービスを提供する企業におけるID・パスワードの管理・運用実態について調査した結果を取りまとめましたので公表します。 現在、インターネットショッピングやインターネットバンキング、ソーシャルネットワーキングサービス等、インターネットを通じて様々なサービスが提供されています。 総務省では、ウェブサービスにおいて利用者を確認する主な手段としてID・パスワードが利用されていることを踏まえ、ウェブサービスを提供する企業におけるID・パスワードの管理・運用実態について調査を行いました。 （1）約9割のサービスで3種類以上の文字種をパスワードとして利用できる パスワードとして利用可能な文字種（大文字・小文字・数字・記号）について、約9割が3種類以上利用可能であり、6割近くが4種類利用可能である等、大半のサービスで複数の文字種の組み合わせによるパスワードの設定が可能となっている。 （
高木浩光＠自宅の日記 - 共用SSLサーバの危険性が理解されていない
■ 共用SSLサーバの危険性が理解されていない さくらインターネットの公式FAQに次の記述があるのに気づいた。 [000735]共有SSLの利用を考えていますが、注意すべき事項はありますか？, さくらインターネット よくある質問（FAQ）, 2010年2月10日更新（初出日不明） Cookieは、パスなどを指定することができるため、初期ドメイン以外では共有SSLを利用している場合にCookieのパスを正しく指定しないと、同じサーバの他ユーザに盗まれる可能性があります。 （略） 上記については、「同サーバを利用しているユーザだけがCookieをのぞき見ることができる」というごく限定的な影響を示していています。また、Cookieの取扱いについて、問い合わせフォームやショッピングカート等、ビジネス向けのウェブコンテンツを設置されていなければ特に大きな問題とはなりませんが、個人情報を取り扱われる管
高木浩光＠自宅の日記 - ここまで破綻しているケータイID認証（簡単ログイン）
■ ここまで破綻しているケータイID認証（簡単ログイン） 2009年夏、はてなブックマーク界隈では「かんたんログイン」が危ういという話題で持ち切りだった。IPアドレス制限をしていても突破できてしまうのではないかという話だった。 実際に動いてすぐ使える「PHPによるかんたんログインサンプル」を作ってみました, ke-tai.org, 2009年7月31日 SoftBank Mobileの携帯用GatewayをPCで通る方法のメモ, Perlとかmemoとか日記とか。, 2009年8月1日 ソフトバンクの携帯用GatewayをPCで通る方法があるようです, ke-tai.org, 2009年8月4日 これは要するに次のような話だった。 まず、SoftBankの携帯電話で特定のAPN mailwebservice.softbank.ne.jp でネット接続して、所定のProxyサーバ sbwap
高木浩光＠自宅の日記 - サイボウズOfficeも匙を投げた「簡単ログイン」
■ サイボウズOfficeも匙を投げた「簡単ログイン」 今年2月20日のこと、サイボウズOfficeに「簡単ログイン」機能があることに気づいた私は、以下の質問をサイボウズ社に送った。 「サイボウズ Office 8 ケータイ」の「簡単ログイン」機能についてお尋ねします。 「携帯端末認証に対応しているので、毎回ログインする手間なく利用できます」とのこと。試用版で試したところ、たしかに2度目以降はパスワードが不要のようです。 この機能は、いわゆる「契約者固有ID」を用いて実現しているものと理解していますが、「契約者固有ID」を用いて端末認証を行う場合、通常は、IPアドレス制限を行って、携帯電話事業者のゲートウェイのIPアドレスからのアクセスしか許さないように実装するものであると考えます。 しかしながら、「サイボウズ Office 8 ケータイ」はそうしたIPアドレス制限を施しておらず、一般のイ
高木浩光＠自宅の日記 - ユニークIDがあれば認証ができるという幻想
■ ユニークIDがあれば認証ができるという幻想 2008年のNTTドコモによるiモードID送信開始以降、ケータイWebの世界に「かんたんログイン」なるエセ認証方式が急速に広がり、その実態は「はてなのかんたんログインがオッピロゲだった件」のように惨憺たるものになっている。こうした欠陥サイトはかなりあると考えられ、すべてを調べて廻ることはできないが、いくつかのメジャーどころのサイトについては、IPAの脆弱性届出窓口に通報して、対策を促す作業をやっている。 各サイトの「かんたんログイン」に欠陥があるかどうかは、実際に他人のIDでなりすましログインしてテストすることは許されない（不正アクセス禁止法違反になる）ので、自分用のアカウントを作成して（会員登録して）、自分のIDについてテストするのであるが、誰でも会員登録できるわけでないサイトがかなりあるようで、そういったサイトはどうしたらよいのか。以下は
メッセサンオーの顧客情報漏洩、原因は化石級の杜撰なCGI | スラド セキュリティ
INTERNET Watchの記事が伝えているように、4月2日、ゲームや同人誌などを販売するメッセサンオーの顧客情報がGoogleにキャッシュされ、誰でも閲覧できる状態になっていたことが発覚した。現在はキャッシュが見えないよう対策されているが、m-birdの日記などによると、使われていたショッピングカートの管理画面が、URLにパスワードを含む仕様になっていたのが原因らしい。INTERNET Watchの記事は「追記」として、これがWEBインベンターが提供するCGIスクリプトだとし、開発元が対策を呼びかけていると伝えている。 しかし、その対策元の呼びかけは、「管理プログラムがGoogleにインデックスされないようにする」というもので、 「パスワード付きのURLが検索エンジンに拾われないようにするために気をつけてください」という注意喚起metaタグ（noindex,nofollow,noarc
このURLは存在しません。
■ なぜ一流企業はhttpsでの閲覧をさせないようにするのか 「かんたんログイン」などという似非認証方式は、たとえIPアドレス制限を実装したとしても安全でない。仕様が公開されていないからという点の他に、技術的な理由として、少なくとも次の2つがある。 「IPアドレス帯域」と俗称される重要情報が安全に配布されていない。 SSLを必要とするケータイサイトでは、通信経路上の攻撃によってなりすましログインされてしまう。*1 2番目には解決策がない。 1番目については解決策はあるだろうが、携帯電話事業者がサボタージュしていて、実現される見通しがない。これについては、2008年7月27日の日記にも書いたが、その後どうなったかを調べてみたところ、ソフトバンクモバイル以外は、何ら改善されておらず、当時のままだった。 NTTドコモ 「iモードセンタのIPアドレス帯域」のページをhttps:// でアクセスする
JR東日本サイトがまた改ざんされた模様 | スラド
改ざんされたファイルは前回とは違い、現在のところ原因も不明とのこと（Security NEXT）。 JR東日本の管理体制が甘いと言われても仕方ないけど、今回は4日 （2010年2月18日（木）22時29分～2010年2月22日（月）17時18分） [jreast.co.jp]でサービスを停止できたわけだからまだマシな感染事例ではないかと。 一方ガンブラー攻撃は次々亜種が登場し、攻撃の様相が様変わりしている模様。 イタチごっこ続くWebサイト改ざん、埋め込みコードがまたまた変化 [so-net.ne.jp]（2010/01/28 セキュリティ通信） 昨年12月から被害が続出している国内のWebサイト改ざんだが、28日未明から、再び改ざんサイトに埋め込むコードの書き換えが始まっている。 22日未明に「/*LGPL*/」から「/*Exception*/」に変わった際には、それまで検出できていたウ
高木浩光＠自宅の日記 - はてなのかんたんログインがオッピロゲだった件
■ はてなのかんたんログインがオッピロゲだった件 かんたんログイン手法の脆弱性に対する責任は誰にあるのか, 徳丸浩の日記, 2010年2月12日 といった問題が指摘されているところだが、それ以前の話があるので書いておかねばならない。 昨年夏の話。 2009年8月初め、はてなブックマーク界隈では、ケータイサイトの「iモードID」などの契約者固有IDを用いた、いわゆる「かんたんログイン」機能の実装が危ういという話題で持ち切りだった。かんたんログイン実装のために必須の、IPアドレス制限*1を突破できてしまうのではないかという話だ。 実際に動いてすぐ使える「PHPによるかんたんログインサンプル」を作ってみました, ke-tai.org, 2009年7月31日 SoftBank Mobileの携帯用GatewayをPCで通る方法のメモ, Perlとかmemoとか日記とか。, 2009年8月1日 ソフ
高木浩光＠自宅の日記 - エコポイント申請画面が共用SSLサイト上にある件
■ エコポイント申請画面が共用SSLサイト上にある件 「エコポイント」の情報システムがわずか３週間で完成した理由, 有賀貞一, NIKKEI NET, 2009年8月26日 こうした問題を解決するために、エコポイント事務局と関係省庁が選択したのが、米セールスフォース・ドットコムの基盤サービス「Force.com」だった。セールスフォースはこのForce.comを「クラウドコンピューティングプラットフォーム」と表現している。利用者はサーバーなどのインフラを持つことなく、この基盤上で独自のシステムを構築できる。 という記事を読んで、「エコポイント」のサイトを初めて訪れたのだが、これはまずい。 「エコポイント」公式サイトの運営者は、「グリーン家電エコポイント事務局」となっていて、プライバシーポリシーでも個人情報取扱責任者が「グリーン家電エコポイント事務局」として書かれている。しかし、国民の視点か
高木浩光＠自宅の日記 - やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合
■ やはり退化していた日本のWeb開発者「ニコニコ動画×iPhone OS」の場合 一年前、「退化してゆく日本のWeb開発者」という題で、ケータイWebの技術面での蛸壺化について次のように書いた。 iPhoneに契約者固有ID送信機能が搭載される日 （略）こうして退化してゆくケータイWebが、日本のスタンダードとなってしまい、いつの日か、PC向けの普通のインターネットまで、単一IDの全サイト送信が必須になってしまうのではないかと危惧した。 （略）iPod touchでNAVITIMEを動かしてみたところ、下の図のようになった。 （略）契約者固有IDがないとどうやって会員登録システムを作ったらいいのかわからないんじゃないのか……というのはさすがに穿ち過ぎだと思いたい。NAVITIMEからソフトバンクモバイルに対して、契約者固有ID送信用プロキシサーバの用意を要請している……なんてことがなけれ
高木浩光＠自宅の日記 - 「NoScript」をやめて「RequestPolicy」にした
■ 「NoScript」をやめて「RequestPolicy」にした セキュリティ屋が、Firefoxユーザに「NoScript」の使用を推奨することがしばしばあるが、私は賛同しない。 JPCERT/CC、技術メモ「安全なWebブラウザの使い方」を公開, INTERNET Watch, 2008年11月4日 *1 技術メモ − 安全なWebブラウザの使い方, JPCERT/CC, 2008年11月4日 IV. 各 Web ブラウザに共通する設定上の注意事項 1. スクリプト等の実行を制限する JavaScript 等のスクリプトや（略）は（略）Ajax に代表されるインタラクティブなインターフェースが実現できるなど、高い利便性が得られます。反面、PC 上の重要なファイルを削除・変更するなど、悪意を持った処理が行われる可能性もあります。従って無制限にスクリプト等を実行できるようにしておくのは
高木浩光＠自宅の日記 - 楽天CERTに対するブラウザの脆弱性修正を阻害しない意思確認
■ 楽天CERTに対するブラウザの脆弱性修正を阻害しない意思確認 楽天は比較的早い時期からコンピュータセキュリティに真剣に取り組んできた希有な存在だと認識している。昨年には、企業内CSIRTを正式に組織し、組織名を「Rakuten-CERT」とした。*1 楽天、社内に「CSIRT」を設置, ITmediaエグゼクティブ, 2007年12月6日 「楽天ad4U」の「脆弱性を突いてブラウザの閲覧履歴を調べるという禁じ手」の問題（前回の日記参照）は、その手法自体が直接人々のプライバシーを侵害するか否かという問題ではない。実際、「楽天ad4U」について言えば、閲覧履歴の有無は参照するけれども履歴自体の送信はしないように作られており、開発元はこれを「プライバシー保護にも優れています」と宣伝している。 しかし、この問題の根本は、10月の日経の記事にも書いたように、この手法が広く使われるようになって、こ
高木浩光＠自宅の日記 - 無責任なキャリア様に群がるIDクレクレ乞食 ―― 退化してゆく日本のWeb開発者
馬鹿じゃないのか。このようなセキュリティに関わる情報公開ページは https:// で提供する（閲覧者が望めば https:// でも閲覧できるようにする）のが当然なのに、携帯電話会社ともあろうものが、そろいもそろってこんな認識なのだ。 （8月2日追記: ソフトバンクモバイルについては「7月27日の日記に追記」参照のこと。） それをまた、ケータイWeb関係者の誰ひとり、疑問の声をあげていないことがまた、信じ難い。何の疑問も抱かずにこれをそのまま設定しているのだろう。 こんな状態では、ケータイWebの運営者は、DNSポイゾニング等で偽ページを閲覧させられても、気付かずに、偽アドレス入りの帯域表を信じてしまうだろう。 つまり、たとえば、example.jp というケータイサイトを運営している会社が example.co.jp であるときに、攻撃者は、example.co.jp のDNSサーバに
高木浩光＠自宅の日記 - 緑シグナルが点灯しないのに誰も気にしていない？という不思議, 追記
■ 緑シグナルが点灯しないのに誰も気にしていない？という不思議 フィッシング対策ソフトの導入動向 最近、金融機関が「PhishWall」や「PhishCut」を導入したというニュースをよく見かけるなあと思っていたら、どうやら、金融庁の監督指針の今年の改定でフィッシング対策について明記されたことが関係しているらしい。 主要行等向けの総合的な監督指針（平成19年6月版）, 中小・地域金融機関向けの総合的な監督指針（平成19年8月版）, 金融庁 III-3-7 インターネットバンキング III-3-7-2 主な着眼点 (2) セキュリティの確保 ホームページのリンクに関し、利用者が取引相手を誤認するような構成になっていないか。また、フィッシング詐欺対策については、利用者がアクセスしているサイトが真正なサイトであることの証明を確認できるような措置を講じる等、業務に応じた適切な不正防止策を講じている
高木浩光＠自宅の日記 - 対策にならないフィッシング対策がまたもや無批判に宣伝されている, 追記（26日）
■ 対策にならないフィッシング対策がまたもや無批判に宣伝されている 「PCからオンライン取引、ケータイで認証」−ソフトバンクBBの新発想・認証サービス, Enterprise Watch, 2007年9月20日 「同サービスはまったく新しい認証の手段だ。暗号化技術にも依存しないので、クラッカーとのいたちごっこにもならず、これまでの認証の問題を一挙に解決することが可能。本当の意味でIT革命が起こせると期待できるサービスだ」と意気込みをあらわにしながら説明を行った。（略） 「PCを標的にしたハッキングやDoS攻撃を受ける可能性がゼロになる」（中島氏）。また、偽サイトとはシンクロしないため、フィッシング詐欺を100％防止することも可能だ。 ソフトバンクBB、携帯活用認証システムでWebサイトログイン対応に, ケータイWatch, 2007年9月20日 今回の新機能は、安全・簡便・低コストで、そう
ウィルスバスター（トレンドマイクロ）からのアクセス - えむもじら
Nothing ventured, nothing gained で話題になっていた 66.180.82.*からのアクセス、調べてみたらうちでも結構ありました。ただし、 Nothing ventured, nothing gained. - 66.180.82.*からのアクセス ウイルスバスター2007でURLフィルタをオンにしていると、アクセスする先のURLをトレンドマイクロのサーバーに送り、トレンドマイクロのサーバーから先に該当URLにアクセスし、サイトの安全性を確認してから、ブラウザがURLにアクセスするような仕様になっているらしい。 とのことですが、うちの最近のログを調べた限りでは、先にブラウザからのアクセスがあり、その2,3秒後にトレンドマイクロからのアクセスとなっているようです。 ウイルスバスター2007とアクセスIP66.180.82.xx - 暇人STRのブログによると、ア
高木浩光＠自宅の日記 - ケータイWebはそろそろ危険
■ ケータイWebはそろそろ危険 これまでの背景と最近の状況変化 「安全なWebサイト利用の鉄則」にある通り、フィッシングに騙されずにWebを安全に使う基本手順は、（パスワードやカード番号などの）重要な情報を入力する直前に今見ているページのアドレスを確認することなのだが、しばしば、「そのページにアクセスする前にジャンプ先URLを確認する」という手順を掲げる人がいる。しかし、それは次の理由で失当である。 ジャンプ先URLを確認する手段がない。ステータスバーは古来よりJavaScriptで自由に書き換えられる表示欄とされてきたのであり、ジャンプ先の確認に使えない。 ジャンプ先URLを事前に確認したとしても、それが（任意サイトへの）リダイレクタになっている場合、最終的にどこへアクセスすることになるか不明。 そもそも、アクセスする前から、アドレス確認の必要性を予見できるとは限らない。普通は、アクセ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
サウンドハウス、情報流出について詳細な経緯を公開 | スラド セキュリティ