クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS
徳丸本をブロガーに差し上げちゃうキャンペーンのお知らせ - ockeghem's blog
「徳丸本」こと「体系的に学ぶ 安全なWebアプリケーションの作り方」は、このたび増刷（第5刷）が決定いたしました。皆様のご愛読に深く感謝申し上げます。増刷を記念して、徳丸本を買いたくてもまだ買えていなかった方々に、徳丸本を進呈するキャンペーンを企画いたしました。 私の手元に徳丸本第3刷の在庫が数冊あります。元々献本用や（HASHコンサルティングの）営業活動の贈呈用として購入していたものですが、思ったほど「差し上げる」機会がなくて、死蔵されているような格好でした（この在庫とは別に増刷ごとに何冊かずつ送付いただいているため）。そんなタイミングで第5刷が出ることになったので、これはいかん、在庫をなんとかしなければと思いました。 とはいえ、著者である私が、Yahoo!オークションやAmazonマーケットプレイスでこの在庫を販売することもためらわれました。 そこで、冒頭に書いたように、何冊かを進呈し
『よくわかる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(
「安全なWebアプリケーションの作り方」電子書籍版9月28日（水）販売開始します - ockeghem's blog
このエントリでは「体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践」（いわゆる徳丸本、#wasbook）の電子書籍版が9月28日（水）に販売開始されるというお知らせをします。 大変要望の多かった徳丸本の電子書籍版ですが、タイトルのように、9月28日（水）の午前中に販売開始されることになりました。以下に諸データを記します。 販売サイト ブックパブ（http://bookpub.jp/） 販売開始 9/28（水）午前 定価 2,800円 キャンペーン価格 1,800円 キャンペーン期間 9/28（水）〜10/17（月）の20日間 いくつか特記すべき事項があります。 まず、電子書籍の形式ですが、*DRMフリーのPDF* です。従来版元のソフトバンククリエイティブでは、iOSやAndroidのアプリという形式で電子書籍を販売したようですが、この徳丸本の電子版から
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について説明しました。 しかし、問題はこれだけではありません。正常
PHPのイタい入門書を読んでAjaxのXSSについて検討した(2)～evalインジェクション～ - ockeghem(徳丸浩)の日記
昨日の日記の続きで、Ajaxに固有なセキュリティ問題について検討します。タイトルはXSSとなっていますが、今回紹介する脆弱性はXSSではありません。 作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeから、Ajaxを利用したアプリケーションの概念図を引用します（本書P20の図1-23）。 Ajaxのアプリケーションでは、XMLHttpRequestメソッド等でデータを要求し、サーバーはXML、JSON、タブ区切り文字列など適当な形式で返します。ブラウザ側JavaScriptでは、データ形式をデコードして、さまざまな処理の後、HTMLとして表示します。以下に、Ajaxのリクエストがサーバーに届いた後の処理の流れを説明します。 サーバー側でデータを作成、取得 データ伝送用の形式（XML、JSON、タブ区切り文字列等）にエンコード
PHPのイタい入門書を読んでAjaxのXSSについて検討した(1) - ockeghem's blog
このエントリでは、あるPHPの入門書を題材として、Ajaxアプリケーションの脆弱性について検討します。全3回となる予定です。 このエントリを書いたきっかけ twitterからタレコミをちょうだいして、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeという本を読みました。所感は以下の通りです。 タレコミ氏の主張のように、本書はセキュリティを一切考慮していない 主な脆弱性は、XSS、SQLインジェクション、任意のサーバーサイド・スクリプト実行（アップロード経由）、メールヘッダインジェクション等 脆弱性以前の問題としてサンプルスクリプトの品質が低い。デバッグしないと動かないスクリプトが多数あった 上記に関連して、流用元のソースやデバッグ用のalertなどがコメントとして残っていて痛々しい 今時この水準はないわーと思いました。以前
もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
たにぐちまことさんの書かれた『よくわかるPHPの教科書（以下、「よくわかる」）』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸本の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸本でも強調しているように、入力値検証はアプリケーション要件（仕様）に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します（「よくわ
僕が「ホワイトリスト」を採用しなかった訳 - ockeghem's blog
ホワイトリストという用語はセキュリティの分野では非常に基本的な用語ですが、セキュアプログラミングという文脈では意外に曖昧な使われ方がされているように見受けます。本エントリでは、ホワイトリストという用語の意味を三種類に分類し、この用語の実態に迫ります。拙著体系的に学ぶ 安全なWebアプリケーションの作り方（以下、徳丸本）では、ホワイトリストという用語を一度も使っていませんが、その理由に対する説明でもあります。 ホワイトリストの分類 私の調査によると、ホワイトリストは以下の3種類に分類されます。 許可されたものの一覧表（第一種ホワイトリスト） セキュリティ上安全と考えられる書式（第二種ホワイトリスト） アプリケーション仕様として許可された書式（第三種ホワイトリスト） 以下順に説明します。 許可されたものの一覧表（第一種ホワイトリスト） ホワイトリストというくらいですから、本来のホワイトリストは
オレ標準JavaScript勉強会発表資料 - ockeghem's blog
Loading...での発表に用いた資料です。 お役に立つかどうかは心許ないのですが、ドキュメントの一部を希望されていた方もおられましたので、slideshareで公開します。 ガラケーで楽しむオレJSの勧めView more presentations from Hiroshi Tokumaru.
携帯電話事業者に学ぶ「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
XSS対策:JavaScriptなどのエスケープ - ockeghem's blog
昨日の日記に対して、id:ikepyonさんからトラックバックを頂戴した。内容はそちら(Tipsと考え方とXSS対策)を読んでいただくとして、興味深いテーマなので少し突っ込んでみたい。 # 日によって「です・ます」で書いたり、「だ・である」で書いているのは気分の問題なので、あまり気にしないでいただきたい Tipsだけでなく、物事の本質を見極め、何が危険で、何が安全なのかということを考える必要があると思う。 昨日の記事は、(一般的な)XSS対策として、どの文字をエスケープするのが「本質的」だったかを考えたかったのであって、あれをTipsととらえると確かに失敗する。 JavaScriptのスクリプトなどが入っている場合も昨日と同じ方法論で考えることは可能である。まずはこれを検討してみよう。 スクリプトがonXXXのイベントハンドラとして記述されている場合 この場合は、HTMLタグの属性値として
新党のホームページを見てメールアドレスのチェック方法について考えた - 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リバインディングがもっとも警戒すべきなのか。このため、この記事の裏を取ってみようと思っ
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アプリケーションを作成するための7つの習慣」のサンプルがとんでもなく酷い - ockeghem's blog
はてブで250以上のブックマークを得ている以下のエントリ。 PHP アプリケーションを作成する際には、可能な限りセキュアなアプリケーションにするために、次の 7 つの習慣を守る必要があります。 入力を検証する ファイルシステムを保護する データベースを保護する セッション・データを保護する XSS (Cross-Site Scripting: クロスサイト・スクリプティング) の脆弱性から保護する フォームへの投稿を検証する CSRF (Cross-Site Request Forgeries: クロスサイト・リクエスト・フォージェリー) から保護する ほう。しかし、内容はどうだろうか。 読んでびっくりした。説明も微妙なところが多いが、サンプルが酷い。こんなサンプルでは悪い習慣が身についてしまう。全部は書ききれないと思うので、目についたところからピックアップして紹介する。 パストラバーサル
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CookieのDomain属性は *指定しない* が一番安全 - ockeghem(徳丸浩)の日記