公開: 2012年2月12日21時35分頃 このお話は興味深いですね……「「管理者パスワードは何日ごとに変更すればよいか」に関する質疑応答 (d.hatena.ne.jp)」。 Q1:上位ポリシーにて、管理者パスワードは定期的に変更するように義務づけられているが、何日毎に変更するのが正しいのか。最近の専門家の見解をお伺いしたい そもそも、「定期的に変更するように義務づけ」ているのに、変更のスパンを決めていないというのがひどい話です。それでは、たとえ「100年に一回」でもポリシーを満たすことになってしまい、義務づけの意味がありません。しかし、実際にはそういうポリシーが多いというのが現実でしょうね。 徳丸さんの答えはこちら。 一般ユーザのパスワードとは異なり、管理者パスワードは、業務の必要上複数の人が知っている状況があります。その状況では、「定期的に変更」するのではなく、管理者パスワードを知っ
更新: 2012年1月20日1時0分頃 これは興味深いですね……「Webアプリケーションに対する広範なDoS攻撃手法(hashdos)の影響と対策 (blog.tokumaru.org)」。 PHPなど多くの言語では、文字列をキーとする配列（連想配列、ハッシュ）が用意されており、HTTPリクエストのパラメータも連想配列の形で提供されます。PHPの場合、$_GET、$_POSTなどです。 連想配列の実装には、高速な検索が要求されるためハッシュテーブルが用いられます。ハッシュテーブルは、文字列を整数値（ハッシュ値）に変換するハッシュ関数を用いて、平均的には一定時間に検索・挿入・削除が行えるデータ構造です。しかし、ハッシュ値が一致する（衝突する）キー文字列については、通常ハッシュテーブルは順次的な探索となり、検索・挿入などが遅くなります。 以上、Webアプリケーションに対する広範なDoS攻撃手法
公開: 2011年10月3日1時50分頃 JPRSが「都道府県型JPドメイン」なるものの導入を発表したことが話題に……「JPRSが、地域に根ざした新たなドメイン名空間「都道府県型JPドメイン名」の新設を決定 (jprs.co.jp)」。 既に「地域型JPドメイン名」というものがあります。よく知られているのは地方公共団体が使用しているドメインでしょう。たとえば東京都は metro.tokyo.jp というドメインを使っていますし、港区はcity.minato.tokyo.jpを使っています (Webはどちらもwwwをつける必要があります。http://www.metro.tokyo.jp/ (www.metro.tokyo.jp)、http://www.city.minato.tokyo.jp (www.city.minato.tokyo.jp))。 しかし、実はこれだけではありません。あま
公開: 2011年7月15日2時10分頃 これは驚きました……「モバイルバンキングは今でもsecure.softbank.ne.jp方式が主流 (d.hatena.ne.jp)」。 以下は、ログイン画面のURLがhttps://secure.softbank.ne.jp/～となっています。大手都市銀行は全てという感じです。 三井住友銀行三菱東京UFJ銀行みずほ銀行りそな銀行セブン銀行じぶん銀行住信SBIネット銀行楽天銀行新生銀行secure.softbank.ne.jpはホワイトリスト方式で残されるということでしたが、上記モバイルバンキングは、そのホワイトリストの対象なのでしょう。 なんということでしょう。 7月からは、secure.softbank.ne.jpで表示されるのは公式サイトのみ (かつ、ソフトバンクに申請したサイトのみ) になりましたから、公式サイトと無関係の者が罠コンテンツ
公開: 2011年7月11日2時10分頃 secure.softbank.ne.jpが廃止されたことに伴い、なぜ廃止しなければならなかったのか、その背景についての解説が相次いで公開されています。 secure.softbank.ne.jp ヤバイの話 (subtech.g.hatena.ne.jp)SoftBankガラケーの致命的な脆弱性がようやく解消 (takagi-hiromitsu.jp)ソフトバンクのゲートウェイ型SSLの脆弱性を振り返る (blog.tokumaru.org)secure.softbank.ne.jp ヤバイの話+ (subtech.g.hatena.ne.jp)先月まで、ソフトバンクのケータイサイトで https://example.com/ へのリンクを辿ろうとすると、以下のような動作になっていました。 ソフトバンクのケータイでサイトにアクセスすると、ゲートウ
更新: 2011年7月10日9時20分頃 徳丸本のあれこれを実践してみて気付いたことの続きです。 前回、ストレッチングの回数をどうするのかが難しいと書きました。負荷を心配しつつ1000回で実装してみたのですが、実際に動かしてみると処理が一瞬で終わってしまい、速すぎて心細く感じるほどでした。 アプリケーションの機能は一通り実装し終わり、テスト運用を始めたのですが、しばらく運用してみてもログインが遅いとか、それに伴って負荷が高くなるといったことは起きませんでした。 というわけで、もう少し遅くしてストレッチパワーをためた方が良いのではないかと考え、調整することにしました。 ハッシュアルゴリズムの変更まず、ハッシュアルゴリズムをSHA512に変更しました。徳丸本 (www.amazon.co.jp)ではSHA256が使われていますが、SHA512の方が遅く、生成されるハッシュ値も長くなります。遅い
公開: 2010年5月26日1時25分頃 WASForum Conference 2010、オープニングセッションに続いて、ヤフーの松岡泰三さんによる「国民のためのウェブサイトを運営するID認証の舞台裏」。松岡さんは「R&D統括本部プラットフォーム開発本部セントラル開発1部」に属し、OpenID、OAuth、認証API、認証(ログイン)、ソーシャルプラットフォーム、ストレージプラットフォーム、外部サービス連携……といった諸々のお仕事をされているそうで。 今回のお話は大きく前後半に分かれていて、前半はYahoo!の認証に関する仕組みや統計データについてのお話、後半は外部サービスとの連携の話になっていました。まずは前半部分のメモから。 Yahoo! Japan ID の現在アクティブユーザ数 …… 2396万IDYahoo!ウォレットのユーザ数 …… 1900万Yahoo!プレミアムの会員数
更新: 2011年7月9日23時0分頃 とあるシステムで徳丸本のストレッチングを採用することにしたという話がありましたが、その実装が佳境に入ってきました。私は指示だけ出して、実装はお任せ……と思っていたのですが、基本的な部分を作ってもらったところでバトンタッチされ、私が引き継ぐ形で実際にコードを書くことになりました。 基本的には徳丸本 (www.amazon.co.jp)のオススメどおりの実装にするという方針なのですが、実際にコードを書いてみると、いろいろと気になったり迷ったりした事も出てきました。そのあたりを簡単にメモしておきます。 ※ちなみに、このシステムはRuby1.9.2 + Ruby on Rails3での実装なので、PHPのコードサンプルをそのまま使っているわけではありません。 ストレッチ回数をどう決めるのか徳丸本327ページにあるコード例を参考にして実装。アプリケーションごと
このように、レビュアーの皆様には、字句の間違い指摘というレベルを超えて、非常に本質的な「この脆弱性のなりたちは何か」という議論に及ぶこともあり、私自身非常に勉強になりました。 と、徳丸さんも書かれているように、誤字脱字の指摘が中心かと思いきや、そうでもありませんでした。「この脆弱性の本質は何か」とか「この保険的対策は実施した方が良いのか」といった、かなり奥深い部分から考え直す機会が何度もあり、面白かったです。しかも調子に乗って「追加でこれを書いてほしい」というリクエストまで出してしまい……。どう考えてもレビューの枠を超えていますが、それでも快く対応していただきました。本当にありがとうございます。 他に面白いと思ったのは、なぜか役割分担ができているように感じたことでしょうか。たとえばPHPを中心に見られている方、VMを中心に見られている方など、自然に担当が分かれるような感じになっていて、その
公開: 2011年2月18日22時35分頃 徳丸さんのセキュリティ本、Amazonで予約できるようになりましたね。 体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践 (www.amazon.co.jp)業界ではおそらく「徳丸本」と呼ばれることになるでしょう。 実は私もレビュアーとして参加していたので、一冊いただけることになっているのでした。レビューの内容などについては、また改めて書こうかと思います。 ※しかし、「11%のカスタマーが魔法少女まどか☆マギカ (1) (www.amazon.co.jp)を購入しています」と言われるのがメッチャ気になるのですけれど……。
更新: 2008年10月29日 「PHPでのセキュリティ対策についてのメモ (note.openvista.jp)」。なかなか良くまとまっていると思いますが、CSRFの話で少し気になった点が。 第三者が知り得ない文字列（ユーザIDやワンタイムトークンなど）をハッシュ関数（md5関数やsha1関数）を複数回用いて擬似乱数化した文字列をフォームに埋め込んでおき、サーバ側で照合することで、リクエストが利用者の意図した動作かどうかをチェックする 以上、PHPでのセキュリティ対策についてのメモ クロスサイトリクエストフォージェリ（略称：CSRF） より ※強調は引用者による。原文では<span class="weaken">でマーク付けされている ※2008-10-29追記: 引用した部分は既に修正されています。 「疑似乱数化」ってなんでしょう……。「疑似乱数」は良く聞きますが、「疑似乱数化」は耳慣
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
