タグ

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

  • クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記

    昨日の日記で、DK祭りで使われている脆弱性がXSSかCSRFかという問題になった。どうも、XSSとCSRFがごっちゃになっている人もいるように見受けるので、簡単な整理を試みたい。 XSSとCSRFには似た点がある。 どちらも「クロスサイト」という言葉が先頭につく なりすましのようなことが結果としてできる どちらも受動型攻撃である それに対して、もちろん違う点もある。専門家から見れば「似てるも何も、そもそも全然違うものですよ」となるのだろうが、現に混同している人がいるのだから紛らわしい点もあるのだろう。 私思うに、XSSとCSRFの決定的な違いは、以下の点ではないだろうか。 XSSは攻撃スクリプトがブラウザ上で動くが、CSRFはサーバー上で動く このため、XSSでできる悪いことは、すなわちJavaScriptでできることであって、攻撃対象のCookieを盗み出すことが典型例となる。一方、CS

    クロスサイトスクリプティング(XSS)とCSRFの違い早分かり - ockeghem(徳丸浩)の日記
  • PHPのSession Adoptionは重大な脅威ではない - ockeghem's blog

    なぜPHPアプリにセキュリティホールが多いのか?:第25回 PHPのアキレス腱にて、大垣靖男氏がPHPSession Adoption問題について取り上げている。大垣氏は度々この問題を取り上げているが、今のところ氏の主張に同調する人を見かけない。それもそのはずで、大垣氏の主張は間違っていると私は思う。 以下、大垣氏の主張を実際に試してみる形で、順に説明しよう。 大垣氏の主張 大垣氏の主張は、PHPにはSession Adoption脆弱性があるために、標準的なSession Fixation対策であるsession_regenerate_id()を施しても、その対策は有効ではないというものだ。 しかし,実際には現在に至るまでPHPのセッションモジュールのセッションアダプション脆弱性は修正されないままになっています。このために,来はsession_regenerate_id関数をログイン

    PHPのSession Adoptionは重大な脅威ではない - ockeghem's blog
    Akaza
    Akaza 2011/12/06
    session
  • 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
    Akaza
    Akaza 2011/09/05
    jQueryのtextメソッドは、HTMLタグ文字列を渡してもタグが生成されないので、XSSが生じない。対してhtmlメソッドはタグ生成を行うのでリスクがある。
  • もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog

    たにぐちまことさんの書かれた『よくわかるPHPの教科書(以下、「よくわかる」)』を購入してパラパラと見ていたら、セキュリティ上の問題がかなりあることに気がつきました。そこで、拙著「体系的に学ぶ 安全なWebアプリケーションの作り方(以下、徳丸)」の章・節毎に照らし合わせて、「よくわかる」の脆弱性について報告します。主に、徳丸の4章と5章を参照します。 4.2 入力処理とセキュリティ 「よくわかる」のサンプルや解説では、入力値検証はほとんどしていません。しかし、入力値検証をしていないからといって即脆弱かというとそうではありません。徳丸でも強調しているように、入力値検証はアプリケーション要件(仕様)に沿っていることを確認するもので、セキュリティ対策が目的ではないからです。 「よくわかる」の中で、私が見た範囲で唯一の入力値検証は、郵便番号のチェックをするものです。以下に引用します(「よくわ

    もし『よくわかるPHPの教科書』の著者が徳丸浩の『安全なWebアプリケーションの作り方』を読んだら - ockeghem's blog
  • PHPにおけるファイルアップロードの脆弱性CVE-2011-2202 - ockeghem's blog

    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 に移転しました。恐れ入りますが、続きは、そちらをご覧ください。

    PHPにおけるファイルアップロードの脆弱性CVE-2011-2202 - ockeghem's blog
  • “完璧なWAF”に学ぶWAFの防御戦略 - ockeghem's blog

    セキュリティExpert 2010に大河内智秀氏が「現状の課題と“完璧なWAF”」と題して寄稿されている。大変興味深い内容であるので、この寄稿をなぞりながら、WAFの防御戦略について検討してみたい。 クロスサイト・スクリプティング(XSS)に対する防御 大河内氏の寄稿の前半は、現状のWAFの課題として、Webアプリケーションに対する攻撃の多く(大半)がWAFのデフォルト設定では防御できないと指摘する。例えばクロスサイト・スクリプティング(XSS)に関しては、以下のような指摘がある。 仮にscriptをブラックリストに指定したとしましょう。それでもまだ不十分です。<IMG>タグでXSSが発動することをご存じでしょうか?プログラムなどでは<IMG>タグは画像添付に必須であり、WAFで禁止することは難しいのが実情で、ブラックリスト方式の課題となっています。 「現状の課題と“完璧なWAF”」より引

    Akaza
    Akaza 2010/05/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
  • pg_sleepをSQLインジェクション検査に応用する - ockeghem's blog

    SQLインジェクションの進化形として、ブラインドSQLインジェクションという手法があります。通常のSQLインジェクションは、検索結果表示やエラー表示のところに、アプリケーションの想定とは別のテーブル・列の値を表示するものですが、ブラインドSQLインジェクションは、SQLの結果がエラーになる・ならないを1ビットの情報として悪用し、これを積み重ねることで、データベース内の任意情報を得ることができるというものです。 1ビットの情報が得る手段としては、SQLのエラー表示に限らないわけで、現実問題として、SQLのエラーが外部からは判別しにくい場合もあります。そのような場合の究極形として、時間差を利用するという手法があります。 MS SQL Serverには、waitfor delayという命令があって、時・分・秒指定でスリープさせることができます。金床には、MySQLやPostgreSQLの場合の

    pg_sleepをSQLインジェクション検査に応用する - ockeghem's blog
    Akaza
    Akaza 2009/11/19
    "ブラインドSQLインジェクションは、SQLの結果がエラーになる・ならないを1ビットの情報として悪用し、これを積み重ねることで、データベース内の任意情報を得る"
  • 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

    PHP逆引きレシピは概ね良いが、SQLインジェクションに関しては残念なことに - ockeghem's blog
    Akaza
    Akaza 2009/08/10
    整数型のエスケープはキャストで代用できる。 ex.) (int)$id
  • 1