バグハンター一問一答！ひとはいかにしてバグハンターになるのか？
―バグハンターってなんですか？ ソフトウェアの欠陥(脆弱性)を見つけることに楽しみや自己実現を見いだす人のことです。ただ近年は、そうした活動に対して報奨金を与える会社が増えています。 ―ハッカーとは違うのでしょうか？ 同じだと思います。ハッカーと呼ばれる人はたくさんいますが、そのうちの、脆弱性を見つけることに長けた人たちのことをいいます。 ―バグハンターは、匿名ですか？実名ですか？ 大半は実名ですが、恥ずかしがり屋もいます。 ―バグハンターが通報してから、脆弱性が修正されるまでのプロセスを簡単に教えてください。 一般に、通知を受けたソフトウェア会社は、その脆弱性をまず確認して、間違いなくそれが脆弱性であるとバグハンターに伝えます。そして、修正のおよその目安をバグハンターに示しながら、修正作業を行うのが一般的です。 ソフトウェア会社側で修正作業が終わり、修正プログラムが公開されると、バグハン
「HACKING: 美しき策謀 第2版」で脱・初心者エンジニア - As a Futurist...
今年もあまり本を読めていないのですが、かなり評価の高い本を数冊読んでいます。その中でもピカイチにオススメしたいのが表題の本です。最近第 2 版が出たようです。って、実はまだ読んでる途中なんですけどね。。。 「教科書」として素晴らしい出来 この本の何よりもすごいと思った点は、頭から読んでいってすんなり全てが飲み込める点です。ここまで頭に吸い込まれる本は久々に読んだ気がします。普通技術書だと、サンプルコードがあって、実際に実行してみてねーこんな感じになるから、って書いてあるんですが、自分で実際に実行してみないとイマイチピンと来ないことがあります(サンプル動かなかったりとかもある)。そういう本は、通勤時間とかにちょこちょこ読むにはちょっとしんどいです。 HACKING がすごいのは、第 2 章のアセンブリやヒープ・スタックの解説、さらに第 3 章のバッファオーバーフロー等の脆弱性を突くといった部
CSRF対策のトークンをワンタイムにしたら意図に反して脆弱になった実装例
補足 この記事は旧徳丸浩の日記からの転載です（元URL、アーカイブ、はてなブックマーク1、はてなブックマーク2）。 備忘のため転載いたしますが、この記事は2011年1月27日に公開されたもので、当時の徳丸の考えを示すものを、基本的に内容を変更せずにそのまま転載するものです。 補足終わり 橋口誠さんから今話題の書籍パーフェクトPHP (PERFECT SERIES 3)を献本いただきました。ありがとうございます。このエントリでは同書のCSRF対策の問題点について報告したいと思います*1。 本書では、CSRFの対策について以下のように説明されています（同書P338）。 CSRFへの対応方法は、「ワンタイムトークンによるチェックを用いる」「投稿・編集・削除などの操作の際にはパスワード認証をさせる」などがあります。一番確実な方法は両者を併用することですが、ユーザ利便性などの理由から簡略化する場合で
パーフェクトPHPのサンプルコードに脆弱性がありました - gusagiの日記
徳丸浩さんのブログで脆弱性のご指摘を頂いていることに遅まきながら気付きました。 徳丸さん、ありがとうございます。 詳細は徳丸さんのブログをご覧頂いた方が良いかと思いますが、指摘頂いた脆弱性は大きく、 (1) 「種」となる$seedとマイクロ秒のみでトークンを生成しているため、マイクロ秒をずらしつつ辞書攻撃を行うことで$seedの推測が可能である (2) そもそも、$seedについての言及がないためコピペされる可能性がある (3) 今回の場合、時刻を元にワンタイムトークンを生成しているため、トークン生成日時を攻撃者が制御しやすくなり、辞書攻撃を容易にしている の3つとなります。 (2)については、徳丸さんがブログ内で あるいは、$seedの値が'secret'となっているわけだから、明記はされていないが暗黙の了解として$seedは本番環境では変更して使うのだという意図かもしれません。 と書か
「体系的に学ぶ 安全なWebアプリケーションの作り方」3月1日発売です - ockeghem's blog
去年の5月末に「本を書く」という宣言をしてから8ヶ月以上掛かってしまいましたが、ようやく体系的に学ぶ 安全なWebアプリケーションの作り方が脱稿し、3月1日に発売される運びとなりました。 現時点で一番詳しい本の目次は、出版元のオフィシャルページにありますが、このブログでもおいおい詳しい内容を紹介したいと思います。また別途サポートページを立ち上げる予定です。 本書の目次は以下の通りです。 1章 Webアプリケーションの脆弱性とは 2章 実習環境のセットアップ 3章 Webセキュリティの基礎 〜HTTP、セッション管理、同一生成元ポリシー 4章 Webアプリケーションの機能別に見るセキュリティバグ 5章 代表的なセキュリティ機能 6章 文字コードとセキュリティ 7章 携帯電話向けWebアプリケーションの脆弱性対策 8章 Webサイトの安全性を高めるために 9章 安全なWebアプリケーションのた
きまぐれ日記: sudo のGUIダイアログはセキュリティ的に大丈夫なのか?
UbuntuやMac OSXを使っていると、権限の高いオペレーションを実行しようとしたときに、ユーザのパスワードを要求するダイアログが起動します。毎回ハイハイと思いつつ入力しているのですが、ふと考えるとこのセキュリティモデルというかユーザビリティー的に大丈夫なのかどうかと思うようになりました。 例えば、インストーラーでダミーのパスワードダイアログを表示させればマルウェア作者はユーザのパスワードを取り放題だし、OSのファイル保存ダイアログをクラックして、適当なファイル保存のタイミングで同ダイアログを出せば、無知なユーザはホイホイパスワードを入力してしまうのではないでしょうか。Webサイトのフィッシングと全く同じ話です。 このダイアログはそもそも CUIプログラム sudo のラッパーにすぎません。しかし、話はそんなに単純ではありません。CUIの場合は、ほとんどの操作が「能動的」なために、su
「PHP×携帯サイト デベロッパーズバイブル」@水無月ばけらのえび日記
うわさの「PHP×携帯サイト デベロッパーズバイブル (www.amazon.co.jp)」を軽く見ましたが……「ゆるいなぁ」、というのがひとまずの感想。 メモ的なコメントを順不同でだらだら列挙しておきます。 最初の1行掲示板のサンプルがいきなり脆弱。「完成版」になっても脆弱。「auではテキスト入力欄で改行が入力できる」という発想の仕方がどうも……。auに限らず、テキスト入力欄に限らず、改行が入力されることは常にあり得ると考えたほうが良いと思うわけで。Cache-ControlをHTTP応答ヘッダではなくmeta要素で指定。20世紀のフリーCGIみたい?Content-TypeをHTTP応答ヘッダとmeta要素の両方で指定する必要があるように読めますが、metaは不要なはず。しかも、何故かmetaにだけcharsetがついており、肝心な方についていないので、これをそのまま実装するとはせがわ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Amazon.co.jp: リストマニア