はてなブックマークボタンがマイクロアド社の新ガイドラインに従ったらこうなる - ockeghem's blog
すでにこちらでご案内の通り、私のブログ（徳丸浩の日記およびEGセキュアソリューションズオフィシャルブログ）に貼っていた「はてなブックマークボタン」により、読者の皆様の閲覧行動がマイクロアド社によりトラッキングされておりました。読者の皆様に断りなく不快な結果を強いていたことに対してお詫び申し上げます。既に当該ボタンは撤去しております。 その後、株式会社はてな社長の近藤淳也氏およびはてなの日記にて行動情報の提供をやめる旨のアナウンスが一昨日ありました（こことここ）。さらに、マイクロアド社からは、昨日以下のアナウンスがありました。 今後マイクロアドでは、ブログパーツや外部ボタン等、マイクロアドと直接提携関係にあるパートナー以外の第三者にあたる媒体・配信面に付与される可能性のあるものについて、それらの表示領域にマイクロアドからの行動履歴情報の蓄積を無効化するオプトアウトページへの導線設置を義務化い
「SQLインジェクション対策」でGoogle検索して上位15記事を検証した - ockeghem's blog
このエントリでは、ネット上で「SQLインジェクション対策」でGoogle検索した結果の上位15エントリを検証した結果を報告します。 SQLインジェクション脆弱性の対策は、既に「安全なSQLの呼び出し方」にファイナルアンサー（後述）を示していますが、まだこの文書を知らない人が多いだろうことと、やや上級者向けの文書であることから、まだ十分に実践されてはいないと思います。 この状況で、セキュリティのことをよく知らない人がSQLインジェクション対策しようとした場合の行動を予測してみると、かなりの割合の人がGoogle等で検索して対処方法を調べると思われます。そこで、以下のURLでSQLインジェクション対策方法を検索した結果の上位のエントリを検証してみようと思い立ちました。 http://www.google.co.jp/search?q=SQLインジェクション対策 どこまで調べるかですが、以前NH
私はいかにしてOperaブラウザのCookie Monster Bugを確認したか - ockeghem's blog
昨日の日記「都道府県型JPドメインがCookieに及ぼす影響の調査 | 徳丸浩の日記」にも書きましたが、Operaブラウザの最新版（11.51）には、地域型ドメインの場合にCookie Monster Bugがあります。以下は、三重県の志摩市のドメイン(www.city.shima.mie.jp)上で domain=mie.jpのCookieをセットした様子です。 この状態で三重県津市(www.info.city.tsu.mie.jp)のホームページにアクセスしたところ、このCookieが送信されることをネットワークキャプチャにて確認しました。 Operaブラウザは独自の方法でCookie Monster Bugに対応しているというのが業界の常識だと思っていましたので、当初この現象を見て驚きました。大げさに言えば「ニュートリノが光速を越えた」ことに匹敵する（大げさ過ぎ）ような驚きでしたので
『よくわかるPHPの教科書』のSQLインジェクション脆弱性 - ockeghem's blog
このエントリでは、数値型の列に対するSQLインジェクションについて説明します。 以前のエントリで、たにぐちまことさんの書かれた『よくわかるPHPの教科書』の脆弱性について指摘しました。その際に、『私が見た範囲ではSQLインジェクション脆弱性はありませんでした』と書きましたが、その後PHPカンファレンス2011の講演準備をしている際に、同書を見ていてSQLインジェクション脆弱性があることに気がつきました。 脆弱性の説明 問題の箇所は同書P272のdelete.phpです。要点のみを示します。 $id = $_REQUEST['id']; // $id : 投稿ID $sql = sprintf('SELECT * FROM posts WHERE id=%d', mysql_real_escape_string($id) $record = mysql_query($sql) or die(
もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
たにぐちまことさんの書かれた『よくわかるPHPの教科書（以下、「よくわかる」）』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸本の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸本でも強調しているように、入力値検証はアプリケーション要件（仕様）に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します（「よくわ
EZwebの2011年秋冬モデル以降の変更内容とセキュリティ上の注意点 - ockeghem's blog
au/KDDIの技術情報サイトEZfactoryには、2011年秋冬モデル以降にEZwebの仕様変更がある旨表示されています。セキュリティ上の問題の可能性もあるため以下に報告します。 EZfactoryトップページでの告知内容 EZfactoryトップページには、2011年秋冬モデルでの変更を以下のように要約しています。 ※お知らせ※ EZブラウザは、2011年秋冬モデルにて、EZサーバを含め、「機能」及び「ネットワーク環境」の見直しを行ないます。 これによる主な変更点は以下のとおりです。 ＜主な変更点＞ ・EZサーバの言語変換機能が削除され、HDMLが非サポートとなる。 ・EZブラウザ、PCサイトビューアーのIPアドレス帯域が統一される。 今後EZブラウザ向けコンテンツを作成する場合は、XHTML Basicを推奨します。 http://www.au.kddi.com/ezfactory
PHPのsocket_connect()関数における *つまらない* 脆弱性の話 - ockeghem's blog
Scan Tech Report（無償版）を読んでいたら、PHP には、socket_connect() 関数の脆弱性（CVE-2011-1938）があると紹介されていました。調査の結果、この脆弱性の影響を受けるPHPのバージョンとして公開されている情報は間違っているようなので報告します。 概要 Scan Tech Reportには以下のように説明されています。 PHP には、socket_connect() 関数の処理に起因してバッファオーバーフローを引き起こしてしまう脆弱性が報告されました。 http://scan.netsecurity.ne.jp/archives/51983960.html バッファオーバーフローというと影響が大きそうでびっくりしますが、この脆弱性はあまり話題になっていません。その理由は、この脆弱性が悪用されるシナリオがほとんどあり得ないからです。 もう少し、詳し
僕が「ホワイトリスト」を採用しなかった訳 - ockeghem's blog
ホワイトリストという用語はセキュリティの分野では非常に基本的な用語ですが、セキュアプログラミングという文脈では意外に曖昧な使われ方がされているように見受けます。本エントリでは、ホワイトリストという用語の意味を三種類に分類し、この用語の実態に迫ります。拙著体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）では、ホワイトリストという用語を一度も使っていませんが、その理由に対する説明でもあります。 ホワイトリストの分類 私の調査によると、ホワイトリストは以下の3種類に分類されます。 許可されたものの一覧表（第一種ホワイトリスト） セキュリティ上安全と考えられる書式（第二種ホワイトリスト） アプリケーション仕様として許可された書式（第三種ホワイトリスト） 以下順に説明します。 許可されたものの一覧表（第一種ホワイトリスト） ホワイトリストというくらいですから、本来のホワイトリストは
続パスワードの定期変更は神話なのか - ockeghem's blog
2008年2月にパスワードの定期変更は「神話」なのか? - ockeghem(徳丸浩)の日記を書いた時の反応は、賛否両論という感じだったが、その後、twitterでのつぶやきなどを見るに、「パスワードは定期変更しなくてもいいんじゃない?」という意見は、セキュリティの専門家にも多くなっているような印象を受けている。 そのよう状況の中、以下の記事を読んだ。 辞書攻撃がうまくいかない場合、クラッカーは総攻撃（ブルートフォース攻撃とも言います）を仕掛けます。【中略】仮に1秒間に1000万回の計算ができるとすれば、パスワードのクラックに要する時間は1年にもなりません。どんなに強固なパスワードであっても、1年ももたないということになります。だからこそ、3カ月に1回とか半年に1回はパスワードを変更する必要があるのです。（2ページ目より引用） http://www.itmedia.co.jp/enterp
携帯電話事業者に学ぶ「XSS対策」 - ockeghem's blog
NTTドコモとソフトバンクモバイルは、フィーチャーフォン（いわゆるガラケー）にてJavaScriptの対応を始めています。JavaScriptに対応すると、クロスサイト・スクリプティング(XSS)脆弱性の懸念が高まりますが、両社は独自の手法によりXSS対策をしている（しようとしている）挙動が観測されましたので報告します。この内容は、オレ標準JavaScript勉強会でネタとして使ったものです。 NTTドコモに学ぶ「XSS対策」まず、サンプルとして以下のようなXSS脆弱なスクリプトを用意します。 <?php session_start(); ?> <body> こんにちは<?php echo $_GET['p']; ?>さん </body>これを以下のURLで起動すると、IE7では下図のような表示になります。 []http://example.com/xss01.php?p=山田<scrip
新党のホームページを見てメールアドレスのチェック方法について考えた - ockeghem(徳丸浩)の日記
新政党「たちあがれ日本」のホームページが話題になっていたので私も見てみた。そして、メーリングリストの受付フォーム中に記述されたメールアドレスのチェック用のJavaScriptが気になった。以下に引用する。 if (!node.match(/^[A-Za-z0-9]+[\w-]+@[\w\.-]+\.\w{2,}$/)){ alert("e-mailアドレスをご確認ください。"); return false; } https://www.tachiagare.jp/mail.php メールアドレスをチェックするための正規表現は、ネット上でたびたび問題視される定番ネタだか、その論点は、RFC(RFC2822やRFC5322)に対して準拠しているかどうかだと思う。例えばこれ(404 Blog Not Found:「PHP使いはもう正規表現をblogに書くな」と言わせないでくれ)。 しかし、現実に
誤報訂正:『2010年に最も警戒すべきセキュリティ脅威は「DNSリバインディング」』報道について - ockeghem's blog
computerworld.jpは3月17日に『2010年に最も警戒すべきセキュリティ脅威は「DNSリバインディング」』と題した記事を公開したが、一部誤報があるので訂正する。 米国White Hat Securityの研究者らがまとめた2010年版の深刻なセキュリティ脅威トップ10では、DNSリバインディングが1位となった。同社では、2006年から毎年、脅威トップ10を発表している。 http://www.computerworld.jp/news/sec/177029.html 当初、この記事を読んで違和感を覚えた。DNSリバインディングという攻撃手法そのものは以前から知られているものであるし、この記事で説明されている脅威の内容についても、以前から知られているものと違わない。このタイミングでなぜ、DNSリバインディングがもっとも警戒すべきなのか。このため、この記事の裏を取ってみようと思っ
「セキュアなPHPアプリケーションを作成するための7つの習慣」のサンプルがとんでもなく酷い - ockeghem's blog
はてブで250以上のブックマークを得ている以下のエントリ。 PHP アプリケーションを作成する際には、可能な限りセキュアなアプリケーションにするために、次の 7 つの習慣を守る必要があります。 入力を検証する ファイルシステムを保護する データベースを保護する セッション・データを保護する XSS (Cross-Site Scripting: クロスサイト・スクリプティング) の脆弱性から保護する フォームへの投稿を検証する CSRF (Cross-Site Request Forgeries: クロスサイト・リクエスト・フォージェリー) から保護する ほう。しかし、内容はどうだろうか。 読んでびっくりした。説明も微妙なところが多いが、サンプルが酷い。こんなサンプルでは悪い習慣が身についてしまう。全部は書ききれないと思うので、目についたところからピックアップして紹介する。 パストラバーサル
クイズ:XSSとCSRFはどこにありますか? - ockeghem's blog
先の日記(XSSはブラウザ上でスクリプトが動き、CSRFはサーバー上でスクリプトが動く - ockeghem(徳丸浩)の日記)は、仕込んだネタがあたって多くの方に読んでいただいた。細かい内容については、頂戴した批判や反省もあるが、このテーマに対して多くの関心を集めることができたのは良かったと思う。今回も、手を変え品を変えて、XSSとCSRFの違いを説明しよう。ということで、今回はクイズ仕立てにしてみた。 といっても、非常に簡単なクイズだ。 認証を必要とする会員制サイトmaitter.comで、個人情報を入力する画面がある。典型的な、入力(A)-確認(B)-登録(C)という画面遷移（下図）を想定した場合、 XSSが発生しやすい画面を一つあげよ CSRFが発生しやすい画面を一つあげよ というものだ(入力画面は初期入力のみ想定)。エラー時の挙動などは指定されていないので想定しないものとする。 解
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「UnicodeによるXSSとSQLインジェクションの可能性」プレゼン資料 - ockeghem's blog