bcryptの72文字制限をSHA-512ハッシュで回避する方式の注意点
宅ふぁいる便から平文パスワードが漏洩した件を受けて、あらためてパスワードの安全な保存方法が関心を集めています。現在のパスワード保存のベストプラクティスは、パスワード保存に特化したハッシュ関数（ソルトやストレッチングも用いる）であるbcryptやArgon2などを用いることです。PHPの場合は、PHP5.5以降で使用できるpassword_hash関数が非常に便利ですし、他の言語やアプリケーションフレームワークでも、それぞれ用意されているパスワード保護の機能を使うことはパスワード保護の第一選択肢となります。 なかでもbcryptは、PHPのpassword_hash関数のデフォルトアルゴリズムである他、他の言語でも安全なハッシュ保存機能として広く利用されていますが、パスワードが最大72文字で切り詰められるという実装上の特性があり、その点が気になる人もいるようです（この制限はDoS脆弱性回避が
正規表現によるバリデーションでは ^ と $ ではなく \A と \z を使おう
正規表現によるバリデーション等で、完全一致を示す目的で ^ と $ を用いる方法が一般的ですが、正しくは \A と \z を用いる必要があります。Rubyの場合 ^ と $ を使って完全一致のバリデーションを行うと脆弱性が入りやすいワナとなります。PerlやPHPの場合は、Ruby程ではありませんが不具合が生じるので \A と \z を使うようにしましょう。 はじめに 大垣さんのブログエントリ「PHPer向け、Ruby/Railsの落とし穴」には、Rubyの落とし穴として、完全一致検索の指定として、正規表現の ^ と $ を指定する例が、Ruby on Rails Security Guideからの引用として紹介されています。以下の正規表現は、XSS対策として、httpスキームあるいはhttpsスキームのURLのみを許可する正規表現のつもりです。 /^https?:\/\/[^\n]+$/
ロリポップのサイト改ざん事件に学ぶシンボリックリンク攻撃の脅威と対策
既に報道されているように、ロリポップ！レンタルサーバーに対する改ざん攻撃により、被害を受けたユーザー数は8428件にのぼるということです。ここまで影響が大きくなった原因は、報道によると、(1)「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされた、(2)パーミッション設定の不備を悪用されて被害が拡大した、ということのようです。 29日夜の時点では、攻撃者の改ざん手法について「WordPressのプラグインやテーマの脆弱性を利用」し、不正なファイルがアップロードされて「wp-config.phpの」の設定情報が抜き出されたと説明していたが、30日午後7時過ぎの説明で、この脆弱性が侵入経路となって同社のパーミッション設定の不備を悪用されたことが原因だったことを明らかにした。 「ロリポップ」のWordPressサイト改ざん被害、原因はパーミッション設定不備
PHPのdisplay_errorsが有効だとカジュアルにXSS脆弱性が入り込む
先に、「CVE-2008-5814を巡る冒険」にて、CVE-2008-5814脆弱性があるとdisplay_errorsがOnの環境下でXSS脆弱性となる場合があることを説明しました。しかし、display_errorsがOnの環境下ではCVE-2008-5814脆弱性がなくても、XSS脆弱性となる場合がしばしばあります。 これは、display_errorsによるエラーメッセージ表示がHTMLエスケープされていないことが原因です。簡単なサンプルを以下に示します。 <?php ini_set('display_errors', 1); // display_errorsを有効にする $a = array(); // 配列の生成 $index = $_GET['x']; // 配列のインデックスを得る $b = $a[$index]; // 配列の要素にアクセス このスクリプトに、x=<sc
COOKPADの「伏せ字にせず入力」ボタンは素晴らしい
@tokuhiromから教えてもらったのですが、COOKPADのスマートフォン向けWebサイトのログインページには、パスワードを「伏せ字にせず入力」するボタンがついているのですね。 さっそく見てみましょう。まずはログイン画面です。パスワード欄の下側に、「伏せ字にせず入力」ボタンが見えます。 「元に戻す」ボタンを押すと、伏せ字に戻ります。 僕はこれを知って興奮しました。なぜなら、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方」には以下のように書いたからです（P337～P338）。 パスワード入力欄のマスク表示は、現在の常識的なガイドラインですが、実は筆者自身は疑問を持っています。パスワード入力欄をマスク表示にすると、記号や大文字・小文字交じりの安全なパスワードを入力しにくくなるので、利用者は簡単な（危険な）パスワードを好むようになり、かえって安全性を阻害するリスクの方が大きいのでは
Cookieによるhashdos攻撃と対策
このエントリでは、Cookieを用いたhashdos攻撃の可能性について検討し、実証結果と対策について報告します。 はじめに既に当ブログで報告の通り、hashdosと呼ばれる攻撃手法が公表されています。HTTPリクエストのパラメータ名に対するハッシュ値を故意に同一にした(衝突させた)ものを多数（数万程度）送信することにより、Webサーバーを数分程度過負荷にできるというDoS攻撃手法です。 先の記事でも説明しているようにPOSTパラメータ(HTTPリクエストボディ)に多数のパラメータを仕込む攻撃が典型的ですが、POSTパラメータ以外のパラメータを用いた攻撃についても検討しておかないと、防御漏れの可能性が生じます。 そこで、POSTパラメータ以外を用いた攻撃方法について検討します。 POST以外に多数のパラメータを仕込めるかPOST以外に多数のパラメータを仕込む場所があるでしょうか。候補となる
属性型JPドメインと地域型JPドメインに対するCookie Monster Bug調査
※凡例 地域型JPドメインの第2レベルとは、tokyo.jpなど第2レベルのドメイン名でCookieが発行できるもの 地域型JPドメインの第3レベルとは、chiyoda.tokyo.jpなど第3レベルのドメイン名でCookieが発行できるもの 背景が赤のセルは現バージョンでバグのあるもの。無色は旧バージョンの参考情報 携帯電話に関しては機種毎に仕様が異なる可能性が高く、全機種について調査したわけではないので、上記はあくまで抜き取りでの結果であることに注意されたし ※確認機種、バージョン等 iモード:P-07A(iモードブラウザ2.0)で確認 EZweb:W52T、biblioで確認（結果は同じ）。詳細は後述 Softbank(1): 821N, 932SHで確認。これらは非公式JavaScript対応機 Softbank(2): 944SH(公式JavaScript対応機)で確認 Andr
都道府県型JPドメインがCookieに及ぼす影響の調査
JPRSからのプレスリリース『JPRSが、地域に根ざした新たなドメイン名空間「都道府県型JPドメイン名」の新設を決定』や報道などで「都道府県型JPドメイン」というものが新設されることを知りました。 都道府県型JPドメインとは、現在活発に使われていない地域型ドメインを活性化する目的で、地域型ドメインの制約（ドメイン名が長い、一人・一団体あたり1つまで）を簡略化しようというもののようです。 しかし、現在の地域型ドメインは、ブラウザにとって処理がややこしいもので、IEなどは昔からまともに対応していません。このため、Cookie Monster Bugという脆弱性になっているという経緯があります。このルールをさらに複雑にすることになるということから、ブラウザセキュリティに関心の高い人たちが騒ぎ始めています。 そこで、高木浩光氏の日記「JPRSに対する都道府県型JPドメイン名新設に係る公開質問」の以
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
