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
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
自作検査ツール - 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)
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
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つを登録します。
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
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)
