http://co3k.org/blog/csrf-token-should-not-be-session-id について。
この記事では触れられていませんが、
この際ハッキリ言っておくべきだと思うので書きますが、そもそもセッションIDを(HTMLソース中に埋め込む)CSRF対策トークンとして使うのは間違いでした。最初から間違っていたのです。正確に言うとCSRFの話は関係ないですね。CSRF関係なく、特に「単体で」セッションハイジャックが可能になるような値を、HTMLソース中に埋め込むべきではありません。
2014-07-09 それぞれ修正されたのを確認したので追記します。
APSB14-17 で修正されたようです
筆者が把握している範囲で、最新版のFlash Playerを利用している場合に、(crossdomain.xmlもしくはユーザーの許可なしで)cross originでカスタムヘッダを付与する方法はありません。
Webサイト運営者は
@ITやテッククランチがアホすぎてつらい。
Rap GeniusというサービスがHerokuに月額2万ドル払っていて、そのサービスに満足していたという。 内訳はよくわからないが、Herokuの「サクセスストーリー」に公開されているところによると、彼らはWeb用のdynoを120使っているとのこと。 http://success.heroku.com/rapgenius
New Relic(サードパーティのパフォーマンス計測アドオン)には年間 $63116.13 払っているという。
Evernoteの話ですけど。「強固なパスワード暗号化技術を採用」していて、攻撃者がまず生パスワード復元できないだろう、という状況であっても、パスワードリセットはしたほうがいい。
2011年のLastpassのケースでは、強固なパスワード使っている人は大丈夫だけど、そうじゃない場合はブルートフォースでマスターパスワード取得されうるということを発表していた。これはハッシュ値生成のアルゴリズムが、既知 or 推測しやすい or ソースコードも含めて漏洩している、という時にこの状態になる。
"If you have a strong, non-dictionary based password or pass phrase, this shouldn't impact you - the potential threat here is brute forcing your master password using dictionary words, then going to LastPass with that password to get your data. Unfortunately not everyone picks a master password that's immune to brute forcing."
で、Evernoteのケースは「弊社は強固なパスワード暗号化技術を採用しておりますが」と言っている。
平日の業務時間内に見つけた問題である関係で(自分ルールで)所属を入れていますが、他社サービスに対する調査や報告は業務とは一切関係のない個人の活動として行っています。
文責はmala個人にあります。お問い合わせなどありましたら個人宛にどうぞ。TwitterのDMや任意の文字列 @ma.la
| 平文でパスワード保存されていた？と推測する奴は頭がおかしいのでエンジニアやめろ。 | |
| ---- | |
| まず事実関係 | |
| MUFGは、ID登録及び、ログインの際に、パスワード規定文字数を超えて「入力することができませんでした」と主張している。 | |
| http://www.cr.mufg.jp/corporate/info/pdf/2012/121120_01.pdf | |
| リニューアル前の直近のログインフォームでは、password入力のinput要素に各提携先に応じたmaxlengthが設定されていて、 |
| #!/usr/local/bin/perl | |
| # DoS tool for memcached | |
| # ulimit -n 15000; perl memcachedos.pl 127.0.0.1 11211 3 | |
| # original: http://gist.github.com/522741 | |
| # This is Public Domain Software | |
| use strict; | |
| use warnings; | |
| use AnyEvent; |
もう5年も前の話になっていたのだけど、Echofon(Twitterクライアントの一つ)の件を今更だけど書かねばならない。
当時、Echofonのプッシュ通知を管理するサーバーの認証機能に欠陥があり(というか認証が無く) 他のEchofon利用者に対して送られるpush通知(DMやreplyなど)を横取りすることが出来た。
このセキュリティホール自体は素早く修正されたのだけど、この件をきっかけに、クライアント/サーバーの境界線が曖昧になっている、という問題を強く意識するようになった。