なぜこのようなことが起きているのでしょうか。想像できるのは、SPモードというプロバイダ単位でXSS対策をしようとしているのではないか、ということです。
ただその割には、一番基本的な<script>タグですらきちんと止める気がないような遮断条件であるし、特定のIPアドレスでは遮断されなかったりで、一体何がしたいのかというかんじもあります。
まずは限定的に導入してみて、影響がどれほどのものなのかのテストでもしているのでしょうか？それとも単にバグ？
まだ理由ははっきりしませんが、攻撃への対策であるのなら、正当なリクエストにも攻撃に近い文字列は入りうるので、今のアクセスすらさせない方法はやりすぎであると思います。現段階ではまだ非常に限られた文字列だけですが、今後防御範囲を拡大しようとして、さらに副作用が広がるようなことがないことを願います。
アノニマス匿名のハッカーがpastebinにtwitterアカウントのユーザ名とパスワード55,000以上を漏洩させたという書き込みがありました。（注:当初anonymous hackersをアノニマスハッカーと訳していましたが、ここは「匿名の」という意味ですね。訂正します）
真偽のほどはよくわかりませんが、ここに貼られていたパスワードを少し分析してみました。当然ながら、このパスワードを使ってログインしてみる、というのは違法行為ですので、絶対にやってはいけません。以下はあくまでもパスワード文字列の統計的な分析です。
まず、貼られていたアカウントの数ですが、単純に数えると、58,978個あり、約59,000というところです。ところが重複がかなりあり、ユニークなID:パスワードの組み合わせだと、34,069に減少します。さらに、「同一ユーザ名でパスワードが異なる」組み合わせが6個ありました。
また、twitterのログインでは、登録メールアドレスとユーザIDのどちらを使ってもログインできますが、pastebinに貼られていたユーザIDを見ると、メールアドレス形式のものと、ユーザID形式のものが混在しています。
これらの事実から、仮に「本物のtwitterアカウント」だとしても、取得した手法・経路や、時期などがまちまちである可能性が高いと考えられます。
次に、パスワードのみに着目して、使用頻度の多い上位20個を以下に示します。5番目はパスワード欄が空だったものです。
580個もある「315475」というパスワードが印象的です。これ、何かの意味があるのかなと最初思ったのですが、おそらくそうではなく、spam bot用に大量作成したアカウントで同一のパスワードを使っていたものではないか予想します(*1)。
また、現在のtwitterのパスワードポリシーでは登録できないパスワードが大量に入っています。そのポリシーとは、以下のようなものと思われます。
ブラックリストに載っている単語は、実際にやってみると分かりますが、「password」、「123456」などです。3位につけている「123456789」も駄目なようです。
次に、パスワードの長さについて調べてみました。結果は以下です。
8文字と6文字が多い理由は想像がつきますが、パスワードポリシー上登録できないはずの5文字以下のパスワードがかなりある理由は不明です。
以上から言えることはあまり多くなさそうです。
念のため自分のアカウントがリストにないか確認するとよいでしょう。また、仮にリストになくても、自分のtwitterパスワードをこの機会に変更しておくとよいと思います。
追記
CNETの記事にtwitterの広報担当者のコメントが出ています。
われわれは現在、この状況を調査しているところだ。さしあたって、影響を受けた可能性のあるアカウントにパスワードのリセットを要請した。
また、他のセキュリティ専門家から、当該リストは過去にLulzSecが公開したものとかなり重複しているという見解を示しています。
これらの状況から、twitter利用者があわてて対処をしなければならない状況ではなくなったと考えます。元々は、最悪ケースを想定して、公表されていないユーザのパスワードも漏洩している可能性を考慮して、パスワードリセットを推奨しましたが、現時点ではそこまでの緊急性は薄いと考えます（パスワードが元々弱いとか、使い回ししているか、twitterからパスワードリセットの指示が来た場合等は別です）。もちろん、心配であればパスワードリセットすることにより、それ以降の安全性を確実にすることができます。
以上、追記致します。
[PR]HASHコンサルティングが提供するセキュリティ情報メールマガジン(無料)
追記:より詳細の報告を公開しましたのでそちらを参照下さい
追記終わり。
昨日のメモでは、CVE-2012-1823の対処をFastCGIかmod_phpに移行するとしていたが、CGIのまま暫定対処する方法を以下に公開する。
PHPの設定が以下と想定する。
AddHandler application/x-httpd-php5 .php
Action application/x-httpd-php5 /cgi-bin/php-cgi
#!/bin/sh
exec /usr/local/bin/php-cgi
PHPの設定を以下のように変更する。/cgi-bin/ディレクトリにphp-cgi（CGI版PHP）がコピーしてある場合は削除する。
AddHandler application/x-httpd-php5 .php
Action application/x-httpd-php5 /cgi-bin/php-wrapper
すると、php-cgiにパラメータが渡されなくなることから、CVE-2012-1823の影響を回避することができる。php-cgiにパラメータを渡さなくても、PHPの実行に支障はない。もしも、php-cgiにオプションパラメータを渡す必要がある場合は、上記ラッパーにハードコードするとよい。
正常系の動作を含め、十分にテストすること。
参考: http://eindbazen.net/2012/05/php-cgi-advisory-cve-2012-1823/
追記:より詳細の報告を公開しましたのでそちらを参照下さい
追記終わり。
【概要】
PHP5.4.2で修正された脆弱性だが、直っていない。CGI版のみが影響を受ける。mod_phpやFastCGIによるPHP実行の場合影響なしとされる。
【影響】
・PHPの実行時オプションが外部から指定されるその結果として以下の影響がある
・リモートのスクリプト実行(影響甚大)
・PHPソースの表示
【影響を受けるサイト】
・PHPをCGIとして実行しているサイト（FastCGIは大丈夫らしい）
【回避策】
・PHP本家の改修リリース(5.4.2など)は不十分な対策（PHP5.4.2でもリモートコード実行できることを確認済み）
・mod_rewriteによる回避策も不十分らしいが情報不足
・FastCGIまたはmod_phpに移行することを推奨
・それが出来ない場合、サイトを閉鎖し、続報を待つこと
・CGI版の場合の回避策はこちら
第2回のメールマガジンのアジェンダ（案）です。第2回配信は5月10日頃を予定しています（無料）。
◎解説コラム：セキュリティ情報の集め方
hashdosを題材としてトリガーから裏とりまでの実際を解説します。
◎解説コラム：ドリランド複製祭りはこうして起こった…かも
PHPカンファレンス北海道で説明した内容を文章に起こします。
◎PHP入門書の脆弱性：ログインIDの重複チェックの問題他
とある売れ筋PHP入門書で見つけた会員登録時のログインID(メールアドレス)の重複チェックの不備を皮切りに、唖然とするバグ（仕様の不備?）、どうすればよいのかの解説。
◎自伝2：はてな村との遭遇
ブログを始めた徳丸が、はてな村と遭遇、とある会に行きたくなる…あたりまで。
◎宣伝：徳丸本講習ありマス
これはタイトル通り。
かねてご案内しておりましたHASHコンサルティングのメールマガジンですが、第1回配信内容を以下のように予定しております。
配信日は、うまくいけば（徳丸の記事執筆が順調であれば）、明日（4月27日）の予定です。
メルマガの説明・登録はこちらから、無料です。
0-9:
こないだShibuya.XSSで徳丸さんが紹介されてたObject.prototype.__defineSetter__を使ったJSON Hijackingに関して「Fx3系とAndroid 2系で動作する」とのことだったので検証してみた。
前書き
__defineSetter__とはブラウザベンダーが独自実装したProperty AccessorでECMAScriptには定義されていない（ECMAScriptでは別の方法が定義された）
具体的な使い方は以下のとおり。
hoge = {};
hoge.__defineSetter__(‘huga’,…
【中略】
上記のコードで検証した範囲では普通の{}形式では攻撃は成功せず、[]で包んだ場合のみ攻撃が成功した。
{}で囲った場合に攻撃が失敗する理由は、{}で囲ったものをJavaScriptのパーサは（オブジェクトではなく）ブロックとして解釈するからです。防御に利用可能とは思いますが、ドキュメントなどにその目的を残しておかないと、うっかり配列形式に仕様変更したら脆弱となるので気持ち悪い気がします。
すでに私のブログでご案内のように、PHPカンファレンス北海道で講演します。このエントリでは、講演の聞き所と、講演を十分に理解するための事前課題をご案内します。
このネタをやろうと思ったきっかけは、OpenPNEの以下のセキュリティリリースです。
キャッシュ経由での情報漏洩は、脆弱性診断屋の診断項目には入っています（但し上級プランのみの場合が多い）が、あまりこの問題が脆弱情報として流れてくるのを見た記憶がありません。徳丸本にも、この問題は載せていません。このため、落ち穂拾い的にこの問題を取り上げようと思いました。
OpenPNEの対策前のバージョンとProxyサーバー(squid)を用いて、特定条件で情報漏洩（別人問題）が発生する様子を実演し、対策を示します。
事前課題は、先のOpenPNEのリリースです。この案内はとても詳細かつ良心的であり、ソフトウェア製品のセキュリティリリースのお手本として読むことができます。
クリックジャッキングについては、ついこの間まで「知る人ぞ知る」というレベル感だったのに、いつの間にか「対策必須」という感じになってきました。基本的には、昨年のPHPカンファレンスの内容の再演となります。
昨年の模様は、以下からスライドとビデオを視聴することができます。
クリックジャッキングはスライド31、ビデオは21:10頃からとなります。これを見ておくことが事前課題です。また、徳丸本P63のコラム「X-FRAME-OPTIONS」を読んでおくと良いでしょう。また、CSRF（徳丸本P141～）も理解しておいてください。
Ajaxはいつの間にか「当たり前」の技術になりましたが、セキュリティの解説は未だにほとんどありません。Ajaxの解説書にも脆弱性が見られます。基本的には、以下のエントリで解説した内容を、デモを交えて詳しく解説します。以下三部作を事前に読んでおいてください。
基本的には、Shibuya.XSS テクニカルトーク#1のLTで5分でやった内容を20分くらい使ってしゃべる予定です。Shibuya.XSSで割愛したevalインジェクションやAjaxのCSRFにも言及できればと思います。
ドリランドの件は運営側から詳細原因が公表されていないため、あくまで推測、ないし妄想レベルの話になってしまいますが、おそらくレースコンディションだろうという想定で、排他制御不備によるカード増殖のデモおよび対策、残る課題について解説します。
事前課題としては、ばけらさんの以下を読んでください。
また、徳丸本の「4.15共有資源に関する問題」(P300～)を読んでおくことと、適当な入門書などでRDBのトランザクションとロックの解説を読んでおいてください。PHP系の入門書でトランザクションをまともに解説している書籍は石井達夫さんの
くらいしか知りません。同書でももちろんいいですし、RDBの解説書でもよいでしょう。
それでは、札幌でお会いしましょう。
このエントリを書くにあたり、はせがわようすけ氏の以下ツイートに刺激を受けました
4,5年くらい前、勉強会って講師の人に周りの参加者が「事前に何を予習しておいたらいいですかねー」とかの会話があらかじめ飛び交ったりしてた覚えあって、ほんとうに全員が勉強になってたんだけど、最近はカジュアルになりすぎて勉強会って名前のただのオフ会化。
— Yosuke HASEGAWAさん (@hasegawayosuke) 4月 12, 2012
[PR]
WAF始めました。詳しくはHASHコンサルティング株式会社まで。
「安全なWebアプリケーションの作り方」DRMフリーのPDFによる電子版もあります。
はてなブックマークボタンを外しましたでご案内しましたように「当面の間、はてなのサービス（ブックマーク、日記）は少なくとも新規の更新をやめ」ておりましたが、それから一ヶ月が経過し、株式会社はてなの対応も変化がないようですので、当面ではなく恒久的に上記の更新をやめようと思います。
これまでの間、両サービスの移行先を検討しておりましたが、以下のようにしたいと思います。
はてなダイアリーについては、ここtumblrを移行先とします。徳丸は他のブログも運用しておりますが以下のような使い分けにしたいと思います。
従来のはてなダイアリーには、軽めの技術ネタも書いていましたが、ネタ成分の多いもの以外は「徳丸浩の日記」に集約しようと思います。なお、はてなダイアリーは新規更新を止めるのみで、データ移行や閉鎖はしないつもりです。
なお、移行先をtumblrにした理由は、「既に使っていた」からです。twitterでは長すぎ、ブログにするほどでないネタを書くのに使っていました。あまりサイトを分散させるのも好ましくないため、tumblrに集約したということです。これに伴い、tumblrをtokumaru.orgドメインで運用することにしました。独自ドメインであれば、いざというときに移行の手段が得やすいというメリットがあります。
はてなブックマークからライブドアクリップに移行します。過去のデータは移行しておりますが、はてなブックマークの閉鎖はしません。ライブドアクリックに移行することに決めた判断のポイントは以下です。
また、ブックマークの内容は、twitterとGoogle+にも流します。それぞれお好きなところでご覧頂き、コメントなど頂ければ嬉しいです。何度も読むことになる方々には申し訳ありません。
以上、今後ともよろしくお願い致します。
「パーフェクトPHP+徳丸本セットを抽選で1名に差し上げちゃうキャンペーン」の抽選サイトを用意いたしましたのでご連絡いたします。
URLは http://amida.tokumaru.org/ です。現在は以下のように待機中となっております。応募者の方は、ご自分のIDが載っているか、ご確認ください。
これはただのHTMLですが、meta refreshで定期的に再読み込みするようになっていまして、抽選開示時刻に合わせて再読み込みの間隔が短くなるようになっています。CGI等ではなく、HTMLファイルをシェルスクリプトが生成しています。セキュアですね。
抽選が始まると、一定秒数毎に落選者が1人決まります。公約通り、落選者の選定には、暗号論的乱数を用いています。
その際に、画面の左上は以下のようになります。
落選者の欄が×となり、背景もグレーになります。また、表の右側に落選者のログが表示されます。
上記の時刻はテスト時のものでして、間隔は適宜調整いたします。残った応募者が1人になったら、その方が当選者です。画面左上が以下のようになります。
それでは、応募者の方は、明日12時13時に抽選サイトをご覧ください。
当選者には別途twitter等でご案内いたします。抽選サイトを見るのはドキドキしていやという方は、twitterでのアナウンスをお待ちください。
