タグ

ブックマーク / blog.ts5.me (22)

  • マッチするはずの正規表現がマッチしない現象 - T.Teradaの日記

    今日は、PHPでよく使用される正規表現エンジンであるPCRE(Perl Compatible Regular Expression)の、余り知られていない(と思う)制約について書きます。 プログラム 題材は下のPHPプログラムです。 <?php header('Content-Type: text/html; charset=latin1'); $url = $_REQUEST['url']; if (preg_match('/^(.*?):/s', $url, $match)) { $scheme = $match[1]; if ($scheme !== 'http' && $scheme !== 'https') { exit; } } echo '<a href="'. htmlspecialchars($url). '">link</a>'; 外部から受け取った「url」パラメータ

    マッチするはずの正規表現がマッチしない現象 - T.Teradaの日記
    TAKESAKO
    TAKESAKO 2010/04/13
    マッチするはずの正規表現がマッチしない現象 - PHPでよく使用される正規表現エンジンであるPCRE
  • htmlspecialchars()/htmlentities()について - 2009-10-19 - T.Teradaの日記

    id:t_komuraさんの、最新の PHP スナップショットでの htmlspecialchars()/htmlentities() の修正内容についてを読みました。 見ていて気になったことが1つあります。 2. EUC-JP …(省略)… (2) \x80 - \x8d, \x90 - \xa0, \xff については、そのまま出力される <?php var_dump( bin2hex( htmlspecialchars( "\x80", ENT_QUOTES, "EUC-JP" ) ) ); var_dump( bin2hex( htmlspecialchars( "\x8d", ENT_QUOTES, "EUC-JP" ) ) ); var_dump( bin2hex( htmlspecialchars( "\x90", ENT_QUOTES, "EUC-JP" ) ) ); va

    htmlspecialchars()/htmlentities()について - 2009-10-19 - T.Teradaの日記
  • IE8のXSSフィルタが裏目に出る例 - 2009-06-22 - T.Teradaの日記

    IE8のXSSフィルタは、WebアプリにXSS脆弱性があったとしても、それが発動する可能性を減らしてくれるものです。 しかし、そのXSSフィルタが裏目に出るようなこともあります。 例えば、以下のような静的なHTMLファイル(test.html)を作ってWebサーバにおきます。 <h3>ie8 test</h3> <!-- 1 --> <script> var u=document.URL; </script> <!-- 2 --> <script> u=u.replace(/&/g,'&amp;').replace(/</g,'&lt;'); </script> <!-- 3 --> <script> document.write('URL:'+u); </script> 上のページは静的なページで、DOM Based XSSの脆弱性もありません。ですが、被害者のユーザがIE8を使っている

    IE8のXSSフィルタが裏目に出る例 - 2009-06-22 - T.Teradaの日記
  • 自作検査ツール - SQLインジェクション編 - 2009-05-31 - T.Teradaの日記

    前回の日記からだいぶ日にちが空いてしまいました。 今日は、自作検査ツールのSQLインジェクション用シグネチャについて書きます。 SQLインジェクションの検査シグネチャとしては、以下の5種類を用意しています。 A. SQLエラー検出+簡易なBlind B. Blind 数値型・カラム名等 C. Blind 文字列型 D. 更新系クエリ E. 文字コード系 SQLインジェクションは、かなりの頻度で脆弱性が発見されること、また一般的に危険度の高い脆弱性であることから、シグネチャの種類を多くしています。 それぞれのシグネチャについて、以下で順番に見ていきます。 A. SQLエラー検出+簡易なBlind 最初に試すのはベーシックなパターンです。 イ:【元の値】'"\'"\ … SQLエラーになる ロ:【元の値】''""\\ … SQLエラーにならない ハ:【元の値】'"\'"\ … SQLエラーにな

    自作検査ツール - SQLインジェクション編 - 2009-05-31 - T.Teradaの日記
  • 自作検査ツール - XSS編 - 2009-01-31 - T.Teradaの日記

    ちょっと時間があいてしまいましたが、自作ツールのXSS検査について書きます。 XSSシグネチャ 検査文字列は基的には2種類のみです。 □タイプA XXXXXX【元の値】'"<9 :&(;\qYYYYYY □タイプB XXXXXX【元の値】'":&(;\qYYYYYY ※ XXXXXX、YYYYYYはランダムな英数文字列ツールは、これらの文字列をパラメータとして与えて、HTMLのどのような文脈に出力されるのか(何らかの属性の値なのか、あるいはSCRIPTタグの内側かなど)、そして出力の際にどのようなエンコードやフィルタが施されるのかを調べて、脆弱性が存在する可能性を調べていきます。 例えば、パラメータ値が「'」や「"」で括られていない属性値に出力されるとします。 <INPUT type="text" name="foo" value=【ここに出る】>この場合、(正確に言うと一部例外はありま

    自作検査ツール - XSS編 - 2009-01-31 - T.Teradaの日記
  • [セキュリティ]javascript://のXSS 00:17 - 2008-07-30 - T.Teradaの日記

    こんな場合、普通はjavascriptやdataスキームなどを使ってXSSさせるのでしょう。 <a href="ここにHTMLエンコードされて入る">link</a> しかし、このアプリは「javascript://...」のように、先頭からアルファベット数文字が続き、その直後に「://」が付いている値以外は、エラーではじいてしまいます。 この「:」のあとの「//」が曲者です。 dataスキーマを試してみましたが、「//」があるとどうやらダメらしいということで、javascriptスキームで頑張ってみます。 まずはこんな感じです。 <a href="javascript://hoge[0x0A]alert(111)">link</a> 「//」が行コメントの開始になるため、[0x0A](LF)や[0x0D][0x0A](CRLF)を入れてみて、その後に動かしたいJavaScriptコードを

    [セキュリティ]javascript://のXSS 00:17 - 2008-07-30 - T.Teradaの日記
    TAKESAKO
    TAKESAKO 2008/07/31
    【a href="javascript://hoge[0xE2][0x80][0xA8]alert(111)" JavaScriptコード内のU+2028(あるいはU+2029)を、Firefoxが改行文字と認識することを利用しています】
  • 2008-07-10 - T.Teradaの日記 - SQLのLIKE演算子のエスケープ

    例えば、「\%foo」から始まる文字列を検索する場合には、どのようなSQL文を書けばよいのでしょうか。 条件は以下の通りです。 DBMSソフトはMySQL ESCAPE節は使わない MySQLでESCAPE節を使わない場合、ワイルドカード文字(「%」や「_」)は「\」でエスケープすることになります。 間違った答え 直感的に以下のようなSQL文を書いてしまう人もいると思います。 SELECT * FROM table1 WHERE hoge LIKE '\\\%foo%'; 実際に試して見ます。 mysql> SELECT 123 FROM dual WHERE '\\%foo456' LIKE '\\\%foo%'; +-----+ | 123 | +-----+ | 123 | +-----+ 1 row in set (0.00 sec) mysql> SELECT 123 FROM

    2008-07-10 - T.Teradaの日記 - SQLのLIKE演算子のエスケープ
  • ページの閲覧履歴 - teracc’s blog

    有害なエントリーを書いてしまい申し訳ありませんでした | 松下健次郎のブログ この問題(CSS History Hack)への対策として作られたFirefoxのAddonがあります。 https://addons.mozilla.org/ja/firefox/addon/1502 https://addons.mozilla.org/ja/firefox/addon/1474 SafeHistoryは当時(2006年ごろ)と今インストールして使ってみましたが、問題なく動きました(余りちゃんと調べてませんが)。SafeCacheの方は使ったことはありません。 なお、SafeCacheは正確には別の種類の攻撃(HistoryではなくCacheに対する攻撃)に対処するものです。 <参考> History関連:147777 - :visited support allows queries int

    ページの閲覧履歴 - teracc’s blog
    TAKESAKO
    TAKESAKO 2008/06/29
    【特定の外部サイト(ページ)の閲覧履歴がJavaScriptで取得できてしまう件、 この問題(CSS History Hack)への対策として作られたFirefoxのAddonがあります。】
  • [その他]フォーマット制御文字 - 2008-06-23 - T.Teradaの日記

    ECMA-262 3rd Edition(和訳)を見ていたら、7章にこんなことが書いてあるのを見つけました。 フォーマット制御文字は ECMAScript プログラムのソーステキストのどの場所に出現してもよい。これらの文字は、字句文法を適用する前にソーステキストから取り除かれる。文字列と正規表現リテラルの処理前にこれらの文字が取り除かれるので、文字列、正規表現内に Unicode 制御文字を入れるには Unicode エスケープシーケンス (セクション 7.6) を使用しなければならない。 This Document has Moved ざっとCfカテゴリ(プロパティ)の文字で調べてみると、IEでは無視される(取り除かれる)ことはありませんでしたが、Firefox2では以下の文字が無視されました。 U+200C: ZERO WIDTH NON-JOINER U+200D: ZERO WID

    [その他]フォーマット制御文字 - 2008-06-23 - T.Teradaの日記
  • preg_replaceによるコード実行 - T.Teradaの日記

    最近少し調べていたのが、PHPの任意コード実行系の脆弱性です。中でも、preg_replace関数(Perl互換の正規表現による置換を行なうための関数)を不適切な方法で使った場合に発生する脆弱性について調べていました。 せっかくなので、日記にまとめてみます。 3種類の脆弱性 preg_replace関数を使ったPHPコード実行系の脆弱性には、大きく分けて3つの種類があります。 第一引数への挿入を許す e修飾子付き・第二引数への挿入を許す e修飾子付き・第三引数への挿入を許す 以下でそれぞれについて見ていきます。 タイプ1:第一引数への挿入 以下のコードに、任意のPHPコードが実行可能な脆弱性があります。 $m = preg_replace("/([^<]*)$kw([^>]*)/i", "\\1<font color=red>$kw</font>\\2", $m); $kwと$mは外部から

    preg_replaceによるコード実行 - T.Teradaの日記
    TAKESAKO
    TAKESAKO 2008/06/07
  • ]SQLインジェクションによるサイト改竄 2008-03-20 - T.Teradaの日記

    今月に入り、SQLインジェクションによるサイト改竄被害が、広範囲で発生しているようです(参考:LACの注意喚起)。 この攻撃で使われた手法に関する詳細な情報が、以下のページに載っていました。 http://blogs.technet.com/neilcar/archive/2008/03/15/anatomy-of-a-sql-injection-incident-part-2-meat.aspx 非常におおざっぱに言うと、以下のような感じです。 リクエストを送ってみて、SQLインジェクション脆弱性があるか調べる。 脆弱性がある場合、それを突いて、全テーブルの、全カラムの、全レコードの値を改竄する*1。具体的には、DB格納値の末尾に「<script src=http://www.211796...(省略)」のような攻撃コードを追加する。 DBのデータをエスケープせずにHTMLに出力している

    ]SQLインジェクションによるサイト改竄 2008-03-20 - T.Teradaの日記
  • セッションを使ったフォーム処理にありがちな問題点 - T.Teradaの日記

    入力画面が複数に渡るフォームで、ユーザが各画面で入力したデータを、hiddenによって引き回すのではなく、セッション変数(セッションIDにヒモ付いてサーバ側に格納される情報)に一時保存するタイプのWebアプリケーションが増えているように思います。 フォーム処理でセッションが使われるのは、「実装をシンプルにしたい」「携帯サイトなどで通信量を減らしたい」といった理由のほかに、「アプリケーションをセキュアにしたい(hiddenだと改竄される)」という理由があるのではないかと思います。 しかし、セキュリティ上の問題は、セッションを使ったフォーム処理においてもしばしば見つかります。 以下では、セッションを使ったフォーム処理で、割と多く見つかる問題について書きます。 画面遷移の不正 ある会員制サイトの、会員登録フォームを会話風に書いてみます。 会員登録の際には、氏名、生年月日、住所の3つを登録します。

    セッションを使ったフォーム処理にありがちな問題点 - T.Teradaの日記
  • Oracleでのエスケープ - 2007-12-30 - T.Teradaの日記

    今日の日記では、OracleでのSQLインジェクション対策について書きます。 以下のようなコード(PHP)があるとします。 <?php ... $foo_escape = str_replace("'", "''", $foo); $sql = "SELECT * FROM table1 WHERE foo='$foo_escape'"; $stmt = OCIParse($dbh, $sql); ... 「'」を「''」にエスケープしてSQL文に埋め込み、Oracleで実行(Parse)しています。 割とよくあるコードかもしれませんが、これだとSQLインジェクション攻撃に脆弱な場合があります。 不正な文字列 DBサーバとのコネクションにEUC-JP(JA16EUCTILDE)を使用しているとします。 ここで、$fooに「[0xA1]' OR 1=1--」のような、EUC-JPとして不正な

    Oracleでのエスケープ - 2007-12-30 - T.Teradaの日記
  • PHPでの入力値チェックのすり抜け - T.Teradaの日記

    Webアプリケーションでは、外部からの変数に対して、形式チェック(Validation)を行ないます。PHPでこれを行なう場合に、ありがちなミスをいくつか挙げてみました。 この日記は、がるさんの日記に触発されて書いたもので、いくつかの例を引用しています。 がるの健忘録(2006/11/08) - 素晴らしき自動的な世界〜或いは「型のない」世界〜 型の問題 数値と文字列の比較 <?php $input = "2'; DELETE FROM hoge; --"; if ($input == 2) { // ↑TRUEと評価される がるさんの日記で紹介されていた例に、手を加えたものです。 if文中の式がTRUEになるのは、PHPの「==」演算子が、数値型と文字列型変数を比較する際に、文字列を(かなり強引なやり方で)数値型に変換するからです。変数の比較は、同じ型同士で行なうのが無難だと思います。

    PHPでの入力値チェックのすり抜け - T.Teradaの日記
    TAKESAKO
    TAKESAKO 2007/12/10
    PHPでの入力値チェックのすり抜けについて
  • SQL Injectionツール - teracc’s blog

    ここのところ、いくつかのSQL Injectionツールについて調べていました。今日はその結果を日記に書いてみようと思います。 はじめに SQL Injectionツールとは SQL Injection脆弱性の発見と、発見した脆弱性を突いてのDB内情報の取得を行なうためのツールです。 ただし、多くのツールでは「脆弱性の発見」はおまけで、後者のDB内情報の取得に主眼を置いています。一般的には、汎用のWeb脆弱性スキャナなどで脆弱性を見つけて、その脆弱性に対してこの日記に書いているようなツールを使って情報を取得するという使い方をすることが多いでしょう。 SQL Injectionツールは、いわゆるHackingツールです。脆弱性検査を行なう者か、さもなければCrackingを行なう犯罪者が使うくらいで、一般のWeb開発者やユーザの人が使う必要に迫られることは無いでしょう。 ツールの使用に際して

    SQL Injectionツール - teracc’s blog
  • 入力値検証の話 - T.Teradaの日記 - 2007-09-08

    Webアプリケーションのセキュリティ対策としての入力値検証について議論されています。 そろそろ入力値検証に関して一言いっとくか: Webアプリケーション脆弱性対策としての入力値検証について - 徳丸浩の日記(2007-09-05) 思ったことをいくつか書きます。 徳丸さんの日記は、ユーザがテキストボックスなどで自由に値を入力できる住所などのデータを主に対象としたものだと思う。 ただ、ユーザの自由な入力を起源としないデータも存在する(ここでは「システム起源のデータ」と呼ぶ)。 hidden、リンクURLに埋め込まれているGETパラメータ、Cookieなどには、この手のデータが入ることが多い。 システム起源のデータの多くは、ある型に従うことが期待されるもので、原則的に入力値検証をすべきもの(BMPの「ピクセルあたりビット数」と同じような感覚)。 システム起源のデータも、エスケープさえすればイン

    入力値検証の話 - T.Teradaの日記 - 2007-09-08
  • Security Restriction - teracc’s blog

    WASCのWeb Security MLで、「Security Restriction」(以降SRと略します)という新しいセキュリティ機構の案が提示され、議論されています。 The websecurity August 2007 Archive by thread この方(Agarwal氏)のメールはいつも見づらいのですが、その辺は置いておいて、以下に内容を抜粋します。 I am looking to get views from people on the list about a proposed security restriction in the browsers. The browser should check with the webserver which domains it can interact with (load files from or submit po

    Security Restriction - teracc’s blog
    TAKESAKO
    TAKESAKO 2007/08/15
    「Security Restriction」と「Content Restriction」
  • [セキュリティ]ImageFight2 - T.Teradaの日記

    先日の日記を見て頂いたようで、id:TAKESAKOさんがmod_imagefightをアップデートされていました。 ソースを見ると、height/widthがそれぞれ最大6000pixelに変更されていました。 むむむ・・・これは厳しい(今日は完全に攻撃者の視点になってます)。 しつこく試してみる 前回の日記で書いた攻撃方法のうち、最も攻撃コードが短いのは、<xmp>のパターンでした(これでも5Byteあります)。今のところ、これより短いものは思いつきません。 height/widthの制限が加わったことで、height/widthそれぞれ1Byte強しか使えない事になり、5Byteには全然足りません。 しかし、IHDRには他にも攻撃に使える部分が残されています。 攻撃PNGファイルの構造 IHDRチャンクを以下のようにします。 チャンク名称49 48 44 52I H D R イメージ

    [セキュリティ]ImageFight2 - T.Teradaの日記
    TAKESAKO
    TAKESAKO 2007/08/12
    すばらしいです。CRC32を現実的に利用できるとは思っていませんでした。とりあえずmod_imagefight.cにadhocな修正を追加してバージョンアップしました
  • [セキュリティ]ImageFight - T.Teradaの日記

    画像を用いたXSSとRFI対策のためのApache Moduleが出たようです。 LL魂お疲れ様でした[LLSpirit] | TAKESAKO @ Yet another Cybozu Labs もう夜遅いので、気づいた事を少しだけ書きます。 とりあえずは、PNGのXSS対策の部分についてだけ。 このプログラムは、IHDR領域の後にコメントを挿入する。 攻撃者は、IHDRのwidth/heightの合計8Byteに攻撃コードを挿入可能。 8Byte内に、xmpやtitleなどの開始タグを入れておけば、plaintextタグの効力を無効にできる。PLTEにxmpなどの終了タグとscriptタグを挿入することで攻略可能。 あるいは、8Byte内に「<a id=`」などを入れることで、コメントを属性値内に押し込めることができる(バッククォートを使っている)。 徳丸さんが日記で書いているように、

    [セキュリティ]ImageFight - T.Teradaの日記
    TAKESAKO
    TAKESAKO 2007/08/09
    ありがとうございます。次バージョンで実装する予定ですがIHDRのwidth/heightについては画像のサイズ制限を設けることで対策可能と考えています/↑一般のWebプログラマが安易なサニタイズに走るのは良くないと考えています
  • [セキュリティ]画像へのPHPコマンド挿入 ― T.Teradaの日記

    だいぶ時間がたってしまいましたが、大垣さんの以下のブログにコメントしたことなどをまとめます。 画像ファイルにPHPコードを埋め込む攻撃は既知の問題 – yohgaki's blog アップロード画像を利用した攻撃についてです。 攻撃の概要 画像ファイルにPHPコマンドを挿入する攻撃は、大きく2種類に分けることができます。 1つは、画像のアップロード機能を持つサイト自身を狙う攻撃です。PHPで開発されており、任意の拡張子のファイルのアップロードを許すサイトでは、拡張子がphpなどのファイルをアップロードされる恐れがあります。 拡張子がphpなどのファイルに仕込まれたPHPコマンドは、そのファイルにHTTP/HTTPSでアクセスされた際に実行されます。攻撃者は、アップロードファイルを通じて、画像が置かれるWebサーバ上で任意のコマンドを実行することできます。 この脆弱性は、アップロード可能なフ

    TAKESAKO
    TAKESAKO 2007/07/16
    詳しくは今度のセキュリティもみじで(ry