もふったーのコンシューマシークレット問題について、鍵はプログラム中に安全に埋め込めるはず。だが… - kazuhoのメモ置き場
超軽量Twitterクライアント「もふったー」コンシューマシークレットキー難読化最後の挑戦 - GIGAZINE もふったーコンシューマシークレットキー難読化最後の挑戦 ・ω・ - Windows 2000 Blog あたりの話について。記憶に頼って書いてるので間違ってたらごめんなさい。 問：鍵を隠すことができるか 答：以下の理由から可能なはず。 HMACのキーは前置型でハッシュ関数のブロックサイズ SHA-1*1はMerkle-Damgaard法で構築される ブロックをまたぐ際のステート値はファイナライズ処理を除けば最終的なハッシュ値と同じ 以上より、鍵のハッシュを演算後の内部ステートをもつ、鍵ごとに特化したHMAC関数（正確に言うと、鍵ごとに特化したハッシュ値同様の安全性をもつ（つまり鍵を回復することのできないステート値）を生成し、鍵のかわりに、そのステート値を埋め込んだ専用HMAC関
なぜPHPでrequire("http://...")したらセキュリティホールなのに、Goならいいのか - kazuhoのメモ置き場
go言語なんか import "http://github.com/mattn/xxx " だったりする。rubyもそういうの面白いかもしれない。require "http://github.com/mattn/xxx "みたいな。 mattn on Twitter: "go言語なんか import "http://t.co/9qiwho7OMZ" だったりする。rubyもそういうの面白いかもしれない。require "http://t.co/9qiwho7OMZ"みたいな。" @mattn_jp それコンパイル型言語なら許されるけどスクリプト型だとセキュリティホールとされるものでは？ (e.g. PHP) Kazuho Oku on Twitter: "@mattn_jp それコンパイル型言語なら許されるけどスクリプト型だとセキュリティホールとされるものでは？ (e.g. PHP)" と
TwitterやFacebookのURLには、なぜ#!が含まれるのか (SEOとAjaxのおいしい関係) - kazuhoのメモ置き場
Ajaxを使うためにはページ内リンク (hash fragment=URLの#以降) を使うのが一般的*1 hash fragmentはサーバに送信されないから、JavaScript非対応のブラウザだと動作しない 特にサーチエンジンのクローラ等で問題になる*2 そこで Google は、#! が含まれる URL を hash を含まないものに読み替える仕組みを提唱している。例えば「www.example.com/ajax.html#!key=value」のサーチエンジン用URLは「www.example.com/ajax.html?_escaped_fragment_=key=value」になる。 TwitterやFacebookはこの仕様に従うことで、Ajax な UI と SEO を同時に実現している、というわけ。ということを調べたなう。 参照: Getting Started |
Ptrace と TOCTOU 攻撃 - kazuhoのメモ置き場
帰国して、ようやく 404 Blog Not Found:perl - Shibuya.pm #11:The Catcher in the INT 80h が読めるようになった id:kazuhooku です。弾さんのスライドは、FreeBSD 特有の事情と、その問題をカバーしようとするための努力について解説していて、とてもおもしろく読ませていただきました。が、一点、気になったのが TOCTOU (Time-Of-Use Time-Of-Attack) 攻撃への対策についてです。TOCTOU 攻撃とは何か、端的に言うと、 You can't stop the invocation but you can still poke the argument on the stack. Shibuya.pm #11:The Catcher in the INT 80h とのことですが、同様のことを
今回の shibuya.pm で一番困ったこと - kazuhoのメモ置き場
M○SQL Conference & Expo 参加中のため、アメリカから shibuya.pm 関連のブログエントリを読んでいるわけですが。一番困るのは発表者の皆さんが shellcode (あるいはそれっぽいもの) をブログに貼りまくってること。 ホテルのインターネット回線 (LODGENET) に接続されている IDS が、どうも HTTP 上を流れる shellcode を監視しているらしく、x86 バイナリ*1が流れた瞬間に、 「攻撃を検知しました。10分間回線を切断します」 って表示がでて、インターネットにつながらなくなる。これじゃ仕事になんないよー >< LODGENET-- ということで、回線断中の怒りにまかせてブログ更新。IDS 開発者の意図はわかるんだけど、いったいどこの製品なんだろ。 ちなみに MyS○L が伏せ字なのは、このどうでもいいエントリが http://jp
SSD とストレージの将来 - kazuhoのメモ置き場
SQL に痛痒感を感じる日々を過ごしている身としては、RDBMS がレガシーだというのは、まったく同感ですが。 SSDを前提にしたプログラムモデルになれば、そもそもシーク時間と戦うこともなく、ストレージを意識せずにプログラムが組めます。そうなったとき、アプリケーションのデータを永続化するためにRDBMSをわざわざ使うことはないでしょう。 2008-12-12 そんなことないと思います。理由は以下の２点。 フラッシュの書き換えブロックサイズは数キロバイト以上 トランザクションは意識して実装せざるを得ない フラッシュメモリはランダムリードできますが、DRAM のようにランダムライトできるわけではありません。書き込みが非常に遅いのに加えて書き換え回数の制限もあるので、メインメモリと同様のプログラム手法を使うのは難しいと思います。 次にトランザクションについてですが、組み込み型データベースとして
ZERO WIDTH SPACE を使って Unicode ステガノグラフィ - kazuhoのメモ置き場
inspired by Yappo id:TKSK かっこいい 上のテキスト、一見 id:TKSK を褒めているいるようですが、実は別の人をほめています。下線のリンクが無いでしょ？ ちなみに、以下の perl スクリプトを通すと、誰をほめているのかわかります。 perl -Mutf8 -MEncode -we 'undef $/; $s = decode_utf8(<STDIN>); $s =~ s!([\x{200b}|\x{feff}]+)!pack("B*", join("", map { $_ eq "\x{200b}" ? 0 : 1 } split("", $1)))!eg; print encode_utf8($s)'この隠しデータを作るには、以下のようにします。 echo "you can see here (
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
