PHPのイタい入門書を読んでAjaxのXSSについて検討した(3)～JSON等の想定外読み出しによる攻撃～ - ockeghem(徳丸浩)の日記
昨日の日記の続きで、Ajaxに固有なセキュリティ問題について検討します。今回はJSON等の想定外読み出しによる攻撃です。これら攻撃手法は本来ブラウザ側で対応すべきもので、やむを得ずWebアプリケーション側で対応する上で、まだ定番となる対策がないように思えます。このため、複数の候補を示することで議論のきっかけにしたいと思います。 まず、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeから、Ajaxを利用したアプリケーションの概念図を引用します（同書P20の図1-23）。 前回、前々回は、(5)のHTTPレスポンスの前後で、JSON等のデータ作成（エンコード）に起因するevalインジェクションや、(5)のレスポンスを受け取った後のHTMLレンダリングの際のXSSについて説明しました。 しかし、問題はこれだけではありません。正常
私はいかにしてソフトバンク端末60機種のJavaScriptを検証したか - ockeghem's blog
昨日のソフトバンクの非公式JavaScript対応の調査結果 | 徳丸浩の日記で報告したように、昨年5月に、ソフトバンク60機種の検証を行い、JavaScript対応の状況などを調査しました。当時はまだ公式なJavaScript対応機種はない状態でしたが、既にほとんどの端末が *非公式に* JavaScriptに対応していました。 このエントリでは、検証の様子を報告します。 なぜJavaScript対応状況を調査したか http://www.hash-c.co.jp/info/20091124.htmlを公表した前後に、とある方（この方）から、ソフトバンクのケータイでもJavaScriptが動作すると伺いました（参考のやりとり）。XMLHttpRequestも含めてJavaScrptが動くと教えていただいた932SHを私も購入して調べたところ、以下が判明しました。 確かにJavaScrip
僕が「ホワイトリスト」を採用しなかった訳 - ockeghem's blog
ホワイトリストという用語はセキュリティの分野では非常に基本的な用語ですが、セキュアプログラミングという文脈では意外に曖昧な使われ方がされているように見受けます。本エントリでは、ホワイトリストという用語の意味を三種類に分類し、この用語の実態に迫ります。拙著体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）では、ホワイトリストという用語を一度も使っていませんが、その理由に対する説明でもあります。 ホワイトリストの分類 私の調査によると、ホワイトリストは以下の3種類に分類されます。 許可されたものの一覧表（第一種ホワイトリスト） セキュリティ上安全と考えられる書式（第二種ホワイトリスト） アプリケーション仕様として許可された書式（第三種ホワイトリスト） 以下順に説明します。 許可されたものの一覧表（第一種ホワイトリスト） ホワイトリストというくらいですから、本来のホワイトリストは
evernoteのテキストをevernote社の管理者にも見えないように暗号化する - ockeghem's blog
このエントリでは、evernoteクライアントを使って、evernote社にも復号できない状態でテキストを暗号化する方法について紹介します。 昨日、EvernoteのXSS問題に関連して、「Evernoteの開発者も徳丸本読んでいたらよかったのにね」などとつぶやいていたら、「EvernoteのCEOが徳丸さんに会いたがっている」という連絡をもらいました。こういうのは異例のことでちょっと悩みましたが、行くっきゃないだろうということで、Evernote社の日本法人でmalaさんと一緒にCEOにお会いしました。 XSSやポリシーについては非常に誠実な対応をお約束いただいたのでよいミーティングだったと思います。僕が指摘した脆弱性についても、当日の夜のうちに直っていたようです。米国時間では深夜から早朝という時間帯で、迅速な対応だったと思いますが、本題はこれからです。 その場で、malaさんが「Eve
“完璧なWAF”に学ぶWAFの防御戦略 - ockeghem's blog
セキュリティExpert 2010に大河内智秀氏が「現状の課題と“完璧なWAF”」と題して寄稿されている。大変興味深い内容であるので、この寄稿をなぞりながら、WAFの防御戦略について検討してみたい。 クロスサイト・スクリプティング(XSS)に対する防御 大河内氏の寄稿の前半は、現状のWAFの課題として、Webアプリケーションに対する攻撃の多く（大半）がWAFのデフォルト設定では防御できないと指摘する。例えばクロスサイト・スクリプティング(XSS)に関しては、以下のような指摘がある。 仮にscriptをブラックリストに指定したとしましょう。それでもまだ不十分です。<IMG>タグでXSSが発動することをご存じでしょうか？プログラムなどでは<IMG>タグは画像添付に必須であり、WAFで禁止することは難しいのが実情で、ブラックリスト方式の課題となっています。 「現状の課題と“完璧なWAF”」より引
誤報訂正:『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逆引きレシピは概ね良いが、SQLインジェクションに関しては残念なことに - ockeghem's blog
404方面でも絶賛されていたPHP逆引きレシピを購入した。本書はとても丁寧な仕事で素晴らしいと思ったが、セキュリティに関しては若干残念な思いをしたので、それを書こうと思う。 目次は以下のようになっている。 第1章 準備 第2章 PHPの基本構文 第3章 PHPの基本テクニック 第4章 ファイルとディレクトリ 第5章 PEARとSmarty 第6章 Webプログラミング 第7章 クラスとオブジェクト 第8章 セキュリティ 8.1 セキュリティ対策の基本 8.2 PHPの設定 8.3 セキュリティ対策 第9章 トラブルシューティング 第10章 アプリケーション編 PHP逆引きレシピ オフィシャルサポート 本書は、タイトルの示すように、コレコレしたいという目的ごとにPHPでの書き方が書かれている。よくある逆引き辞典タイプの本だが、類書に比べて丁寧に書かれている印象を受けた。私が感心したのは、PH
携帯電話向けWebアプリのセッション管理はどうなっているか - ockeghem's blog
最近購入したPHP×携帯サイト 実践アプリケーション集を読んでいて妙な感じがしたので、この感覚はなんだろうと思っていたら、その理由に気づいた。本書に出てくるアプリケーションは、PHPのセッション管理機構を使っていないのだ。そんな馬鹿なと思ったが、目次にも索引にも「セッション」や「session」という語は出てこない。サンプルプログラムのCD-ROM上で session を検索しても出てこないので、セッションはどこでも使っていないのだろう。 そうは言っても、本書にはブログやSNSなど認証が必要なアプリケーションも登場する。本書で採用している認証方式はこうだ。 携帯電話の個体識別番号を用いた、いわゆる「かんたんログイン」のみを使う 認証状態をセッション管理機構で維持しない。全てのページで毎回認証する そのため、「iモードID」など、ユーザに確認せずに自動的に送信されるIDを用いる つまり、全て
i-mode2.0は前途多難 - ockeghem's blog
既に発表されているように、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」の販売開始時期
PHPのSession Adoptionは重大な脅威ではない - ockeghem's blog
なぜPHPアプリにセキュリティホールが多いのか?：第25回 PHPのアキレス腱にて、大垣靖男氏がPHPのSession Adoption問題について取り上げている。大垣氏は度々この問題を取り上げているが、今のところ氏の主張に同調する人を見かけない。それもそのはずで、大垣氏の主張は間違っていると私は思う。 以下、大垣氏の主張を実際に試してみる形で、順に説明しよう。 大垣氏の主張 大垣氏の主張は、PHPにはSession Adoption脆弱性があるために、標準的なSession Fixation対策であるsession_regenerate_id()を施しても、その対策は有効ではないというものだ。 しかし，実際には現在に至るまでPHPのセッションモジュールのセッションアダプション脆弱性は修正されないままになっています。このために，本来はsession_regenerate_id関数をログイン
正規表現で「制御文字以外」のチェック - ockeghem's blog
一般に、セキュアコーディングの基本として入力値の検証（Validation）をせよということになっていますが、これが変な方向に行くといわゆる「サニタイズ」のような手法になってしまいます。以前も指摘したように、アプリケーションとしてのValidationは仕様に従って行うべきものです。 ですが、概ねどの場合でも行うべき検証として以下があると思います。 文字エンコーディングの妥当姓 制御文字(\x00〜\x1f, \x7f)のチェック 文字列長のチェック このうち後ろ二つを正規表現として書くにはどうすればいいかを考えていました。つまり、「制御文字以外の文字でm文字以上n文字以下」というようなチェックです。m文字以上、n文字以下は、{m,n}で書けるので、問題は「制御文字以外の文字」です。これはtextタイプのinput要素で、かつアプリケーション仕様としては文字種の制限をしない場合を想定してい
SQLインジェクション攻撃はDB上の任意データを盗み出す - ockeghem's blog
前回に引き続き、Think IT上の連載「SQLインジェクション大全」の第4回：ケース別、攻撃の手口を読んで感じたことを書きたい。 まず、この記事は以下のような書き出しから始まっている。 本記事は、システムを防御するにはまず敵を知らなければならない、という意図の下に、攻撃手法を紹介する。 dfltweb1.onamae.com – このドメインはお名前.comで取得されています。 この趣旨に異論があるわけではないが、しかしこの表現は誤解を生みやすいものだと思う。 というのは、「敵」(攻撃方法)を知ったからと言って、防御の方法が導き出せる訳ではないからだ。例えば、開発者が「最近のSQLインジェクションの自動化攻撃にはT-SQLのDECLARE文が用いられる」という情報を得て独自に対策を考えた場合、DECLAREという単語をチェックしてエラーにしたり、単語を削除することを考えがちだと思う。現に
SQLのバインド機構は「エスケープ処理された値」をはめ込むのか - ockeghem's blog
以前このブログでも取り上げたことのある神戸デジタル・ラボの近藤伸明氏がThink IT上で「SQLインジェクション大全」という連載を執筆しておられる。その第三回「SQLインジェクションの対策」を読んで以下の部分が引っかかった。 バインド機構とは、あらかじめSQL文のひな型を用意し、後から変動個所（プレースホルダ）に実際の値（バインド値）を割り当ててSQL文を生成するデータベースの機能だ。バインド値はエスケープ処理した後にプレースホルダにはめ込むので、悪意あるSQL文が挿入されても、その実行を阻止することができる（図1-2）。 http://thinkit.jp/article/847/1/ たしかにエスケープ処理を使ってバインド機構を実装する場合もある。JavaとMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性 | 徳丸浩の日記から派生して、MyS
書籍『Ajaxセキュリティ』に関する残念なお知らせ - ockeghem's blog
昨年の10月に刊行された書籍Ajaxセキュリティは，発刊直後に購入したが，しばらく積ん読になっていた。最近になって読み始めたのだが，いささかあきれる結果となった。HPの現役エンジニア2名の著作，一人は元SPI Dynamics社(WebInspectの開発元，HPが買収)出身，GIJOE氏の監訳ということで期待していたのだが，残念である。 残念だと思う主要な理由は，脆弱性への対策が十分に示されていないことだ。Ajaxであってもインジェクション系脆弱性が発生する可能性があること，むしろ従来型のWebアプリケーションよりもその可能性が広がることは説明されているが，肝心の対策が不十分だ。 本書第四章の後半には，対策として入力検査（バリデーション）が示されている。 4.6 適切な入力検査 4.7 リッチなユーザ入力のバリデーション しかし，入力検証だけでは，任意の文字入力を許す場合の対策はできない
「なぜPHPアプリにセキュリティホールが多いのか?」のセキュリティホール - ockeghem's blog
大垣靖男さんの連載から 第21回 文字エンコーディングとセキュリティ（3）：なぜPHPアプリにセキュリティホールが多いのか?｜gihyo.jp … 技術評論社 一見この動作は無害のように思えるかもしれませんが，ブラウザなど，“\”がエスケープ文字になっているシステムでは重大な問題となります。 <div height="<?php echo addslashes($height); ?>" width="<?php echo addslashes($width); ?>"> この記事が公開された当初，上記のechoが抜けていた。しかし，echoがないと，プログラムの正常系としても動作しない。どこかから，突っ込みが入ったのであろう，その後echoが追加された。 しかし，まだ根本的におかしい。 なぜなら，以下の部分が間違っているからだ。 ブラウザなど，“\”がエスケープ文字になっているシステム
神戸デジタル・ラボの「セルフチェックかんたん5」は試すな危険 - ockeghem's blog
株式会社神戸デジタル・ラボが公表している「セルフチェックかんたん5」がWebアプリケーションセキュリティの一部専門家の間で話題になっている。 mi1kmanさん経由。 神戸デジタル・ラボさんの Webセキュリティ診断の販促ページ。 色々と言いたいことはありますが、一番は、「Webサイトセキュリティチェックリスト」の7ページ目：【中略】の部分ですかね。 手元の IE7/Firefox3 で試してみた限りでは、「http://int21h.jp/../」にアクセスした場合、ブラウザから出るリクエストの時点で「GET / HTTP/1.1」になっていました。（ブラウザが勝手に訂正してくれるので、GET /../ HTTP/1.1 のようなリクエストが送信されることは無さそう。） はたして“何らかのエラーメッセージ”が表示されることはあるのでしょうか…。(^-^; http://yamagata.
ミニミニブログにCSRF脆弱性 - ockeghem's blog
前回に引き続き、はじめてのPHPプログラミング 基本編5.3対応のゆるいところ第三段は、本書に紹介されているミニミニブログにクロスサイト・リクエストフォージェリ(CSRF)脆弱性があるというものだ。 このミニミニブログは、BASIC認証を利用していて、twitterやwassrなどのように一行コメントが書き込めるというものだ。BASIC認証、投稿機能があればCSRF脆弱性の対策が必要だが、本書にはCSRFに対する解説は特にないので、調べるまでもなくCSRF脆弱性があるのだろうと思っていた。 しかし、人様の書籍に確認もしないで脆弱性指摘をするのも失礼なので、以下のように簡単な検証コードを書いて試してみた。 <html><body> <form action="http://localhost/hajimete_php5/miniblog/index.php" method="post"> <
「セキュアなPHPアプリケーションを作成するための7つの習慣」のサンプルがとんでもなく酷い - ockeghem's blog
はてブで250以上のブックマークを得ている以下のエントリ。 PHP アプリケーションを作成する際には、可能な限りセキュアなアプリケーションにするために、次の 7 つの習慣を守る必要があります。 入力を検証する ファイルシステムを保護する データベースを保護する セッション・データを保護する XSS (Cross-Site Scripting: クロスサイト・スクリプティング) の脆弱性から保護する フォームへの投稿を検証する CSRF (Cross-Site Request Forgeries: クロスサイト・リクエスト・フォージェリー) から保護する ほう。しかし、内容はどうだろうか。 読んでびっくりした。説明も微妙なところが多いが、サンプルが酷い。こんなサンプルでは悪い習慣が身についてしまう。全部は書ききれないと思うので、目についたところからピックアップして紹介する。 パストラバーサル
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
「UnicodeによるXSSとSQLインジェクションの可能性」プレゼン資料 - ockeghem's blog
とくまるひろしのSession Fixation攻撃入門 - ockeghem's blog
