日本のセキュリティチーム (Japan Security Team) : Web アプリケーション

IIS & ASP 向け検査・対策ツールを公開

JSECTEAM — Wed, 25 Jun 2008 04:43:00 GMT

小野寺です。

ニュースとしては、比較的下火になっているかもしれない、SQL インジェクションの対策が済んでいないサイトが、まだまだ、残っています。しかし、実際に対策を進めてみると「検査方法が分からない」「開発元がもうすでに・・・」「色々有ってコードが変更できない」といった様々なフィードバックというか悩みがでてきます。

現在のSQL インジェクションの問題の怖いところは、侵害されたサイトが、そのサイトの利用者にも被害を伝播させるところです。そして利用者側で自衛するのは大変難しいと言えます。現在発見されている多くのパターンは、セキュリティ更新を適用しておけば被害を受ける可能性は低くなりますが、ゼロではありません。
将来、もしも未知の脆弱性が発見された場合、この多数のSQL インジェクションに耐性のないサイト群が犯罪者にとって都合のよい犯罪のプラットフォームになってしまう事も考えられます。

ということで、少なくとも先ずは、自分のところから何とかしようということになりまして、Internet Information Services (IIS) と ASP の対策・検査ツールを新たに提供することにしました。 (前置きが長かったです。)

1. Microsoft Source Code Analyzer for SQL Injection (SQLインジェクションに関するソースコード分析ツール)
このツールは、ASP のソースコードを静的に分析して、SQL インジェクションの原因となるような未検証の外部入力や、外部入力を直接使った SQL コマンド/ステートメントの構築等々を検出します。
ツールでは、以下の6種類の点について検査し、警告を出力します。

80400 – Possible SQL Injection vulnerability through data that is read from the Request object without any input validation. These warnings are very likely bugs that must be fixed.
80406 – Possible SQL Injection vulnerability through data that is read from the Request object where the input is passed through some unknown function calls that might perform data validation. If there is no data validation done inside the function call, then these are likely bugs else these are likely false positives.
80403 – Possible SQL Injection vulnerability through data that comes from a backend server. If the data is controlled by an end user through some other web page then these are likely bugs. But if the data is well trusted then these may not be bugs. It is still a good practice to parameterize these queries as a defense in depth.
80407 - Possible SQL Injection vulnerability through data that comes from a backend server and is passed through some unknown function calls. If the data is controlled by an end user through some other web pages and if there is no data validation performed on this data, then these are likely bugs.
80420 – Possible SQL Injection vulnerability through function parameters. These warnings are generated at function scope, so if the function parameter values come from trusted sources then these are false positives. If the parameter values are controlled by end users then these are very likely bugs. You can use __sql_pre_validated annotation on the function parameters to detect if end users can reach this code.
80421 – Possible SQL Injection vulnerability through function parameters and the function parameters are passed through some unknown function calls that might perform data validation. You can use __sql_pre_validated annotation on the function parameters and __sql_validate on validation function to detect if end users can reach this code.

既存の ASP で一度、どんな項目が検出されるかチェックしてみてもよいかもしれません。
使い方は、以下の様な感じで、検査対象の ASP ソースを指定するだけです。ツールは、自動的にページ遷移を追いかけませんので、複数の ASP ファイルが有る場合は、個別に検査する必要が有ります。

msscasi_asp.exe /input="default.asp"

2. URLScan の新バージョン (3.0 ベータ)
今までも、URLScan で不正なリクエストをある程度拒否する事が出来たのですが、最近のSQL インジェクション攻撃を防ぐののに便利なオプションを追加しました。
まだ、ベータという扱いですが、既存のコードに一切手を入れることなくリスクを減らすことが可能です。とはいえ、脆弱なコード、このツールを導入しても脆弱なままですし、すべてのケースで防げるとは限りません。 URLScanは、本来は「コードが対策済みで、もし、脆弱性が見つかっても」不正なリクエストを拒否する事で、実際の被害にはつながらない様にするためのリスク要因緩和ツールです。
決して、コード上の脆弱性対策の恒久的な代替え手段ではありません。

セキュリティデベロップメント “ライフサイクル”：裏側と表側

JSECTEAM — Thu, 19 Jun 2008 06:41:00 GMT

小野寺です。

セキュリティデベロップメント（SDL: Security Development Lifecycle) って本当にやってるの？
ということを、聞かれることがあるが、実は結構真面目にやっていたりします。この辺りの現場の声を Web Application Security Forum の2日目 (7/5) で話すことになりました。
といっても、話すのは私ではなく、ソニーの松並氏とマイクロソフト最高技術責任者の加治佐が、開発の現場経験から話していきます。きっと、生々しい話になるのだろうと思っています。

私もその場で聞いてみたいのですが、その日はMicrosoft Security Response Alliance Conference に出席するために、シアトルに居る予定なのです。

そのほかにも、過去の事例から多くを学んだ企業がその経験を話すようなプログラムが組まれていたり、開発者向けのセッションも内容が濃くなっているようです。

最近の事件・事故やセキュリティの動向をみていると聞いておくべき内容になっているのではないでしょうか。

最近のWeb改ざんとかSQLインジェクションとか

JSECTEAM — Wed, 30 Apr 2008 06:56:00 GMT

小野寺です。

3月頃からSQLインジェクションが原因となるWebサイトの改ざんが報告されているのは皆さまご存じの通りです。
4月に入って被害がさらに広がっているように感じています。まず、SQLインジェクションに対して殆ど認知されていないですし、その対策方法も知られていないのではないでしょうか。各方面ですでに啓発告知がなされてはいますが、その様な告知を受けている人は、ある程度セキュリティに興味があるか詳しい人である可能性が高く既に対策済みという場合が多いのではないかと思っています。この点は、マイクロソフトも例外ではなく、前々から悩ましく思っています。とはいえ、届くところには伝えなければなりませんので、マイクロソフトからも管理者・開発者を含め我々から直接連絡の取れるお客様に広く注意喚起することにしました。

SQL インジェクション攻撃とその対策
http://www.microsoft.com/japan/technet/security/guidance/sqlinjection.mspx

実際に、SQL インジェクション攻撃を受けているかは、Webサーバーの”適切に設定された”ログに現れてきます。
最近広く行われている攻撃は、自動化ツールによるものとみられており、ログに以下のような文字列の断片が見られた場合は、攻撃を受けている可能性があります。
;DECLARE%20@S%20NVARCHAR(4000);SET%20@S=CAST(0x4400450043004C0041005200450020004 (以下略)

そのほか、特殊記号 (' ; --等)がログに残っている場合も同様に注意が必要でしょう。

問題は、実際に不正なコードをインジェクション(注入)されているかどうかの確認ですが・・・<iframe>や<script>タグをうまく使っているため目視による検証はあまり意味を持ちません、また、コンテンツファイル (*.htmlとか*.asp等)を検索しててもだめです。問題のコードはデータベース側に埋め込まれることになりますので、関連するテーブルで文字列を格納可能な型の列を其々チェックすることをお勧めします。

最後に根本的な対処については、少なからずWebアプリケーションや、データベースロジックを変更することになりますので、サイトで紹介している資料等を参考に、早めの対応が肝要です。

すでに、Webが改ざんされてしまっている場合は、アプリケーション改修ももちろんですが、利用者保護も忘れずに。

日本のセキュリティチーム (Japan Security Team) : Web アプリケーション

IIS & ASP 向け検査・対策ツールを公開

セキュリティ デベロップメント “ライフサイクル”：裏側と表側

最近のWeb改ざんとかSQLインジェクションとか

セキュリティデベロップメント “ライフサイクル”：裏側と表側