htmlspecialcharsに関する残念なお知らせ - 岩本隆史の日記帳（アーカイブ）
「htmlspecialcharsのパッチ私案」に書いた件、バグレポートを出してみましたが、「すでに同じバグレポートがあるだろ」という理由により、あえなく却下されました。 せめて先方が「同じ」とみなしているレポート番号ぐらいは示してほしくて、そのようにコメントしましたが、お相手のjaniという人は気難し屋のようで*1、教えてもらえる気がしません。 私なりに探した結果、下記のレポートがくさいように感じました。 PHP :: Bug #43896 :: htmlspecialchars() returns empty string on invalid unicode sequence 「不正なUTF-8シーケンスの場合に空文字列を返すのはおかしい」というレポートで、私のそれとは正反対どころか、Shift_JISにもEUC-JPにも触れられていない別個のものです。もちろん、私はレポート送信前に
セッションIDのみの認証はセキュリティレベルが低いのか - 岩本隆史の日記帳（アーカイブ）
はてなブックマークモバイル版の脆弱性 昨日、はてなブックマークモバイル版の脆弱性に関する報告が公開されました。 「はてなブックマーク モバイル版」の脆弱性を利用した不正アクセスに関するご報告 - はてなブックマーク日記 - 機能変更、お知らせなど キャッシュ機構の不備により、セッションID付きのURLを含むコンテンツページがキャッシュされてしまい、悪意のあるユーザが他人になりすます（セッションハイジャック）ことができたというものです。 セッションIDのみの認証なんてありえない？ 報告記事に対する下記のブックマークコメントを目にしたとき、私は違和感を覚えました。 セッションIDのみの認証なんてありえない。そもそもセッションIDは認証に使うべきではない。せめて各種完了処理のときくらいはUID(NULLGWDOCOMO)もしくはFOMAカードor端末の製造番号(icc〜、ser〜)を使って認証し
フォーム認証は本当に捨てられないのか - 岩本隆史の日記帳（アーカイブ）
フォーム認証とは 2008年も暮れようかという現在、Webアプリを作る際に「そうだBasic認証を使おう」と思う人はほとんどいないでしょう。ユーザIDとパスワードを入力するログインフォームを用意し、セッションIDをcookieに保存する方法を選ぶのが定石だと思います。ユーザIDとパスワードの代わりにOpenIDを受け入れる方法も考えられますが、セッションIDをcookieに保存するという意味では、先の例と違いはありません。この「セッションIDをcookieに保存する方法」のことを、以下「フォーム認証」と呼ぶことにします。 Basic認証が使われない理由 なぜフォーム認証が選ばれるのか。逆にいうならば、なぜBasic認証*1が選ばれないのか。産業技術総合研究所の情報セキュリティ研究センターでは、Basic認証が使われない理由を下記のようにまとめています。 ログアウト機能がないこと ログインせ
Pinto公開に向けて #8 ― OpenID対応中 - 岩本隆史の日記帳（アーカイブ）
眠いので、簡単に。「Pintoって何？」という方は前回の記事をご参照ください。 Rack::Auth::OpenIDは現状使えない OpenID対応するにあたり、Rack::Auth::OpenIDを使ってみようと思ったわけですが、現状では使えないことが分かりました。ruby-openidのバージョン2に対応していないからです。結局、ruby-openidを直接使うことにしました。 Rack::Auth::OpenIDがruby-openid 2にいつか対応したとしても、使うかどうか微妙な感じです。Rackのプラグインは、どれも融通がきかない印象があります。Rack::Session::Cookieもそうですね。 ruby-openidを使えば、リプライ攻撃への対応を考えなくてよい 「id:ZIGOROuさんの資料が勉強になった」という記事で心配していた件ですが、ruby-openidがよ
id:ZIGOROuさんの資料が勉強になった - 岩本隆史の日記帳（アーカイブ）
プロバイダ（OPでもRPでも）やるなら必読といえるのではないでしょうか。 WASForum Conference 2008 での OpenID のセキュリティについてのスライドを公開します - Yet Another Hackadelic 個人的にありがたかったのが、「RPは OP Endpoint URL と openid.response_nonce」をペアで覚えておけ」という部分（41〜42ページ）。OPからの認証成功コールバック時に、過去に使われたペアだったらリプレイ攻撃とみなす、ということですね。 RDBMSで管理するとすれば、OP Endpoint URL を繰り返すのは冗長なので、下記のように正規化する感じかな。 op_end_point テーブル op_end_point_id op_end_point_url 1 https://open.login.yahooapis.
WebアプリとWebサービスは違うことにようやく気づいた - 岩本隆史の日記帳（アーカイブ）
『RESTful Webサービス』の第3回読書会に参加するため、6〜8章を読み返しています。構想中のWebアプリの認証周りについて考えていたところで、読むのにちょうど良いタイミングでした。 まだ全部を読みきってはいませんが、「6.1.1 ユーザーアカウントはなぜリソースなのか」に「Webアプリケーションの設計は一般的なテーマであり、本書のテーマではない」とあるのを読み、衝撃を受けました。そうか！ これはWebサービスのアーキテクチャを提案する本だったんだ！ ここしばらく私が悩んでいたのは、Webサービス向けに提案されているアーキテクチャ（ROA）をそのままWebアプリに適用しようとしていたせいだったんだと、ようやく気づいたわけです。 おかげで、WebアプリとWebサービスを分けて考えることができるようになり、下記の方針に至りました。 WebアプリもできるだけROAベースにする。どうしようも
個人的なホワイトリスト案 - 岩本隆史の日記帳（アーカイブ）
現在構想中のWebアプリでは、リソースの表現を英語と日本語から選べるようにしようと考えています。日本語圏以外の方にも使っていただきたいので。 いわゆるソーシャルなWebアプリなので、ユーザ登録も必要になります。が、ユーザ視点に立つと、個人が運営するWebアプリにユーザ登録するのは少し抵抗があります。「どこぞの馬の骨に俺様の認証情報あずけて大丈夫なんけ？」ということです。開発者視点でも、ユーザ管理であまり悩みたくない（「パスワードリマインダ必要だなあ」とか「だったらメールアドレスも預からなきゃなあ」とか）。 そこでOpenIDですよ。ユーザ登録時には、まずOpenIDで認証してもらい、コールバック画面で好みのアカウント名を入力させ、Claimed Identifierと紐づけるのが良いかなと思っています（Fastladder方式）。 RPとなる場合、すべてのOPを信頼するのかというレピュテー
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
