タグ

xssに関するhiro1963のブックマーク (9)

  • 第11回 スクリプトインジェクションを防ぐ10のTips | gihyo.jp

    前回はスクリプトインジェクションがなくならない理由を紹介しました。それをふまえて今回はスクリプトインジェクションを防ぐ10のTipsを紹介します。 デフォルト文字エンコーディングを指定 php.iniには、PHPが生成した出力の文字エンコーディングをHTTPヘッダで指定するdefault_charsetオプションがあります。文字エンコーディングは必ずHTTPヘッダレベルで指定しなければなりません。しかし、デフォルト設定ではdefault_charsetが空の状態で、アプリケーションで設定しなければ、HTTPヘッダでは文字エンコーディングが指定されない状態になります。 HTTPヘッダで文字エンコーディングを指定しない場合、スクリプトインジェクションに脆弱になる場合あるので、default_charsetには“⁠UTF-8⁠”を指定することをお勧めします。サイトによってはSJIS、EUC-JP

    第11回 スクリプトインジェクションを防ぐ10のTips | gihyo.jp
  • Perlを使って脆弱性を検証する:CodeZine

    はじめに 今回はXSSの脆弱性をチェックするPerlスクリプトを作成したいと思います。すべてのXSSによる脆弱性が回避できるわけではありませんが、テストコード作成のヒントになれば幸いです。 対象読者 Webアプリケーション開発者で、XSSのテストケースを作成したい方。 必要な環境 Perl 5.8以上が動作する環境。基動作の確認はMac OS Xを利用しました。次のPerlモジュールを利用するので、あらかじめインストールしておいてください。 Template::Toolkit Web::Scraper Test::Base またCGIを使用するので、ApacheなどのCGIが実行できるWebサーバを用意してください。 解説内容 ソースコード解説 まず最初にソースコードの解説をします。 xss.pl

  • Webサーバへの攻撃を見抜く ― @IT

    ウイルス、ワーム、ボットによる攻撃……ネットワーク上に存在する脅威は多種多様である。サーバにアクセスされた形跡を見て、それが通常のものなのか、それとも脅威なのかを判断するには知識と経験が必要となる。そこで連載では、インシデント・ハンドリングのために必要な「問題を見抜く」テクニックを分野ごとに解説していく(編集部) ※ご注意 他社および他組織のWebサイトなどへのポートスキャンおよびデータの取得などの行為で得た情報を侵入などに悪用するか、または同じ目的を持つ第三者に提供した時点で違法となります。ご注意ください。 稿の内容を検証する場合は、必ず影響を及ぼさない限られた環境下で行って下さい。 また、稿を利用した行為による問題に関しましては、筆者およびアイティメディア株式会社は一切責任を負いかねます。ご了承ください。 インシデントを最終判断するのは「人間」 インターネットは、いわずと知れた世

    Webサーバへの攻撃を見抜く ― @IT
  • インジェクション系攻撃への防御の鉄則

    前回までは,主にクロスサイト・スクリプティングのぜい弱性とその対策について解説してきた。最終回となる今回は,クロスサイト・スクリプティング以外の「インジェクション系」ぜい弱性について解説する。具体的には,SQLインジェクション,OSコマンド・インジェクション,HTTPヘッダー・インジェクション,そしてメールの第三者中継である。 SQLインジェクション対策にはバインド変数の利用が最適 まず,SQLインジェクションから見ていこう。対策には二つの方法がある。一つは,SQLの「バインド変数(注1)」を使う方法である。バインド変数の書式はプログラミング言語によって異なるが,一例として,Perlを使った場合に,パスワード認証のSQLをバインド変数で書き換えた例を示す(図1)。 (注1) 「準備された文(Prepared Statement)」というのがJIS SQLでの用語だがあまり普及していない。バ

    インジェクション系攻撃への防御の鉄則
  • それ Unicode で

    UTF-7 を使ってスクリプトを記述 +ADw-SCRIPT+AD4-alert(\'XSS\');+ADw-+AC8-SCRIPT+AD4- IE は、文字エンコーディングが不明で UTF-7 っぽい文字列があれば、自動判別で UTF-7 となる。

  • まだまだあるクロスサイト・スクリプティング攻撃法

    前回はクロスサイト・スクリプティングのぜい弱性を突く攻撃の対策としてのHTMLエンコードの有効性を述べた。ただ,HTMLエンコードだけではクロスサイト・スクリプティング攻撃を完全に防御することはできない。そこで今回は,HTMLエンコードで対処できないタイプのクロスサイト・スクリプティング攻撃の手口と,その対策について解説する。 HTMLエンコードで対処できない攻撃には,次のようなものがある。 タグ文字の入力を許容している場合(Webメール,ブログなど) CSS(カスケーディング・スタイルシート)の入力を許容している場合(ブログなど) 文字コードを明示していないケースでUTF-7文字コードによるクロスサイト・スクリプティング <SCRIPT>の内容を動的に生成している場合 AタグなどのURLを動的に生成している場合注) 以下では,HTMLタグやCSSの入力を許容している場合と,文字コードを明

    まだまだあるクロスサイト・スクリプティング攻撃法
  • 対策遅らせるHTMLエンコーディングの「神話」

    クロスサイト・スクリプティングという言葉は元々,WebアプリケーションのHTMLエンコード漏れなどを利用することによって第三者にJavaScriptを実行させる手法を指す。広義では,HTMLのエンコードによる画面改変などを含むこともある。 前回述べたように,クロスサイト・スクリプティングのぜい弱性はWebアプリケーションに見付かるぜい弱性の半分以上を占める。数年前から指摘されているにもかかわらず,一向になくならない。その理由として,クロスサイト・スクリプティング対策あるいはHTMLエンコード注1)に対する「神話」があり,正しい対策の普及を遅らせているように思う。その「神話」の数々について説明しよう。 注1)実体参照(entity reference)というのが正式だが,あまり普及していない用語なので,HTMLエンコードという用語を用いる 「すべからくHTMLエンコードすべし」が鉄則 HTM

    対策遅らせるHTMLエンコーディングの「神話」
  • HTMLを許可しつつXSS対策を行えるPHPライブラリ「HTML Purifier」:phpspot開発日誌

    HTML Purifier - Filter your HTML the standards-compliant way! HTML Purifier is a standards-compliant HTML filter library written in PHP. HTMLを許可しつつXSS対策を行えるPHPライブラリ「HTML Purifier」。 HTMLをちゃんとパースして、XSSに関わる問題のあるタグなどは除去して返してくれます。 例えば、次のコードが(Before)、 phpspot <a href="hogehoge" onclick="alert('test1');">hogehoge</a> <script type="text/javascript"> <!-- alert("test2"); --> </script> 次のコードのようにクリーンになります。(A

  • Ywcafe.net

    Ywcafe.net This Page Is Under Construction - Coming Soon! Why am I seeing this 'Under Construction' page? Related Searches: Cheap Air Tickets Top Smart Phones fashion trends Healthy Weight Loss Health Insurance Trademark Free Notice Review our Privacy Policy Service Agreement Legal Notice Privacy Policy

  • 1