タグ

ブックマーク / bakera.jp (17)

  • 徳丸本のあれこれを実践してみて気付いたこと | 水無月ばけらのえび日記

    更新: 2011年7月9日23時0分頃 とあるシステムで徳丸のストレッチングを採用することにしたという話がありましたが、その実装が佳境に入ってきました。私は指示だけ出して、実装はお任せ……と思っていたのですが、基的な部分を作ってもらったところでバトンタッチされ、私が引き継ぐ形で実際にコードを書くことになりました。 基的には徳丸 (www.amazon.co.jp)のオススメどおりの実装にするという方針なのですが、実際にコードを書いてみると、いろいろと気になったり迷ったりした事も出てきました。そのあたりを簡単にメモしておきます。 ※ちなみに、このシステムはRuby1.9.2 + Ruby on Rails3での実装なので、PHPのコードサンプルをそのまま使っているわけではありません。 ストレッチ回数をどう決めるのか徳丸327ページにあるコード例を参考にして実装。アプリケーションごと

    hiro_y
    hiro_y 2011/06/27
    パスワードのストレッチングの回数をどうするか問題など
  • ストレッチング採用の理由 | 水無月ばけらのえび日記

    更新: 2011年5月30日10時50分頃 徳丸さんに誘われ、徳丸 (www.amazon.co.jp)レビュアー中心に6名ほどで飲みいしながら四方山話をしたり。 翌日に徳丸さんはこんなつぶやきをしておられますが、 同じく昨日の一言。「パスワードのストレッチングについては効果を疑問視する声もあったが、『教科書』にベストプラクティスとして載っている以上、最低限そこまではやるべきと主張して、徳丸の通りに実装することにした」<こういう声は嬉しいですね 以上、http://twitter.com/ockeghem/status/73526372642988032 より これは私の発言ですね。せっかくなので、もう少し流れを補足しておきます。 サーバ側でパスワードを保存する際、パスワードそのものではなく、ハッシュ関数を通したハッシュ値を保存することが良く行われます。これによって、たとえDBの値が

    hiro_y
    hiro_y 2011/06/27
    パスワードのストレッチング、「ハッシュ関数を何度も使った結果を保存するという手法です。」
  • 第1回アクセシビリティBAR~初夏のパンくず祭 | 水無月ばけらのえび日記

    公開: 2011年6月5日17時55分頃 以前からやろうといっていた「パンくず祭」、ついに実現! 第1回「アクセシビリティBAR(仮称)」初夏のパンくず祭 (atnd.org)Togetter - 「第1回「アクセシビリティBAR(仮称)」初夏のパンくず祭」 (togetter.com)第1回アクセシビリティBAR『初夏のパンくず祭』に行ってきた (sho.tdiary.net)覚え書き@kazuhi.to: 第1回「アクセシビリティBAR(仮称)」初夏のパンくず祭 (kidachi.kazuhi.to)参加者はウェブアクセシビリティ基盤委員会ワーキンググループ2 (waic.jp)のメンバー7人とを中心に、3人を加えた合計10人。そういう構成だったこともあり、ちょっと内輪ネタが多かったような感じもなきにしもあらずですが、全体としてはとても面白い話ができたと思います。 議論の中心になったの

    hiro_y
    hiro_y 2011/06/06
    パンくずリスト談義
  • サンシャイン牧場 情報「露出」問題のまとめ | 鳩丸よもやま話

    「サンシャイン牧場」において、課金操作を行った人のメールアドレスと電話番号が「露出」していた件のまとめです。 はじめに「サンシャイン牧場」はmixiアプリとして提供されているゲームです。mixiアプリとしては最大の利用者数を誇り、2009年11月23日現在、利用者は300万人を突破しています。運営しているのはRekooという中国の会社です (が、最近、日法人もできました)。 2009年10月21日、サンシャイン牧場に「Kコイン」の仕組みが導入されました。実際のお金を支払って「Kチャージ」を行うとKコインが増え、Kコインを消費することで、通常では購入できない作物や肥料などを手に入れられる仕組みです。リアルのお金を支払ってアイテムを購入するという、いわゆるアイテム課金の制度になります。支払い方法は、株式会社ゼロの決済代行サービスを利用したクレジットカード払いでした。 ところが、この課金に際し

    hiro_y
    hiro_y 2009/11/23
    サンシャイン牧場問題まとめ。そもそも認証が行われていなかったということか。
  • スピンドクターと脆弱性関連情報 | 水無月ばけらのえび日記

    公開: 2009年11月10日22時5分頃 読み終わったので。 スピンドクター “モミ消しのプロ”が駆使する「情報操作」の技術 (www.amazon.co.jp)スピン = 情報操作のお話。さまざまな操作の例が紹介されているのですが、興味深いと思ったのは、先に情報を出してニュースとしての価値を低下させてしまうという手法。「しんぶん赤旗」にスクープさせると、他紙が後追い取材をしなくなるとか……。民主党偽メール事件の話も非常に興味深かったですね。 ※個人的に期待していたネット情報操作の話は、最後にちょこっと出ていただけで、ほぼ既知の話でした。そこは少し残念でしたが、他の部分は読み応えがあったかと。 しかし考えてみれば、脆弱性関連の報道やリリースなんてのは「スピン」の典型例でしょうね。 私が発見・報告して報道された事例としては、最近ではサンシャイン牧場、古くはニフティのXSS、JVNアンケート

    hiro_y
    hiro_y 2009/11/18
    webの脆弱性関連の情報操作。なるべく表に出さない、なるべく控えめにアナウンス。
  • W2Cマークアップエンジニア・ワーキンググループ 「マークアップエンジニアが知っておきたい3つの脆弱性」 | 作者プロフィール

    2009年9月16日、W2Cマークアップエンジニア・ワーキンググループでお話しした「マークアップエンジニアが知っておきたい3つの脆弱性」に関するサポートページです。とりあえず資料がダウンロードできます。 資料ダウンロードプレゼンテーション資料の PDF 版がダウンロードできます。 bakera_w2cWG.pdf (PDFファイル 487KB) 無断での再配布はご遠慮ください。また、資料内に含まれる画面キャプチャは全て削除されていますので、一部不自然な空白があります。 以下に若干の補足があります。 マークアップエンジニアが知っておきたい3つの脆弱性:補足 参考サイト話の中で触れたり、参考にしたりしたサイトです。 情報処理推進機構 (www.ipa.go.jp)経済産業省告示「ソフトウエア製品等脆弱性関連情報取扱基準」(PDF) (www.meti.go.jp)ソフトウェア等の脆弱性関連情報

    hiro_y
    hiro_y 2009/10/03
    セキュリティはきちんと理解して対処すること。
  • ワンタイムトークンをハッシュ関数で処理する意味はある? | 水無月ばけらのえび日記

    更新: 2008年10月29日 「PHPでのセキュリティ対策についてのメモ (note.openvista.jp)」。なかなか良くまとまっていると思いますが、CSRFの話で少し気になった点が。 第三者が知り得ない文字列(ユーザIDやワンタイムトークンなど)をハッシュ関数(md5関数やsha1関数)を複数回用いて擬似乱数化した文字列をフォームに埋め込んでおき、サーバ側で照合することで、リクエストが利用者の意図した動作かどうかをチェックする 以上、PHPでのセキュリティ対策についてのメモ クロスサイトリクエストフォージェリ(略称:CSRF) より ※強調は引用者による。原文では<span class="weaken">でマーク付けされている ※2008-10-29追記: 引用した部分は既に修正されています。 「疑似乱数化」ってなんでしょう……。「疑似乱数」は良く聞きますが、「疑似乱数化」は耳慣

    hiro_y
    hiro_y 2008/11/16
    「ワンタイムトークンを使うのであれば、それ自体はCSRFの対策になります。が、トークンが安全に作られていればハッシュ関数を使用する必要はありません。」
  • 困ったときの404 | 水無月ばけらのえび日記

    公開: 2008年11月14日17時55分頃 プログラマー系の新人にHTMLの基礎を学んでいただくべく社内講習をやりたいという話があり、そのための資料を作っていたのですが、あらためてRFC2616を見直していたら、404についてこんな記述を発見。 This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable. 以上、RFC2616 10.4.5 404 Not Found より

    hiro_y
    hiro_y 2008/11/14
    404のステータスコード、「アクセス拒否の理由を明かしたくないときは404を使うことができるのですね。」
  • IE7でコンテント・ネゴシエーションが残念なことになる件 | 水無月ばけらのえび日記

    Accept-Language によるコンテント・ネゴシエーションが IE7 でうまく動作しないらしいというお話があり、いろいろ調査。 問題を簡潔にまとめると、「IE7で複数の言語を設定している場合に、その設定の順位が無視されているように見える」という感じ。たとえば、コンテンツ側で日語と英語を用意しているとき、以下のような動作になります。 言語設定何も無し……英語コンテンツが返ってくる英語のみ設定……英語コンテンツが返ってくる日語のみ設定……日語コンテンツが返ってくる英語、日語の順で2言語を設定……英語コンテンツが返ってくる日語、英語の順で2言語を設定……英語コンテンツが返ってくる (順番が無視されている!)日語、英語の順で設定したら日語を返してほしいのに、何故か英語が返って来るという。 この原因は、「IEBlog : Accept-Language Header for I

    hiro_y
    hiro_y 2008/08/06
    「IE7で複数の言語を設定している場合に、その設定の順位が無視されているように見える」
  • ベリサインのセキュアドシールは役に立つのか | 水無月ばけらのえび日記

    セキュリティホールmemo (www.st.ryukoku.ac.jp)より、「Adobe Flash Player バージョン9.0.124.0導入環境においてベリサインセキュアドシール(Flash形式)の検証ページが表示出来ない事象について (www.verisign.co.jp)」。 Flash版のセキュアドシールが表示できないそうで。 ……しかしこれ、誰が困るのですかね。いつも思うのですが、そもそもこの「セキュアドシール」って何の意味があるのでしょうか。 ベリサインのサイトを見ると「毎日世界で約1.5億回表示」なんて書いてあるようです。シールを表示する際のログはきっちり記録されていて、それがベリサインのマーケティングに役立っているのでしょう。というわけでベリサイン側にはメリットがあるのでしょうが、これを貼る側にどういうメリットがあるのか分かりません。 ベリサインのサイトには以下のよ

    hiro_y
    hiro_y 2008/07/24
    このVeriSignのセキュアドシールは本物なのか? と考えてみること。
  • WASForum Conference 2008: 携帯電話向けWebのセキュリティ | 水無月ばけらのえび日記

    自転車GREEについて自転車はGIANTがオススメGREEは2006年11月に携帯にシフト、携帯からのアクセスがぐんぐん増加 携帯の諸々Referer来ないかもしれない。auとSoftbankはおおむね来る。来ないなら来ないで統一されていれば良いものを……Cookieは、au来ます、Softbankは来ないかも。 Referer漏洩問題についてそもそも他サイトにリンクしないこと。ドコモ公式では必須端末不具合によって、何故かメールから叩いたURLに前のサイトのRefererが出ることが……セッション格納情報でチェックする? UA……Referer漏洩時点でばれている。端末固有情報?SIDを変えまくるという対策だと、戻ると死んだりするユーザがGREEGREEのURLを貼ることは多い (URLにはセッション追跡情報がついている)。GREEではURLをパースしてがんばっている携帯ではHTML

    hiro_y
    hiro_y 2008/07/17
    ケータイwebのセキュリティ。
  • Firefox3のオレオレ警告 | 水無月ばけらのえび日記

    ……なんと「そのままアクセスする」とか「一時的に受け入れる」とかいう選択肢がありません。そのかわり「例外として扱うこともできます」という謎のリンクがあります。クリックすると、「例外を追加」というボタンが現れます。 「インターネット接続環境を完全には信頼できない場合や、これまでこのサーバではこの警告が表示されなかった場合は、このサイトを例外として追加しないでください。」という注意書きが。そして例外に追加しようとすると、だめ押しの一撃。 「物の銀行、ショップ、その他公共サイトがこの操作を求めることはありません。」太字で断言ですよ。これは気持ち良い! ここまでされると、物サイトをオレオレ証明書で運用するのもかなり抵抗が出てくるでしょう。 ※興味位で一時的にアクセスしてみたりするのがやりにくくなりますが……。まあ、一般の人はそんなことをする必要がありませんしね。 「Firefox3のオレオレ

    hiro_y
    hiro_y 2008/06/19
    Firefox3がドメインの違うSSL証明書に厳しい警告を出してくれる件。
  • 不正データによる終了時のステータスコードで悩む | 水無月ばけらのえび日記

    「なぜPHPアプリにセキュリティホールが多いのか?【スクリプトインジェクション対策07】予期しないエラーが発生した場合,プログラムの実行を停止する (gihyo.jp)」。 「プログラムの実行を停止」というのは表現がおかしいと思いますが、要は処理を続行せずにエラー終了すべきということですね。 しかしこういうときに悩むのが、「どういうステータスコードで応答したら良いのか」ということ。普通に考えると500系のレスポンスになると思うのですが、501 (Not Implemented) では変ですし、503 (Service Unavailable) だと一定期間後に復活しそうに見えますし、他に使えそうなコードはないし……。というわけで、まあ素直に500 (Internal Server Error) で良いかなぁ……と思うわけですが。 ところがついこの前、とある案件にて、セキュリティ屋さんから「

    hiro_y
    hiro_y 2008/04/18
    異常終了時のHTTPのステータスコードを何にするか。単純に500を返すと攻撃者に情報を与える可能性…か。
  • POST にすることは CSRF の対策と言えるのか | 水無月ばけらのえび日記

    「Webアプリケーションを作る前に知るべき10の脆弱性 (www.atmarkit.co.jp)」。いろいろ微妙な感じがするのですが、特に気になったのがこれ。 5.クロスサイトリクエストフォージェリ CSRF(Cross Site Request Forgery)は、来拒否すべき外部のWebページからのHTTPリクエストを受け付けてしまうというバグによって起こります。 (~中略~) ランダムなトークンをフォームやURLに埋め込んでその整合性を確認したり、重要なデータ更新を扱う際には再度認証を行ったり、GETは使用しないといった対策が有効です。 前からずっと思っているのですが、「GETは使用しない」「POSTのみ許可する」というのは CSRF の「対策」になるのでしょうか? CSRF の性質上、POST で攻撃できないという道理がありませんし、実際、私が届け出たものも、「ぼくはまちちゃん」

    hiro_y
    hiro_y 2007/06/21
    CSRF対策とリクエストメソッド。
  • 第8回WebSig会議 ディレクター・製作者が知っておくべきセキュリティ | 作者プロフィール

    2006年7月22日、第8回WebSig会議でお話しした「ディレクター・製作者が知っておくべきセキュリティ」に関するサポートページです。とりあえず資料がダウンロードできます。 資料ダウンロードプレゼンテーション資料の PDF 版がダウンロードできます。 bakera_WebSig247_08.pdf (PDFファイル 315KB) 無断での再配布はご遠慮ください。また、資料内に含まれる画面キャプチャは全て削除されていますので、一部不自然な空白があります。

    hiro_y
    hiro_y 2006/07/27
    (X)HTMLを理解していない→脆弱性に気づくことができない。
  • 情報処理試験でNUL文字攻撃の問題など | 水無月ばけらのえび日記

    更新: 2006年4月20日 スラッシュドットに「情報処理試験(2006年春)はどうでしたか (slashdot.jp)」というトピックができていますね。今回、「テクニカルエンジニア(情報セキュリティ)」という試験区分が新たに追加されたとのこと。 「情報処理技術者試験センター:問題冊子・配点割合・解答例 (www.jitec.jp)」として問題が公開されているので見てみましたが、ディレクトリトラバーサルやSQLインジェクションの攻撃手法を答えさせるものがあったりして、なかなか興味深いです。 個人的に印象深かったのは、拡張子指定を迂回する話ですね。Perl スクリプトで、外部から与えられた $fname という名前に対して '.cep' という文字列を連結してから open に渡しています。$fname は何もサニタイズされていませんが、プログラム内で '.cep' という固定の文字列が連結

    hiro_y
    hiro_y 2006/04/18
    NUL文字攻撃について。
  • CSRF | 鳩丸ぐろっさり (用語集)

    用語「CSRF」についてCSRF (しーえすあーるえふ)話題 : セキュリティ CSRF は Cross Site Request Forgeries の略です。"forgery" は偽造の意味で、サイトをまたがって捏造された攻撃リクエストを送信する、という程度の意味になります。 ※ちなみに、CSRF は「シーサーフ」と発音するのだという説もありますが、少なくとも日では「しーえすあーるえふ」と呼ぶ方が主流のようです。 たとえば、blog などは Web 上の管理画面で記事の削除ができるようになっています。削除を実行するには、削除を行うような HTTP のリクエストをサーバに送れば良いのですが、この画面は Cookie なり、Basic 認証なりでアクセス制御がされています。そのため、正規のユーザ以外が削除のリクエストを送っても何も起きません。ログイン済みの正規のユーザが「削除」のリクエス

    hiro_y
    hiro_y 2005/07/21
    リファラを確認するようにするか、ランダム値をリクエストパラメータに含ませるか。
  • 1