Scrawlrを試す - teracc’s blog
http://www.microsoft.com/japan/technet/security/advisory/954462.mspx MSが、SQL Injection対策ツールを3つほど紹介しています。 そのうち、Scrawlrを試してみました。 Technical details for Scrawlr * Identify Verbose SQL Injection vulnerabilities in URL parameters * Can be configured to use a Proxy to access the web site * Will identify the type of SQL server in use * Will extract table names (verbose only) to guarantee no false positive
[その他]フォーマット制御文字 - 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の日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/2d9bb2ae5f6c6f018decdbb90d46c4ce47c42dde/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F10257846132711010800%2F10257846132711092503%2F1548045400)
preg_replaceによるコード実行 - T.Teradaの日記
最近少し調べていたのが、PHPの任意コード実行系の脆弱性です。中でも、preg_replace関数（Perl互換の正規表現による置換を行なうための関数）を不適切な方法で使った場合に発生する脆弱性について調べていました。 せっかくなので、日記にまとめてみます。 3種類の脆弱性 preg_replace関数を使ったPHPコード実行系の脆弱性には、大きく分けて3つの種類があります。 第一引数への挿入を許す e修飾子付き・第二引数への挿入を許す e修飾子付き・第三引数への挿入を許す 以下でそれぞれについて見ていきます。 タイプ１：第一引数への挿入 以下のコードに、任意のPHPコードが実行可能な脆弱性があります。 $m = preg_replace("/([^<]*)$kw([^>]*)/i", "\\1<font color=red>$kw</font>\\2", $m); $kwと$mは外部から
Piece Frameworkを試した - teracc’s blog
Piece FrameworkはPHPのフレームワークです。 セキュリティに強い、そして日本人が開発している、というのが特徴のようです。 【PHPウォッチ】第34回 セキュアでロバストなPHPフレームワーク「Piece Framework」：ITPro Piece Framework - A stateful and secure web application framework for PHP 早速触ってみました。 概要 以下の3つの要素から構成されます。 Piece_Unity: 基本 Piece_Right: Validation Piece_Flow: フロー制御 一番の売りは、フロー制御のようです。これを使うと、Webアプリ開発者が意識せずとも、CSRF脆弱性を持たないフォームを作れます。 デモサイトでフロー制御を体験 デモサイトが用意されています。 Piece Framewo
]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の日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/f1f73d68b2028ddb7e86850fc884fc4031e279d8/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F10257846132711010800%2F10257846132711092818%2F1548045430)
セッションを使ったフォーム処理にありがちな問題点 - T.Teradaの日記
入力画面が複数に渡るフォームで、ユーザが各画面で入力したデータを、hiddenによって引き回すのではなく、セッション変数（セッションIDにヒモ付いてサーバ側に格納される情報）に一時保存するタイプのWebアプリケーションが増えているように思います。 フォーム処理でセッションが使われるのは、「実装をシンプルにしたい」「携帯サイトなどで通信量を減らしたい」といった理由のほかに、「アプリケーションをセキュアにしたい（hiddenだと改竄される）」という理由があるのではないかと思います。 しかし、セキュリティ上の問題は、セッションを使ったフォーム処理においてもしばしば見つかります。 以下では、セッションを使ったフォーム処理で、割と多く見つかる問題について書きます。 画面遷移の不正 ある会員制サイトの、会員登録フォームを会話風に書いてみます。 会員登録の際には、氏名、生年月日、住所の3つを登録します。
Mac World Expoのチケットが無料に - teracc’s blog
今年もプラチナチケット（$1,895）が無料で購入できる欠陥があったそうです。 Superimposing Nothing Nowhere: Another Free MacWorld Platinum Pass? Yes in 2008! どんな方法で無料で買えたのかと言うと。。。 Apple（もしくはExpo主催者のIDG）は、チケットを無料（もしくは割引）で購入するための「Priority Code」と呼ばれるパスワードみたいなものを、上客の人達に郵送 or Eメールで配った。 Webサイト上の購入ページで、「Priority Code」を入力すると、無料（もしくは割引）で購入できるようになっていた。 ユーザが入力した「Priority Code」が正しいかをJavaScriptで検証できるように、発行した「Priority Code」の全て（1500個ほど）のMD5ハッシュをWeb
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として不正な
PHPでの入力値チェックのすり抜け - T.Teradaの日記
Webアプリケーションでは、外部からの変数に対して、形式チェック（Validation）を行ないます。PHPでこれを行なう場合に、ありがちなミスをいくつか挙げてみました。 この日記は、がるさんの日記に触発されて書いたもので、いくつかの例を引用しています。 がるの健忘録(2006/11/08) - 素晴らしき自動的な世界〜或いは「型のない」世界〜 型の問題 数値と文字列の比較 <?php $input = "2'; DELETE FROM hoge; --"; if ($input == 2) { // ↑TRUEと評価される がるさんの日記で紹介されていた例に、手を加えたものです。 if文中の式がTRUEになるのは、PHPの「==」演算子が、数値型と文字列型変数を比較する際に、文字列を（かなり強引なやり方で）数値型に変換するからです。変数の比較は、同じ型同士で行なうのが無難だと思います。
SQL Injectionツール - teracc’s blog
ここのところ、いくつかのSQL Injectionツールについて調べていました。今日はその結果を日記に書いてみようと思います。 はじめに SQL Injectionツールとは SQL Injection脆弱性の発見と、発見した脆弱性を突いてのDB内情報の取得を行なうためのツールです。 ただし、多くのツールでは「脆弱性の発見」はおまけで、後者のDB内情報の取得に主眼を置いています。一般的には、汎用のWeb脆弱性スキャナなどで脆弱性を見つけて、その脆弱性に対してこの日記に書いているようなツールを使って情報を取得するという使い方をすることが多いでしょう。 SQL Injectionツールは、いわゆるHackingツールです。脆弱性検査を行なう者か、さもなければCrackingを行なう犯罪者が使うくらいで、一般のWeb開発者やユーザの人が使う必要に迫られることは無いでしょう。 ツールの使用に際して
入力値検証の話 - T.Teradaの日記 - 2007-09-08
Webアプリケーションのセキュリティ対策としての入力値検証について議論されています。 そろそろ入力値検証に関して一言いっとくか: Webアプリケーション脆弱性対策としての入力値検証について - 徳丸浩の日記(2007-09-05) 思ったことをいくつか書きます。 徳丸さんの日記は、ユーザがテキストボックスなどで自由に値を入力できる住所などのデータを主に対象としたものだと思う。 ただ、ユーザの自由な入力を起源としないデータも存在する（ここでは「システム起源のデータ」と呼ぶ）。 hidden、リンクURLに埋め込まれているGETパラメータ、Cookieなどには、この手のデータが入ることが多い。 システム起源のデータの多くは、ある型に従うことが期待されるもので、原則的に入力値検証をすべきもの（BMPの「ピクセルあたりビット数」と同じような感覚）。 システム起源のデータも、エスケープさえすればイン
[セキュリティ]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の日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/74e9aa9f9e6621a9d728a9460cede25902d1fbda/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F10257846132711010800%2F10257846132711094607%2F1548045577)
価格の改竄などの話 - teracc’s blog
ECサイトにおける価格の改竄の対策として、「購入確定処理で、クライアントからPOSTされてくる商品IDをキーに商品マスタテーブルを検索して、検索した結果の価格で購入処理を行なう」というような趣旨の対策が書いてあるのを見たことがあります。 これは悪意あるユーザによる価格改竄の対策として正しいわけですが、私は別の問題で少々引っかかるものを感じてしまいます。 私が「引っかかるところ」について、以下で少し書いてみます。 運営者による価格変更 購入確定処理の直前には、購入確認画面がユーザに提示されているはずです。 ┏━━━━━━━━━━┓ ┃ ＜購入確認画面＞ ┃ ┃ ┃ ┃ みかん 1個 100円 ┃ ┃ ---------------- ┃ ┃ 合計 100円 ┃ ┃ ┃ ┃上記を購入しますか？┃ ┃ ┃ ┃ [購入確定] [戻る] ┃ ┗━
[セキュリティ]画像へのPHPコマンド挿入 ― T.Teradaの日記
だいぶ時間がたってしまいましたが、大垣さんの以下のブログにコメントしたことなどをまとめます。 画像ファイルにPHPコードを埋め込む攻撃は既知の問題 – yohgaki's blog アップロード画像を利用した攻撃についてです。 攻撃の概要 画像ファイルにPHPコマンドを挿入する攻撃は、大きく2種類に分けることができます。 1つは、画像のアップロード機能を持つサイト自身を狙う攻撃です。PHPで開発されており、任意の拡張子のファイルのアップロードを許すサイトでは、拡張子がphpなどのファイルをアップロードされる恐れがあります。 拡張子がphpなどのファイルに仕込まれたPHPコマンドは、そのファイルにHTTP/HTTPSでアクセスされた際に実行されます。攻撃者は、アップロードファイルを通じて、画像が置かれるWebサーバ上で任意のコマンドを実行することできます。 この脆弱性は、アップロード可能なフ
T.Teradaの日記 HTML Purifierを試した
Webメールでは、受信したHTMLメールのタグを残して、クライアントサイドスクリプト（JavaScriptなど）のみを除去するサニタイズ処理を行ないます。 このようなスクリプト除去処理は、Blog、掲示板などでも行なわれる、比較的ポピュラーなものであるため、それ用のライブラリがいくつか存在します*1。 HTML Purifierもその一つです。PHP4/5で動作します。バージョン1.0.0のリリースは2006年9月ですから、比較的新しいものです。私は昨年末に初めて触ってみました（バージョン1.3.2です）。 これまでのものと比べて、非常によく出来ているなと思いましたので、日記に書いてみます。 HTML Purifierの概要 特徴としては、以下が挙げられると思います。 ユニコード対応 UTF-8のHTMLに対応（既存のライブラリの多くはlatin1を暗黙の前提としていました）。EUC-JP
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
2008-02-27 - T.Teradaの日記 [セキュリティ]Burpの更新＆文字化けの話![2008-02-27 - T.Teradaの日記 [セキュリティ]Burpの更新＆文字化けの話](https://cdn-ak-scissors.b.st-hatena.com/image/square/04d2ebbacad05f97bcf52ae0bdbfc1327372d8db/height=288;version=1;width=512/https%3A%2F%2Fcdn-ak.f.st-hatena.com%2Fimages%2Ffotolife%2Ft%2Fteracc%2F20080228%2F20080228004221.gif)
