このエントリでは、セキュリティの観点から、バリデーション実装について検討します。大垣さんの本を読んで「大垣流バリデーション」について勉強した結果を報告します。 はじめに 大垣さんの記事「入力バリデーションはセキュリティ対策」では、「入力バリデーションはセキュリティ対策である」が力説されています。この記事はおそらくid:ajiyoshiさんのブログ記事「妥当性とは仕様の所作 - SQLインジェクション対策とバリデーション」を受けてのことだと思います。id:ajiyoshiさんのエントリでは、「妥当性検証は仕様の問題であってセキュリティ対策ではありません」と明言されています。私はid:ajiyoshiさんに近い考えを持っていますので、大垣さんの主張について、私なりに考えてみました。 記事を書くにあたり、徳丸の立場を明確にしておきたいと思います。 バリデーションの基準は仕様の問題 バリデーション

このエントリでは、ネット上で「SQLインジェクション対策」でGoogle検索した結果の上位15エントリを検証した結果を報告します。 SQLインジェクション脆弱性の対策は、既に「安全なSQLの呼び出し方」にファイナルアンサー（後述）を示していますが、まだこの文書を知らない人が多いだろうことと、やや上級者向けの文書であることから、まだ十分に実践されてはいないと思います。 この状況で、セキュリティのことをよく知らない人がSQLインジェクション対策しようとした場合の行動を予測してみると、かなりの割合の人がGoogle等で検索して対処方法を調べると思われます。そこで、以下のURLでSQLインジェクション対策方法を検索した結果の上位のエントリを検証してみようと思い立ちました。 http://www.google.co.jp/search?q=SQLインジェクション対策 どこまで調べるかですが、以前NH

このエントリでは「体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践」（いわゆる徳丸本、#wasbook）の電子書籍版が9月28日（水）に販売開始されるというお知らせをします。 大変要望の多かった徳丸本の電子書籍版ですが、タイトルのように、9月28日（水）の午前中に販売開始されることになりました。以下に諸データを記します。 販売サイト ブックパブ（http://bookpub.jp/） 販売開始 9/28（水）午前 定価 2,800円 キャンペーン価格 1,800円 キャンペーン期間 9/28（水）〜10/17（月）の20日間 いくつか特記すべき事項があります。 まず、電子書籍の形式ですが、*DRMフリーのPDF* です。従来版元のソフトバンククリエイティブでは、iOSやAndroidのアプリという形式で電子書籍を販売したようですが、この徳丸本の電子版から

昨日の日記の続きで、Ajaxに固有なセキュリティ問題について検討します。今回はJSON等の想定外読み出しによる攻撃です。これら攻撃手法は本来ブラウザ側で対応すべきもので、やむを得ずWebアプリケーション側で対応する上で、まだ定番となる対策がないように思えます。このため、複数の候補を示することで議論のきっかけにしたいと思います。 まず、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeから、Ajaxを利用したアプリケーションの概念図を引用します（同書P20の図1-23）。 前回、前々回は、(5)のHTTPレスポンスの前後で、JSON等のデータ作成（エンコード）に起因するevalインジェクションや、(5)のレスポンスを受け取った後のHTMLレンダリングの際のXSSについて説明しました。 しかし、問題はこれだけではありません。正常

昨日の日記の続きで、Ajaxに固有なセキュリティ問題について検討します。タイトルはXSSとなっていますが、今回紹介する脆弱性はXSSではありません。 作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeから、Ajaxを利用したアプリケーションの概念図を引用します（本書P20の図1-23）。 Ajaxのアプリケーションでは、XMLHttpRequestメソッド等でデータを要求し、サーバーはXML、JSON、タブ区切り文字列など適当な形式で返します。ブラウザ側JavaScriptでは、データ形式をデコードして、さまざまな処理の後、HTMLとして表示します。以下に、Ajaxのリクエストがサーバーに届いた後の処理の流れを説明します。 サーバー側でデータを作成、取得 データ伝送用の形式（XML、JSON、タブ区切り文字列等）にエンコード

今日、KDDIのEZfactoryのEZ番号に関する説明が変更されていました。 2011年6月9日の内容（URLは魚拓）赤字はママ HTTP Requestヘッダ情報では、この他にHTTP_X_UP_SUBNOフィールドにてEZ番号が確認できます。 EZ番号は、ユーザの端末操作によって、送出しない設定にすることが可能です。ユーザが「送出しない」設定にした場合、本フィールドは送出されません。 ※EZ番号に関する注意 EZ番号はスマートフォン等では詐称可能なため、ユーザー認証に用いる場合には、EZ番号と併せてEZサーバのIPアドレス等、複数手段で確認してください。 http://megalodon.jp/2011-0609-1231-51/www.au.kddi.com/ezfactory/tec/spec/4_4.html 本日2011年7月15日の内容。赤字指定は筆者。 EZ番号とは、EZ

ソフトバンク携帯電話のSSL方式変更に伴い、みずほ銀行のモバイルバンキングが一部使えなくなっていましたが、昨日復旧したようです。 7月3日時点では、みずほダイレクトのトップに以下のように表示されていました。URLは魚拓のものです。 現在、ソフトバンクの携帯電話からアクセスいただいた、みずほダイレクト（モバイルバンキング）の［ネット決済振込サービス］および［Pay-easy（ペイジー）税金・料金払込みサービス］において、一部のお取引がご利用いただけません。「ご利用の端末のユーザーIDを「ON」に設定し、再度アクセスしてください。」と表示された場合には、パソコンなどでご利用ください。 お客さまには大変ご迷惑をおかけしておりますことをお詫び申しあげます。 （原因につきましては現在調査中です。） http://megalodon.jp/2011-0703-0032-51/www.mizuhoban

昨日のソフトバンクの非公式JavaScript対応の調査結果 | 徳丸浩の日記で報告したように、昨年5月に、ソフトバンク60機種の検証を行い、JavaScript対応の状況などを調査しました。当時はまだ公式なJavaScript対応機種はない状態でしたが、既にほとんどの端末が *非公式に* JavaScriptに対応していました。 このエントリでは、検証の様子を報告します。 なぜJavaScript対応状況を調査したか http://www.hash-c.co.jp/info/20091124.htmlを公表した前後に、とある方（この方）から、ソフトバンクのケータイでもJavaScriptが動作すると伺いました（参考のやりとり）。XMLHttpRequestも含めてJavaScrptが動くと教えていただいた932SHを私も購入して調べたところ、以下が判明しました。 確かにJavaScrip

PHPの現行バーション（PHP5.3.6以前）には、ファイルアップロード時のファイル名がルート直下の場合、先頭のスラッシュを除去しないでファイル名が渡される問題があります。CVE-2011-2202として報告されています。 後述するように影響を受けるアプリケーションは少ないと思われますが、念のためアプリケーションの確認を推奨します。また、次バージョンPHP5.3.7のRC1で修正されていることを確認しましたので、PHP5.3.7正式版が公開され次第、できるだけ早期に導入することを推奨します。 ※このエントリは、http://blog.tokumaru.org/2011/06/PHP-file-upload-bug-CVE-2011-2202.html に移転しました。恐れ入りますが、続きは、そちらをご覧ください。

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

こんにちは、セキュリティ勉強会などで講師を担当しているockeghem夫です。私は学歴も知識もありませんが、セキュリティに関してはプロフェッショナル。今回は、モテるセキュ女子力を磨くための4つの心得を皆さんにお教えしたいと思います。 1. あえて2〜3世代前の書籍の知識で対策する あえて2〜3世代前の書籍の知識で脆弱性対策するようにしましょう。そして勉強会の打ち上げで好みの男がいたら話しかけみましょう。「あ〜ん！　addslashes本当にマジでチョームカつくんですけどぉぉお〜！」と言って、男に「どうしたの？」と言わせましょう。言わせたらもう大成功。「SQLインジェクションとか詳しくなくてぇ〜！ サテ技本に載ってたからずっとaddslashes使ってるんですけどぉ〜！ 日本語が化けるんですぅ〜！ ぷんぷくり〜ん（怒）」と言いましょう。だいたいの男は新しい書籍を持ちたがる習性があるので、古か

ライザムーン攻撃に対する行き届いた解説を読みました。 大規模インジェクション 「LizaMoon」攻撃について調べてみた。 - piyolog ここで紹介されている内容は素晴らしいと思うのですが、一点、WAFに関する以下の記述が引っかかりました。 SQLインジェクションであれば既知の攻撃手法でありWAFで防ぐことは出来るのではという考え方もありますが、例えばブラックリストタイプのWAFでこの数値リテラル型をつくSQLインジェクションを防ぐことが出来ません。HTTPリクエストとして受けた文字列だけで、最終的にデータベースに対して発行されるSQLでその文字列がどのような扱いになるか(数値リテラルになるのかどうか)判断することが出来ないためです。 本当にブラックリストタイプのWAFで防ぐことができないのでしょうか。IBMのレポートに紹介されている以下の攻撃で考えてみます。 /target.asp

2008年2月にパスワードの定期変更は「神話」なのか? - ockeghem(徳丸浩)の日記を書いた時の反応は、賛否両論という感じだったが、その後、twitterでのつぶやきなどを見るに、「パスワードは定期変更しなくてもいいんじゃない?」という意見は、セキュリティの専門家にも多くなっているような印象を受けている。 そのよう状況の中、以下の記事を読んだ。 辞書攻撃がうまくいかない場合、クラッカーは総攻撃（ブルートフォース攻撃とも言います）を仕掛けます。【中略】仮に1秒間に1000万回の計算ができるとすれば、パスワードのクラックに要する時間は1年にもなりません。どんなに強固なパスワードであっても、1年ももたないということになります。だからこそ、3カ月に1回とか半年に1回はパスワードを変更する必要があるのです。（2ページ目より引用） http://www.itmedia.co.jp/enterp

Loading...での発表に用いた資料です。 お役に立つかどうかは心許ないのですが、ドキュメントの一部を希望されていた方もおられましたので、slideshareで公開します。 ガラケーで楽しむオレJSの勧めView more presentations from Hiroshi Tokumaru.

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

大垣靖男さんの連載から 第21回 文字エンコーディングとセキュリティ（3）：なぜPHPアプリにセキュリティホールが多いのか?｜gihyo.jp … 技術評論社 一見この動作は無害のように思えるかもしれませんが，ブラウザなど，“\”がエスケープ文字になっているシステムでは重大な問題となります。 <div height="<?php echo addslashes($height); ?>" width="<?php echo addslashes($width); ?>"> この記事が公開された当初，上記のechoが抜けていた。しかし，echoがないと，プログラムの正常系としても動作しない。どこかから，突っ込みが入ったのであろう，その後echoが追加された。 しかし，まだ根本的におかしい。 なぜなら，以下の部分が間違っているからだ。 ブラウザなど，“\”がエスケープ文字になっているシステム

最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。本書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。そんな馬鹿なと思ったが、目次にも索引にも「セッション」や「session」という語は出てこない。サンプルプログラムのCD-ROM上で session を検索しても出てこないので、セッションはどこでも使っていないのだろう。 そうは言っても、本書にはブログやSNSなど認証が必要なアプリケーションも登場する。本書で採用している認証方式はこうだ。 携帯電話の個体識別番号を用いた、いわゆる「かんたんログイン」のみを使う 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する そのため、「iモードID」など、ユーザに確認せずに自動的に送信されるIDを用いる つまり、全て

既に発表されているように、NTTドコモの夏モデルからi-modeの仕様が大幅に拡張され、JavaScript、Cookie、Refererに対応するようになった。これら仕様変更はセキュリティの面からも影響が大きいため、私は夏モデルの中から、P-07Aを発売開始日(5月22日)に購入した。そして、リリースどおりJavaScript、Cookie、Refererが動作することを、実機にて確認した。 ところが、P-07Aと同日に発売開始されたN-06Aは、その日のうちに一時販売停止のお知らせが出る。 この度、弊社の携帯電話「N-06A」において、iモード接続時の不具合が確認されましたので、販売を一時見合わせさせていただきます。 なお、本事象に伴い、本日発表いたしました「N-08A」の販売開始日につきましても、5月28日から延期となります。 「N-06A」の販売再開及び「N-08A」の販売開始時期

前回のエントリSQLのバインド機構は「エスケープ処理された値」をはめ込むのか - ockeghem(徳丸浩)の日記に対応して、mi1kmanさんのブクマ経由で、訂正が出ていることを知った。 訂正内容 1ページ目を下記のように変更いたしました（2個所）。 バインド値はエスケープ処理した後にプレースホルダにはめ込むので、悪意あるSQL文が挿入されても、その実行を阻止することができる（図1-2）。 ↓ SQL文のひな型とバインド値は個別にデータベースに送られ、構文解析されるので、バインド値に悪意あるSQL文が挿入されても、その実行を阻止することができる（図1-2）。 http://www.impressit.co.jp/inside/?p=791 なんとなく私のエントリの断片が散りばめられているのを別にしても、『悪意あるSQL文…の実行を阻止することができる』というあたりに、サニタイズ的発想が依