タグ

ブックマーク / ockeghem.hatenablog.jp (20)

  • 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について検討した(3)~JSON等の想定外読み出しによる攻撃~ - ockeghem(徳丸浩)の日記
    send
    send 2011/11/25
  • 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について検討した(2)~evalインジェクション~ - ockeghem(徳丸浩)の日記
    send
    send 2011/11/25
  • PHPのイタい入門書を読んでAjaxのXSSについて検討した(1) - ockeghem's blog

    このエントリでは、あるPHPの入門書を題材として、Ajaxアプリケーションの脆弱性について検討します。全3回となる予定です。 このエントリを書いたきっかけ twitterからタレコミをちょうだいして、作りながら基礎から学ぶPHPによるWebアプリケーション入門XAMPP/jQuery/HTML5で作るイマドキのWeというを読みました。所感は以下の通りです。 タレコミ氏の主張のように、書はセキュリティを一切考慮していない 主な脆弱性は、XSS、SQLインジェクション、任意のサーバーサイド・スクリプト実行(アップロード経由)、メールヘッダインジェクション等 脆弱性以前の問題としてサンプルスクリプトの品質が低い。デバッグしないと動かないスクリプトが多数あった 上記に関連して、流用元のソースやデバッグ用のalertなどがコメントとして残っていて痛々しい 今時この水準はないわーと思いました。以前

    PHPのイタい入門書を読んでAjaxのXSSについて検討した(1) - ockeghem's blog
    send
    send 2011/11/25
  • CookieのDomain属性は *指定しない* が一番安全 - ockeghem(徳丸浩)の日記

    たまに誤解があるようですが、Cookieを設定する場合のDomain属性は *設定しない* のがもっとも安全です。以下、例示により説明します。 ※このエントリは、http://blog.tokumaru.org/2011/10/cookiedomain.html に移転しました。恐れ入りますが、続きは、そちらをご覧ください。

    CookieのDomain属性は *指定しない* が一番安全 - ockeghem(徳丸浩)の日記
    send
    send 2011/10/13
  • evernoteのテキストをevernote社の管理者にも見えないように暗号化する - ockeghem's blog

    このエントリでは、evernoteクライアントを使って、evernote社にも復号できない状態でテキストを暗号化する方法について紹介します。 昨日、EvernoteのXSS問題に関連して、「Evernoteの開発者も徳丸読んでいたらよかったのにね」などとつぶやいていたら、「EvernoteCEOが徳丸さんに会いたがっている」という連絡をもらいました。こういうのは異例のことでちょっと悩みましたが、行くっきゃないだろうということで、Evernote社の日法人でmalaさんと一緒にCEOにお会いしました。 XSSやポリシーについては非常に誠実な対応をお約束いただいたのでよいミーティングだったと思います。僕が指摘した脆弱性についても、当日の夜のうちに直っていたようです。米国時間では深夜から早朝という時間帯で、迅速な対応だったと思いますが、題はこれからです。 その場で、malaさんが「Eve

    send
    send 2011/04/20
  • 続パスワードの定期変更は神話なのか - ockeghem's blog

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

    続パスワードの定期変更は神話なのか - ockeghem's blog
    send
    send 2010/12/09
  • 新党のホームページを見てメールアドレスのチェック方法について考えた - 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に書くな」と言わせないでくれ)。 しかし、現実に

    新党のホームページを見てメールアドレスのチェック方法について考えた - ockeghem(徳丸浩)の日記
    send
    send 2010/04/13
  • 誤報訂正:『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リバインディングがもっとも警戒すべきなのか。このため、この記事の裏を取ってみようと思っ

    誤報訂正:『2010年に最も警戒すべきセキュリティ脅威は「DNSリバインディング」』報道について - ockeghem's blog
    send
    send 2010/03/23
  • 携帯電話向けWebアプリのセッション管理はどうなっているか - ockeghem's blog

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

    携帯電話向けWebアプリのセッション管理はどうなっているか - ockeghem's blog
    send
    send 2009/10/28
  • SQLのバインド機構は「エスケープ処理された値」をはめ込むのか - ockeghem's blog

    以前このブログでも取り上げたことのある神戸デジタル・ラボの近藤伸明氏がThink IT上で「SQLインジェクション大全」という連載を執筆しておられる。その第三回「SQLインジェクションの対策」を読んで以下の部分が引っかかった。 バインド機構とは、あらかじめSQL文のひな型を用意し、後から変動個所(プレースホルダ)に実際の値(バインド値)を割り当ててSQL文を生成するデータベースの機能だ。バインド値はエスケープ処理した後にプレースホルダにはめ込むので、悪意あるSQL文が挿入されても、その実行を阻止することができる(図1-2)。 http://thinkit.jp/article/847/1/ たしかにエスケープ処理を使ってバインド機構を実装する場合もある。JavaMySQLの組み合わせでUnicodeのU+00A5を用いたSQLインジェクションの可能性 | 徳丸浩の日記から派生して、MyS

    SQLのバインド機構は「エスケープ処理された値」をはめ込むのか - ockeghem's blog
    send
    send 2009/03/03
  • 続:SQLのバインド機構は「エスケープ処理された値」をはめ込むのか - ockeghem's blog

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

    続:SQLのバインド機構は「エスケープ処理された値」をはめ込むのか - ockeghem's blog
    send
    send 2009/02/27
  • とくまるひろしのSession Fixation攻撃入門 - ockeghem's blog

    やぁ、みんな,元気?とくまるひろしです。今日はSession Fixation攻撃の方法をこっそり教えちゃうよ。 いつもは防御側で漢字の名前でやってるんだけど,きょうは攻撃側ということで,名乗りもひらがなに変えたんだ。だってさ,今度デブサミでご一緒するはせがわようすけさんとか,はまちちゃんとか,ひらがなの人たちの方が格好良さそうじゃないか。 では始めよう。 このエントリは、http://blog.tokumaru.org/2009/01/introduction-to-session-fixation-attack.html に移転しました。恐れ入りますが、続きは、そちらをご覧ください。

    とくまるひろしのSession Fixation攻撃入門 - ockeghem's blog
    send
    send 2009/02/02
  • 「なぜPHPアプリにセキュリティホールが多いのか?」のセキュリティホール - ockeghem's blog

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

    「なぜPHPアプリにセキュリティホールが多いのか?」のセキュリティホール - ockeghem's blog
    send
    send 2009/01/23
  • セキュリティエンジニア急募 - ockeghem's blog

    当ブログのオーナー(徳丸浩)の勤務先(京セラコミュニケーションシステム)にて、セキュリティエンジニアのキャリア採用を募集しています。 職種は、以下の通りです(若干名)。 Webアプリケーションの脆弱性診断エンジニアコンサルタント(の卵) セキュリティASPサイトの企画、構築、運用 セキュリティ製品のプリセールス、サポート 要求スキルは、ITの基礎スキル、ヒューマンスキルを重視しています。 プログラミング、システム構築スキル(1,2) とくに(1)に関しては、Webアプリケーション開発経験があるとよい ネットワーク、サーバー構築スキル(3) セキュリティエンジニアとしての経験(必須ではないあれば尚可) セキュリティに関心のある方 ヒューマンスキルとしては、 真面目な方 自分の人生を一生懸命に生きようとする方 明るい方(困難に対して前向きに考えられる方) を高く評価します。 そのほかの条件、

    セキュリティエンジニア急募 - ockeghem's blog
    send
    send 2007/11/20
    ニートやフリーターにやさしい
  • 危険文字と言わないで - ockeghem's blog

    昨日、とあるベンダーのセキュリティセミナーに行きました。 そしたら、どうです。僕らのことを「危険文字」と呼んでる人がいるじゃありませんか。 ひどすぎます。僕らは日夜、世界中で、HTMLのページを書いたり、データベースを検索したりで、Webを支えているんです。僕らが無かったら、Yahoo!だって、Amazonだって、Googleだって、tokumaru.orgだって実現できないんですよ。うそだと思ったら、「<」も「>」も「'」も「"」もなしに、Webアプリを書いてごらんなさい。 こんなことを言ったら、UTF-7なら、7bitアスキーなら「危険文字」使わないで書けるとか言う人がいるかもしれない。でも考えてみてください。UTF-7とか7bitアスキーの方こそ、よっぽど「危険」じゃないですか。それに、UTF-7は見た目が変なだけで(UTF-7怒るかな?)、結局は僕らのことを表現しているんです。当た

    危険文字と言わないで - ockeghem's blog
    send
    send 2007/09/11
    wwwwwww
  • Firefoxのひどい脆弱性 - ockeghem's blog

    id:hasegawayosukeさん経由 FirefoxとIEの相互作用でまた新たな脆弱性、エクスプロイトも公開 - ITmedia エンタープライズ MozillaのFirefoxブラウザとMicrosoftのInternet Explorer(IE)の相互作用で生じる深刻な脆弱性が、また新たに報告された。Firefoxが数日前にリリースしたバージョン2.0.0.5では未対応。IE 7が関与するエクスプロイトも公開されているという。 【中略】 US-CERTによると、この脆弱性は、Firefoxが特定のURIをフィルタにかけないまま、登録されたアプリケーションに引き渡してしまうことに起因する。これにより、リモートの攻撃者がFirefoxを攻撃経路として使い、悪質なURIを利用して任意のコマンドを実行することが可能になる。 インターネット上のコンテンツ経由で、クライアントのプログラムを実

    Firefoxのひどい脆弱性 - ockeghem's blog
  • XSS対策:JavaScriptなどのエスケープ - ockeghem's blog

    昨日の日記に対して、id:ikepyonさんからトラックバックを頂戴した。内容はそちら(Tipsと考え方とXSS対策)を読んでいただくとして、興味深いテーマなので少し突っ込んでみたい。 # 日によって「です・ます」で書いたり、「だ・である」で書いているのは気分の問題なので、あまり気にしないでいただきたい Tipsだけでなく、物事の質を見極め、何が危険で、何が安全なのかということを考える必要があると思う。 昨日の記事は、(一般的な)XSS対策として、どの文字をエスケープするのが「質的」だったかを考えたかったのであって、あれをTipsととらえると確かに失敗する。 JavaScriptのスクリプトなどが入っている場合も昨日と同じ方法論で考えることは可能である。まずはこれを検討してみよう。 スクリプトがonXXXのイベントハンドラとして記述されている場合 この場合は、HTMLタグの属性値として

    XSS対策:JavaScriptなどのエスケープ - ockeghem's blog
  • XSS対策:JavaScriptのエスケープ(その2) - ockeghem's blog

    5/11の日記XSS対策:JavaScriptなどのエスケープ - ockeghem(徳丸浩)の日記に対する金床さんのコメントに触発されて、JavaScriptのエスケープについて検討してみよう。ただし、現実のアプリケーション開発においては、私はJavaScriptの動的生成を推奨していないが、これはエスケープ処理をどのように考えるかと言うレッスンのつもりで検討することにする。 金床さんのコメントで紹介されたリンクには、以下のようなガイドライン案が提案されている。 JavaScriptの文字列でのエスケープ手順としては、以下が今のところ正解っぽい感じです。 1. 「\」を「\\」に置換する 2. 「"」を「\"」に置換する 3. 「'」を「\'」に置換する 4. 「/」を「\/」に置換する 5. 「<」を「\x3c」に置換する 6. 「>」を「\x3e」に置換する 7. 「0x0D(CR)

    XSS対策:JavaScriptのエスケープ(その2) - ockeghem's blog
  • Firefoxのパスワード・マネージャの脆弱性その後 - ockeghem's blog

    昨年の11月に、日経BPのITpro編集勝村記者(現在は日経パソコン)から表題の件で取材を受けた。 Firefoxの脆弱性は危険,“ワンクリック”でパスワードを盗まれる恐れあり | 日経 xTECH(クロステック) 「Firefoxユーザーがクロスサイト・スクリプティング(XSS)脆弱性のあるWebサイトでパスワードを記憶させている場合には,細工が施されたリンクをクリックするだけでそのパスワードを盗まれる恐れがある」――。京セラコミュニケーションシステムのセキュリティ事業部副事業部長である徳丸浩氏は11月24日,ITproの取材に対して,11月22日に公表されたFirefoxの脆弱性は,考えられているよりも深刻であるとして注意を呼びかけた。 Firefoxの最新バージョン(2.0.0.3)では、この問題を「緩和する」改善が見られたが、根的には対策されていない。Mozilla Founda

    Firefoxのパスワード・マネージャの脆弱性その後 - ockeghem's blog
    send
    send 2007/04/04
    いつ直るんだろう
  • 2007-03-06

    ケータイWebアプリの脆弱性問題は、私の専門分野であるので、もう少し突っ込んでみたいと思う。 高木浩光氏の高木浩光@自宅の日記 - 携帯電話向けWebアプリの脆弱性事情はどうなっているのか 携帯電話Webアプリのセキュリティが怪しいという話はいろいろな人から耳にするが、携帯の世界では秘密保持契約による縛りがあって、皆それらを話せない状態になっているようだ。その結果として、脆弱性の実態が明らかにならないばかりか、正しい実装方法の普及が進まない。 この問いかけに対して、技術論ではなく、脆弱性検査を実施した結果の統計情報で回答する。 というには、私の勤務先では、まさにケータイ向けWeb脆弱性診断をやっていて、昨年一年間の脆弱性傾向の統計を発表しているからだ。 https://www.kccs.co.jp/contact/paper_websecurity/index.html このホワイトペーパ

    2007-03-06
  • 1