最近買った本 - teracc’s blog
Web Application Obfuscation: '-/WAFs..Evasion..Filters//alert(/Obfuscation/)-' 作者: Mario Heiderich,Eduardo Alberto Vela Nava,Gareth Heyes,David Lindsay出版社/メーカー: Syngress発売日: 2010/12/10メディア: ペーパーバック クリック: 105回この商品を含むブログ (1件) を見る sla.ckers.orgのXSS板とかでよく見る人たちが著者に名前を連ねています。 行きの電車の中で読んでますが、まだ40ページくらい。先は長いです。 体系的に学ぶ 安全なWebアプリケーションの作り方 脆弱性が生まれる原理と対策の実践 作者: 徳丸浩出版社/メーカー: SBクリエイティブ発売日: 2011/03/01メディア: 単行本購入
ASP.NETのセッション固定対策 - 2010-04-24 - T.Teradaの日記
本日は、ASP.NETでログイン機能をつくる際のセッション固定対策について書きます。 ログイン状態の管理には、ASP.NETが提供するセッション機構（ASP.NET_SessionId Cookie）を使っているとします。 ASP.NETでのセッション再生成 ログイン機能のセッション固定対策は、ログイン時に新たなセッションを開始することです。既存のセッションがなければ新たにセッションを開始し、既存のセッションがあるならばそのセッションは再生成されなければなりません。 しかし、ASP.NETはセッションを再生成する方法を提供していません。 それはJavaも同じなのですが、TomcatだとHttpSession#invalidateでセッションを無効化することで、セッションを再生成することができます*1。 ASP.NETでも普通に考えると、Session.Abandonという同等のメソッドを利
今更ながらmagic_quotes_gpcの欠点 - teracc’s blog
今更ながらですが、PHPのmagic_quotes_gpcをOnにすべきでない理由を整理してみます。 世の中には、magic_quotes_gpcはOffにすべき、と書いた文章は多数あるのですが、その理由を（私が見る限りで）十分に説明しているものは無いからです。 以下では、 1. 対象外の変数の存在 2. 弊害（副作用） 3. エスケープの不完全さ という三つの観点から記述します。 対象外の変数の存在 magic_quotes_gpcの、「gpc」はGET/POST/COOKIEを表しています。つまり、この3種類のリソースからの入力はエスケープされますが、それ以外は原則エスケープされません。 エスケープされているもの、されていないものを、以下にまとめてみます。 エスケープ済み ・$REQUEST $_GET・$_POST・$_COOKIE 場合によってエスケープ済み ・$_SESSION（
pg_sleepを使った検査 - teracc’s blog
徳丸さんの日記（pg_sleepをSQLインジェクション検査に応用する - ockeghem's blog）を読みました。 こういう検査のマニアックな話は大好きです。 このあたりのシグネチャは、私も自作ツール（参考）の検討をしていた際に相当いろいろ悩んで調べましたので、今回はUPDATE文のSET句などにも適用できるような改善の提案をしたいと思います（おろらく既に徳丸さんの頭にあるものだとは思いますが）。 徳丸さんの日記の検査パターンは、以下の値を挿入するものでした。 ' and cast( (select pg_sleep(3)) as varchar) = 'これを少し変えて、以下のようにします。 ＜文字列型＞ 【元の値】'||(select pg_sleep(3))||'数値型であれば、以下のようにします。 ＜数値型＞ 【元の値】-cast(chr(48)||(select pg_s
htmlspecialchars()/htmlentities()について - 2009-10-19 - T.Teradaの日記
id:t_komuraさんの、最新の PHP スナップショットでの htmlspecialchars()/htmlentities() の修正内容についてを読みました。 見ていて気になったことが１つあります。 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
MySQLのエラーメッセージ - 2009-07-03 - T.Teradaの日記
MySQL環境において、BlindではないSQLインジェクションがあるときに（SQLエラーメッセージが応答に含まれるときに）、欲しいデータをエラーメッセージから得る方法。 mysql> select extractvalue('<a/>',concat('/$',version())); ERROR 1105 (HY000): XPATH syntax error: '$5.1.36-log' こんな感じで使います。 ?vuln_var='-extractvalue('<a/>',concat('/$',version()))-'おそらく、MySQL5.1以上で動きます。 金床さんの本（ウェブアプリケーションセキュリティ）には、同じことをload_file関数を使ってやる方法が載ってますが、FILE権限が必要ですし、ちょっと前からその方法自体が使えなくなってます。 （参考）MySQL Bu
SQLのlike演算子でエスケープが必要な文字 - teracc’s blog
まとめると以下のようになると思います。 Oracle % _ ％(全角）＿(全角) DB2 % _ ％(全角）＿(全角) MS SQL Server % _ [ MySQL % _ PostgreSQL % _ 注意点は以下のとおり。 DB2、Oracleは、「％」「＿」（全角）もワイルドカードとして解釈する SQL Serverは、[a-z]のような正規表現的な記述を解釈する 当然、ワイルドカード的な機能を持たせたい「%」や「_」等はエスケープしない 全データベース共通の話として、エスケープ文字自体もエスケープする必要がある（MySQL、Postgresでは「\」がデフォルトのエスケープ文字） likeのエスケープをした後に、Prepared Statementで値をSQLにバインドする （関連）2008-07-10 - 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,'&').replace(/</g,'<'); </script> <!-- 3 --> <script> document.write('URL:'+u); </script> 上のページは静的なページで、DOM Based XSSの脆弱性もありません。ですが、被害者のユーザがIE8を使っている
IE8のtoStaticHTML関数 - 2009-06-21 - T.Teradaの日記
以前の日記で、IE8β2のtoStaticHTML関数にバグがあると書きました。 そのバグについては、発見したときにMSに報告しました。その後、特に「直した」という連絡はありませんが、IE8の正式版では修正されていました。 β2にあったバグのPOCは、以下のようなものです。 <body> <div id="foo"></div> <script> var tmp="<img style=\"color:expression(alert('; width:x'))\">"; document.getElementById('foo').innerHTML = toStaticHTML(tmp); </script> </body> ポイントは、alertのちょっとうしろに入れたセミコロンです。β2では、セミコロンが含まれていると、そこで1つの宣言が終わると解釈していました。かなり荒っぽい解釈
XMLをparseするアプリのセキュリティ - 2009-06-21 - T.Teradaの日記
「XML」「セキュリティ」という単語でWeb検索すると、多くヒットするのはXMLデジタル署名やXML暗号などを説明したWebページです。 本日の日記では、それとはちょっと違うテーマ（XXEと呼ばれる攻撃）について書きます。 脆弱なコードと攻撃方法 さっそく脆弱性があるサンプルプログラムです。 import java.io.*; import javax.servlet.*; import javax.servlet.http.*; import org.w3c.dom.*; import org.apache.xerces.parsers.*; import org.xml.sax.*; public class Test1 extends HttpServlet { public void service(HttpServletRequest request, HttpServletRe
DB2の文字列→数値変換 - teracc’s blog
だいぶ前に徳丸さんが、文字列から数値への暗黙の型変換についてまとめています。 数値リテラルをシングルクォートで囲むことの是非 - ockeghem's blog 徳丸さんの日記には、Oracle, MS SQL Server, MySQL, PostgreSQLの4つのDBMSを対象に、暗黙の型変換が起こるかを実際に調べた結果が書かれています。 私が思うところ、割とメジャーなDBMSで網羅されていないのはDB2です。 というわけで、今日の日記ではDB2の挙動について書きます。 下は、DB2 V9.5での動作です。 [db2inst1@localhost ~]$ db2 "SELECT * FROM staff WHERE id=10" ID NAME DEPT JOB YEARS SALARY COMM ------ --------- ------ ----- ------ ------
自作検査ツール - 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エラーにな
自作検査ツール - OSコマンドインジェクション編 - 2008-12-27 - T.Teradaの日記
OSコマンドインジェクションを許す欠陥を持つアプリケーションは非常に少ないです。最近のアプリケーションは特に、メールを送信するために直接sendmailコマンドを叩くようなことをしなくなってきており、欠陥を持つアプリは殆ど見られなくなっています。 また、OSコマンドインジェクションは、仮に脆弱性が存在したとしてもなかなかブラックボックスでの発見が難しい脆弱性です。脆弱性の発見が困難となる要因としては、コマンドの実行結果がレスポンスに含まれるとは限らない（例えばsendmailを実行してメールを送る場合）、OSコマンド内への挿入箇所が「'」や「"」で括られている場合がある――などが挙げられます。 脆弱性が存在する可能性が低く、また発見しづらい脆弱性であれば、無視してしまってもいいようなものですが、悪用された際の危険度が最大級の脆弱性であるために無視する訳にもいきません。何とも扱いづらい脆弱性
自動化されたSQL Injectionの攻撃対象 - teracc’s blog
WASCのWeb Security MLの少し前の投稿より。 Tactical Web Application Security: Mass SQL Injection Attacks Now Targeting PHP Sites 自動化されたSQL Injection攻撃が、現在はPHPサイトをターゲットにしているとの内容の記事です。 確かに、SQL Injectionによって埋め込まれるJSファイルのURLをキーワードにしてGoogle検索すると、拡張子がphpのページもヒットします。 "1000mg.cn/csrss/w.js" - Google Search 個人的に一番気がかりなのは、これまで狙われていたSQL Server以外のデータベースが新たに攻撃対象になっているのか（あるいはそうではないのか）ということです。 そこにも関わりそうな話なので、可能な範囲で調べてみました。
JavaScript Hijack/JSON Hijackのぜい弱性
今回で，ratproxyで検出できる特徴的なぜい弱性の解説は終わりです。最終回となる今回は，JavaScript Hijackについてです。JavaScript Hijack，そしてJSON Hijackは，JavaScriptファイルやJSONデータ内に含まれる情報を盗む攻撃です。ratproxyは，この攻撃を成立させてしまうぜい弱性を見付けやすくなっています。 JavaScript Hijack まず最初にJavaScript Hijackについて説明しましょう。JavaScript Hijack攻撃にぜい弱になるのは，個人情報などの機密情報を内容として含むJavaScriptファイルを動的に生成しているアプリケーションです。筆者が過去の検査で実際に見たケースには，以下のようなものがありました。 （index.htmlの一部） <script src="greeting.cgi"></
JavaScriptスクリプトに潜むXSSのぜい弱性も検出
今回は，ratproxyが検出する特徴的なぜい弱性として，JavaScript関数に関するものを紹介しましょう。DOM（document object model）の仕組みを使ったクロスサイト・スクリプティング（XSS）のぜい弱性（DOM Based XSS）です。 DOM Based XSSは，XSSの中では比較的新しいタイプのぜい弱性で，業界団体のサイトなどで紹介されています。ここでは詳細な説明は割愛しますが，簡単に言うと，Webサーバーを経由させずに標的ユーザーのブラウザ上で悪意あるスクリプトを実行させられるぜい弱性です。 ぜい弱性のある簡単なサンプルJavaScriptコードを以下に示します。これは，かつてBugzillaで発見されたぜい弱性です。 このコードでは，locationがそのまま（エスケープされずに）HTMLに出力されています。そのため，locationに「<scrip
検出できるぜい弱性は42種類，SQLインジェクションは苦手
前回，ratproxyは受動的なぜい弱性検査ツールだと紹介しました。では，ratproxyを使ってどのようなぜい弱性を検出できるのでしょうか。これは，ratproxyがぜい弱性を検出した際にレポートに出力するメッセージから分かります。このメッセージは42種類あって，ダウンロードしたratproxyのファイル群の一つ，messages.listファイルに記載されています。42種類のメッセージの中には「Adobe Flashファイルの一覧」のような単なるINFOレベルのメッセージも含まれていますが，基本的に42種類のぜい弱性を検出できると考えて良いでしょう。 42種類の多くはクロスサイト・スクリプティング このうち，主要なものを大まかに分類すると，次のようになります。 （1）Content-TypeやCharset指定の誤り（XSSの危険性） （2）write()などのJavaScript関数
2008-08-06 - T.Teradaの日記 - HTTP用のページにHTTPSでアクセスする
同一ホスト上にHTTPとHTTPSのページが同居しているサイトをしばしばみます。 そんなサイトでは、本来はHTTPのページに、HTTPSでもアクセスできるようになっていることがあります。そういう場合、HTMLの中身によってはセキュリティ上の問題が出ますよという話です。 問題があるページ http://www.example.jp/index.html というURLのページがあるとします。 問題となるのは、そのページの中身に以下のようなHTMLがベタ書きされている場合です。 <script src="http://www2.example.jp/foo.js"></script> このページ（index.html）はHTTPでのアクセスを想定して作られているため、JSファイルをHTTPで読み込んでいます。 ここで、このページが実はHTTPSでもアクセス可能だとします。もしHTTPSでアクセス
[セキュリティ]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の日記](https://cdn-ak-scissors.b.st-hatena.com/image/square/3ce21f422dafba32f7c257ef3ed09227bfdd2c5e/height=288;version=1;width=512/https%3A%2F%2Fogimage.blog.st-hatena.com%2F10257846132711010800%2F10257846132711092219%2F1548045373)
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ITProに記事を書きました - teracc’s blog
