はてなブックマークからDeliciousに移動します - 岩本隆史の日記帳（アーカイブ）
ブックマークを http://b.hatena.ne.jp/IwamotoTakashi/ から http://www.delicious.com/iwamot に移動します。もちろん今般のトラッキング問題が大きなきっかけではありますが、それより前に「新ユーザーページの使いづらさ問題」という小さなきっかけもありました。自分のブックマークでなく「マイホットエントリー」をデフォルトにするセンスが僕には合いません。 優秀なエンジニアの退職はやまず、はてなアイデアは放置されっぱなし。今回のような大きな問題が起きても、社長が外遊中のためか対応が遅い。はてなには上場より先にやるべきことがあるのではないかと苦言を呈したくもなります。 ブックマークだけでなく日記も、そのうち別のサービスに移動しようと考えています。
htmlspecialcharsに関する素敵なお知らせ - 岩本隆史の日記帳（アーカイブ）
外出のため確認が遅くなってしまったのですが、「htmlspecialcharsに関する残念なお知らせ」という記事で触れたバグレポートが、reopenされ、fixされました。 「改善される見込みは薄い」という私の予測は外れたわけで、申し訳ないと思うと同時に、htmlspecialcharsの挙動が改善され、嬉しく思っています。ご尽力いただいた皆様、ありがとうございました。 PHPのバグレポートを初めて書く方へ PHPのバグレポートには、再現コードや期待される結果、実際の結果を書く欄があります。私のレポートでも埋めました。 PHPのコミッタはそれらを読み、バグだと思えばコードを修正するでしょう。また、仕様だと思えば却下するでしょう。私のレポートでいえば、janiさんは仕様と判断され、moriyoshiさんはバグと判断されたわけです。「それでいいのか」という気もしますが、そうなのだから仕方がない
htmlspecialcharsに関する残念なお知らせ - 岩本隆史の日記帳（アーカイブ）
「htmlspecialcharsのパッチ私案」に書いた件、バグレポートを出してみましたが、「すでに同じバグレポートがあるだろ」という理由により、あえなく却下されました。 せめて先方が「同じ」とみなしているレポート番号ぐらいは示してほしくて、そのようにコメントしましたが、お相手のjaniという人は気難し屋のようで*1、教えてもらえる気がしません。 私なりに探した結果、下記のレポートがくさいように感じました。 PHP :: Bug #43896 :: htmlspecialchars() returns empty string on invalid unicode sequence 「不正なUTF-8シーケンスの場合に空文字列を返すのはおかしい」というレポートで、私のそれとは正反対どころか、Shift_JISにもEUC-JPにも触れられていない別個のものです。もちろん、私はレポート送信前に
htmlspecialcharsのパッチ私案 - 岩本隆史の日記帳（アーカイブ）
PHPのhtmlspecialchars関数について、文字エンコーディングの妥当性チェックが不充分であること、また場合によってはXSS攻撃が可能になることが、下記ふたつの記事で指摘されています。 htmlspecialcharsは不正な文字エンコーディングをどこまでチェックするか | 徳丸浩の日記 Shift_JIS では、htmlspecialchars() を使用しても XSS が可能な場合がある - t_komuraの日記 徳丸さんの記事では、仕様変更も提案されています。 冗長なUTF-8は不正なエンコーディングとして扱う（出力を空にする） Shift_JIS、EUC-JPの2バイト目が不正な場合も、エラーとして出力を空にする htmlspecialcharsは不正な文字エンコーディングをどこまでチェックするか | 徳丸浩の日記 さらに、id:t_komuraさんの記事をうければ：
セッションIDのみの認証はセキュリティレベルが低いのか - 岩本隆史の日記帳（アーカイブ）
はてなブックマークモバイル版の脆弱性 昨日、はてなブックマークモバイル版の脆弱性に関する報告が公開されました。 「はてなブックマーク モバイル版」の脆弱性を利用した不正アクセスに関するご報告 - はてなブックマーク日記 - 機能変更、お知らせなど キャッシュ機構の不備により、セッションID付きのURLを含むコンテンツページがキャッシュされてしまい、悪意のあるユーザが他人になりすます（セッションハイジャック）ことができたというものです。 セッションIDのみの認証なんてありえない？ 報告記事に対する下記のブックマークコメントを目にしたとき、私は違和感を覚えました。 セッションIDのみの認証なんてありえない。そもそもセッションIDは認証に使うべきではない。せめて各種完了処理のときくらいはUID(NULLGWDOCOMO)もしくはFOMAカードor端末の製造番号(icc〜、ser〜)を使って認証し
Rails 2系のXSS脆弱性がRuby 1.9では影響なしとされる理由 - 岩本隆史の日記帳（アーカイブ）
Rails 2系のXSS脆弱性を修正するパッチが先日公開されました。 4日(米国時間)、Ruby on Railsの2系すべてのバージョンにXSSの脆弱性があることがRiding Rails: XSS Vulnerability in Ruby on Railsにおいて発表された。特定のUnicode文字列を使ってチェックをくぐり抜け、任意のHTMLを送り込まれる危険性がある。なおRuby 1.9系で動作しているアプリケーションはこの影響を受けない。 http://journal.mycom.co.jp/news/2009/09/07/048/index.html この件に関して、大垣さんは次のように説明しています。 RoRの脆弱性に関連してRuby1.9では安全、と解説されていますが、それはRuby1.9は不正な文字エンコーディングを受け付けないからです。 何故かあたり前にならない文字エ
不正な文字列をどこでチェックすべきか - 岩本隆史の日記帳（アーカイブ）
大垣さんの書かれた： 不正な文字エンコーディングを利用した攻撃は、文字エンコーディングを厳格に取り扱い、文字エンコーディングをバリデーションすれば無くなります。これを怠ると、システムのどこで問題が発生するか予想できなくなります。つまり、いい加減に文字エンコーディングを取り扱うと安全なシステムは作れないのです。 何故かあたり前にならない文字エンコーディングバリデーション – yohgaki's blog という警告には同意なのですが、対策の一番手に「全ての入力文字列の文字エンコーディングをバリデーションする」が挙げられているのに違和感を覚えます。入力時のバリデーションは、あくまで保険的な対策でしかないのではないでしょうか。 この文脈において、XSSが起きるのは、不正なバイト列や冗長なUTF-8表現がHTML中に出力されるためでしょう。そうならば、不正な文字列がHTMLに出力されそうになった段
POSTリクエストをリダイレクトしたい状況とその対応 - 岩本隆史の日記帳（アーカイブ）
Webアプリケーションを作成する際には，POSTのリクエストをリダイレクトして，そのまま別のURLにPOSTさせるということはできないと思っておいたほうが良さそうですね． POSTリクエストをリダイレクトするとGETされる？POSTされる? - はこべにっき ♨ HTTP/1.1のRFC上は「できる」はずなのに、非準拠UAのせいで「できない」という話ですね。同意です。 私は現在、Webアプリケーションフレームワークの設計に関心があります。その辺にかかわる話なので、POSTリクエストをリダイレクトしたい状況にはどのようなものがあるか、また、それが「できない」場合どうしたらよいか考えてみます。 POSTリクエストをリダイレクトしたい状況 リダイレクトしたい状況は、以下の2つだけではないでしょうか。 1. POSTリクエストの処理後、別のリソースを見せたい たとえばブックマーク登録処理後に、登録
非同期処理メインのWebアプリについて考えた - 岩本隆史の日記帳（アーカイブ）
先日「非同期にしたいけれど」という記事を書いてからずっと、非同期処理メインのWebアプリについて考えています。実装したわけではないため、まだ机上の空論にすぎませんが、方向性が見えてきたので備忘録として残しておきます。 前提条件 Create/Update/Deleteのリクエストは非同期で処理する（参照：Life is beautiful: マルチスレッド・プログラミングの落とし穴、その２） ユーザ登録処理を例に考える 現在、Pintoというソーシャルブックマークを作っているので、そのユーザ登録処理を例として考えます。 1. ユーザ登録画面リソースを取得 GET /create_user_form HTTP/1.1 Host: ja.pinto.jp 2. ユーザ登録ジョブリソースを作成 POST /create_user_jobs HTTP/1.1 Host: ja.pinto.jp u
第02回まっちゃ４４５勉強会に参加した - 岩本隆史の日記帳（アーカイブ）
第02回まっちゃ４４５勉強会 竹迫さん（id:TAKESAKO）によるmod_wafful話が聞けそうだ、ということで参加表明した勉強会。表明後、徳丸さん（id:ockeghem）・大垣さん・園田さん（id:sonodam）が登壇されることが決まり、願ってもない流れに。 勉強会開始直後は、知らない方（あるいは私が一方的に知っている方）ばかり60名の中、正直アウェー感を感じずにはいられなかったのですが、最終的には満足感・充実感でいっぱいになりました。スタッフの皆様、講師の皆様、参加者の皆様、本当にありがとうございます。 勉強会は4部構成でした。1部は自己紹介タイム、2部以降が本編です。 WAF入門 〜原理、効果、限界〜（徳丸さん） WAF（Webアプリケーションファイヤーウォール）について何も知らない状態で参加した私にはありがたいご講演でした。実際にWAFが動いている環境でのデモも分かりやす
ブルートフォースアタックがひどいのでDenyHostsを入れた - 岩本隆史の日記帳（アーカイブ）
リリースチェッカーを動かしているFreeBSDサーバに対し、ここ数日ブルートフォースアタックが行われていました。どげんかせんといかんので、DenyHostsというツールを入れて様子を見ています。とりあえず作業メモを残しておきます。 なお、作業にあたっては下記のリソースが参考になりました。ありがたいねー。 http://ibio.jp/index.php?DenyHosts http://blog.harmonicom.jp/archives/6 ports からインストール # cd /usr/ports # portinstall security/denyhosts /etc/rc.conf の編集 インストールすると To run denyhosts from startup, add denyhosts_enable="YES" in your /etc/rc.conf.とか Wa
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
