書籍「Android Security」の暗号鍵生成方法には課題がある - ockeghem's blog
書籍「Android Security 安全なアプリケーションを作成するために」は既に各方面で絶賛されているように、Androidアプリケーションの開発者には必携の書籍だと思いますが、新しい分野だけに、首をひねらざるを得ない箇所もありました。このエントリでは、同書第10章「暗号化手法」から共通鍵の生成方法について議論します。 はじめに 書籍「Android Security」（業界では「タオ本」と呼ばれているので、以下タオ本と記述）の10章では、端末内のファイルを暗号化して保存する手法について説明されています。その際に問題となるのが、鍵の生成と保管の方法です。スマートフォン端末、とくにAndroid端末は、アプリケーションのリバースエンジニアリングとルート化の可能性は常にあるため、あらゆる場合にも破られない暗号化というものはありません。このため、守るべき情報資産と、想定する脅威（言い換え
「管理者パスワードは何日ごとに変更すればよいか」に関する質疑応答 - ockeghem's blog
昨日Webサイトを守るためのセキュリティ講習会の講師を担当しました。講習会の終了後、受講生から「管理者パスワードの定期的変更」に関する質問がありました。備忘の為、質疑内容を以下に記録します。 Q1:上位ポリシーにて、管理者パスワードは定期的に変更するように義務づけられているが、何日毎に変更するのが正しいのか。最近の専門家の見解をお伺いしたい A1:専門家の見解は分かれているとお答えしました 現在の主流はパスワードを定期的に変更するべしという考え方ですが、それに異論を持つ人もいて、私もその一人です。 一般ユーザのパスワードとは異なり、管理者パスワードは、業務の必要上複数の人が知っている状況があります。その状況では、「定期的に変更」するのではなく、管理者パスワードを知っている人が、他業務に異動、あるいは退職するタイミングで遅滞なく変更するべきです。そうしないと、「管理者でなくなった人が管理者パ
何が正しいのかを考える際は、正しさの基準が必要 - ockeghem's blog
大垣さんの寄稿記事「第44回 セキュリティ対策が確実に実施されない2つの理由：なぜPHPアプリにセキュリティホールが多いのか?｜gihyo.jp … 技術評論社」のまとめにて、『最後に「何が正しいのか？」常に考えるようにしてください』と書かれています。この部分は、私への反論のようですので、このエントリで返答したいと思います。 大垣さんの主張 先にも述べたように、大垣さんはこのエントリの「まとめ」として以下のように書かれています。 最後に「何が正しいのか？」常に考えるようにしてください。 http://gihyo.jp/dev/serial/01/php-security/0044?page=2 この主張自体には私も大賛成です。大垣さんの記事は以下のように続きます。 例えば，SQL文を作成する場合にリテラル（パラメータ）を文字列としてエスケープすると浮動小数点型のデータが正しく処理されないデ
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
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
誤報訂正:『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リバインディングがもっとも警戒すべきなのか。このため、この記事の裏を取ってみようと思っ
XMLHttpRequestから送られてくるHTTPリクエストヘッダ - ockeghem's blog
以下のようになります。CGIでHTTP_で始まる環境変数を列挙したものです。 HTTP_USER_AGENT=DoCoMo/2.0 P07A3(c500;TB;W24H15) HTTP_COOKIE=≪Cookie値≫ HTTP_X_UE_VERSION=1 HTTP_HOST=≪ホスト名≫これは、通常のリクエストと全く同じで、XMLHttpRequestを区別するためのリクエストヘッダはありません。 追記(2009/11/18) PCのブラウザの場合、もう少しヘッダが多くつくことと、際だった違いとして、Refererが付与されることがあります。なぜ付与しないのですかね。ちなみに、SCRIPT要素のSRC属性で呼び出した場合はRefererが付与されます…なんて書いたらSCRIPT要素からのRefererも削除されかねませんな。
携帯電話向け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関数をログイン
コメント masa (2008/02/29 18:31) - パスワードの定期変更は「神話」なのか? - ockeghem(徳丸浩)の日記
ITProの記事が契機となって、PCIDSS（PCIデータセキュリティ規準）およびパスワードに関する規定が話題となっている*1。 「パスワードは90日ごとの変更」が義務づけられる！？ | 日経 xTECH（クロステック） それに対して，PCIDSSは表現が具体的である。現在のバージョン1.1ではパスワードについて下記のような規定がある。 ■要件8.5.8 グループ、共有または汎用のアカウントとパスワードを使用しないこと。 ■要件8.5.9 ユーザー・パスワードは少なくとも90日ごとに変更する。 http://itpro.nikkeibp.co.jp/article/OPINION/20080220/294287/ このうち、要件8.5.9「ユーザー・パスワードは少なくとも90日ごとに変更する」に関して疑問を持った。これはいわゆる「セキュリティの常識」という奴の一つではあるが、実際のところ、
2007-03-06
ケータイWebアプリの脆弱性問題は、私の専門分野であるので、もう少し突っ込んでみたいと思う。 高木浩光氏の高木浩光＠自宅の日記 - 携帯電話向けWebアプリの脆弱性事情はどうなっているのか 携帯電話Webアプリのセキュリティが怪しいという話はいろいろな人から耳にするが、携帯の世界では秘密保持契約による縛りがあって、皆それらを話せない状態になっているようだ。その結果として、脆弱性の実態が明らかにならないばかりか、正しい実装方法の普及が進まない。 この問いかけに対して、技術論ではなく、脆弱性検査を実施した結果の統計情報で回答する。 というには、私の勤務先では、まさにケータイ向けWeb脆弱性診断をやっていて、昨年一年間の脆弱性傾向の統計を発表しているからだ。 https://www.kccs.co.jp/contact/paper_websecurity/index.html このホワイトペーパ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
CookieのDomain属性は *指定しない* が一番安全 - ockeghem(徳丸浩)の日記
「UnicodeによるXSSとSQLインジェクションの可能性」プレゼン資料 - ockeghem's blog
とくまるひろしのSession Fixation攻撃入門 - ockeghem's blog