はてなブックマークボタンがマイクロアド社の新ガイドラインに従ったらこうなる - ockeghem's blog
すでにこちらでご案内の通り、私のブログ（徳丸浩の日記およびEGセキュアソリューションズオフィシャルブログ）に貼っていた「はてなブックマークボタン」により、読者の皆様の閲覧行動がマイクロアド社によりトラッキングされておりました。読者の皆様に断りなく不快な結果を強いていたことに対してお詫び申し上げます。既に当該ボタンは撤去しております。 その後、株式会社はてな社長の近藤淳也氏およびはてなの日記にて行動情報の提供をやめる旨のアナウンスが一昨日ありました（こことここ）。さらに、マイクロアド社からは、昨日以下のアナウンスがありました。 今後マイクロアドでは、ブログパーツや外部ボタン等、マイクロアドと直接提携関係にあるパートナー以外の第三者にあたる媒体・配信面に付与される可能性のあるものについて、それらの表示領域にマイクロアドからの行動履歴情報の蓄積を無効化するオプトアウトページへの導線設置を義務化い
書籍「Android Security」の暗号鍵生成方法には課題がある - ockeghem's blog
書籍「Android Security 安全なアプリケーションを作成するために」は既に各方面で絶賛されているように、Androidアプリケーションの開発者には必携の書籍だと思いますが、新しい分野だけに、首をひねらざるを得ない箇所もありました。このエントリでは、同書第10章「暗号化手法」から共通鍵の生成方法について議論します。 はじめに 書籍「Android Security」（業界では「タオ本」と呼ばれているので、以下タオ本と記述）の10章では、端末内のファイルを暗号化して保存する手法について説明されています。その際に問題となるのが、鍵の生成と保管の方法です。スマートフォン端末、とくにAndroid端末は、アプリケーションのリバースエンジニアリングとルート化の可能性は常にあるため、あらゆる場合にも破られない暗号化というものはありません。このため、守るべき情報資産と、想定する脅威（言い換え
大垣本を読んで「バリデーションはセキュリティ対策」について検討した - ockeghem(徳丸浩)の日記
このエントリでは、セキュリティの観点から、バリデーション実装について検討します。大垣さんの本を読んで「大垣流バリデーション」について勉強した結果を報告します。 はじめに 大垣さんの記事「入力バリデーションはセキュリティ対策」では、「入力バリデーションはセキュリティ対策である」が力説されています。この記事はおそらくid:ajiyoshiさんのブログ記事「妥当性とは仕様の所作 - SQLインジェクション対策とバリデーション」を受けてのことだと思います。id:ajiyoshiさんのエントリでは、「妥当性検証は仕様の問題であってセキュリティ対策ではありません」と明言されています。私はid:ajiyoshiさんに近い考えを持っていますので、大垣さんの主張について、私なりに考えてみました。 記事を書くにあたり、徳丸の立場を明確にしておきたいと思います。 バリデーションの基準は仕様の問題 バリデーション
徳丸本をブロガーに差し上げちゃうキャンペーンのお知らせ - ockeghem's blog
「徳丸本」こと「体系的に学ぶ 安全なWebアプリケーションの作り方」は、このたび増刷（第5刷）が決定いたしました。皆様のご愛読に深く感謝申し上げます。増刷を記念して、徳丸本を買いたくてもまだ買えていなかった方々に、徳丸本を進呈するキャンペーンを企画いたしました。 私の手元に徳丸本第3刷の在庫が数冊あります。元々献本用や（HASHコンサルティングの）営業活動の贈呈用として購入していたものですが、思ったほど「差し上げる」機会がなくて、死蔵されているような格好でした（この在庫とは別に増刷ごとに何冊かずつ送付いただいているため）。そんなタイミングで第5刷が出ることになったので、これはいかん、在庫をなんとかしなければと思いました。 とはいえ、著者である私が、Yahoo!オークションやAmazonマーケットプレイスでこの在庫を販売することもためらわれました。 そこで、冒頭に書いたように、何冊かを進呈し
何が正しいのかを考える際は、正しさの基準が必要 - ockeghem's blog
大垣さんの寄稿記事「第44回 セキュリティ対策が確実に実施されない2つの理由：なぜPHPアプリにセキュリティホールが多いのか?｜gihyo.jp … 技術評論社」のまとめにて、『最後に「何が正しいのか？」常に考えるようにしてください』と書かれています。この部分は、私への反論のようですので、このエントリで返答したいと思います。 大垣さんの主張 先にも述べたように、大垣さんはこのエントリの「まとめ」として以下のように書かれています。 最後に「何が正しいのか？」常に考えるようにしてください。 http://gihyo.jp/dev/serial/01/php-security/0044?page=2 この主張自体には私も大賛成です。大垣さんの記事は以下のように続きます。 例えば，SQL文を作成する場合にリテラル（パラメータ）を文字列としてエスケープすると浮動小数点型のデータが正しく処理されないデ
「SQLインジェクション対策」でGoogle検索して上位15記事を検証した - ockeghem's blog
このエントリでは、ネット上で「SQLインジェクション対策」でGoogle検索した結果の上位15エントリを検証した結果を報告します。 SQLインジェクション脆弱性の対策は、既に「安全なSQLの呼び出し方」にファイナルアンサー（後述）を示していますが、まだこの文書を知らない人が多いだろうことと、やや上級者向けの文書であることから、まだ十分に実践されてはいないと思います。 この状況で、セキュリティのことをよく知らない人がSQLインジェクション対策しようとした場合の行動を予測してみると、かなりの割合の人がGoogle等で検索して対処方法を調べると思われます。そこで、以下のURLでSQLインジェクション対策方法を検索した結果の上位のエントリを検証してみようと思い立ちました。 http://www.google.co.jp/search?q=SQLインジェクション対策 どこまで調べるかですが、以前NH
twitterにクロスサイトスクリプティング(XSS)脆弱性があればパスワードを変更できる - ockeghem's blog
秋のDK収穫祭などで騒がれている、いわゆるDK祭り。 さすがの私も、今夜半の祭りにはmaitter。 私のtwitterが荒らされていたのだ。 http://blog.livedoor.jp/dankogai/archives/50959103.html 現象から見てセッションハイジャックされたと思われるが、原因となる脆弱性が小飼弾氏の主張どおりCSRF(Cross Site Request Forgeries)だったのか、パスワードは窃取されたのか、元々のパスワードが類推しやすいものだったのかなど、議論を呼んでいる。 私は、現象からみて、原因となる脆弱性はCSRFではなく、XSSだったと思う*1。twitterにXSS脆弱性があれば、セッションハイジャックにより、第三者が小飼弾氏になりすまして発言するところまでは可能だ。しかし、一般的にはXSSではパスワードまでは窃取できない。id:ha
クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
