投稿者: Tomotoshi Sugishita
2008年5月25日 17:59
数日前にDNNの脆弱性に関する問題点が見つかったとの報告をしました。
ユーザー会のOff Site MeetingでもこれからはWebアプリケーションのセキュリティに関する内容についても取り上げていこうと思っています。
dotnetnuke.comでは、公式文書として「Secure Module Development」というガイドブックを公開しています。この文書では、モジュールを開発するにあたり、セキュリティの観点から考慮すべき点について簡単な実例と対策を説明しています。
こちらをもとに現在、Off Site Meetingで使用する資料を作成していますが、先行してこちらで内容を抜粋したいと思います。
ちょっとブログのエントリーとしてはボリュームが多いので、前後編に分けて書きます。
なぜ、セキュリティを考慮すべきなのか？
DotNetNukeは、これまで様々な運用経験やフィードバックを受けてバージョンアップを繰り返してきました。セキュリティに関する対策についても当然ながらバージョンアップとともに強固になっています。
しかしながら、これらはあくまでも技術的な手段の提供にしかすぎません。
使用する側により正しい理解と管理の上で使用されなければ、これらは全く意味をなしません。
例えば、DotNetNukeのファイルアップロードの機能でアップロード可能なファイルの種類を設定できる機能があります。ユーザー向けにファイル共有の機能を提供し、ここで画像やその他のファイルのアップロードを許可する設定をしたとします。この状況を把握していない制作者が制作過程における一方的な必要性からアップロード可能なファイルの種類にスクリプトファイルを加えたとしたらどうでしょうか？あるいはモジュール開発者が危険なファイルをまったく考慮しないようにモジュールを作成したとしたらどうでしょうか？このWebサイトが信頼できるユーザーのみに開放されるものであればさほど問題が起こらないのかもしれませんが、一般に広く開放されたものであればどうなるかはおおかた想像つきますよね？最悪のケースでは、悪意のあるスクリプトが匿名ユーザーによって配置され、Webサイト全体のアクセス権の略奪、内部の改竄や情報の漏えいといったことになります。
このようなことから、サイト管理および制作者、開発者はこれらを十分理解し、Webサイトの構築、管理にあたるべきです。
さしあたり、モジュール開発者においては開発工程において、十分な技術的対策措置を行う必要があります。
それでは、これからいくつか考慮すべき点をみていきましょう。
ユーザーインプット
「Secure Module Development」ガイドの中で最初に留意すべき点としてあげられているのがこの「ユーザーインプット」です。
「ユーザーインプット」とは、そのままとらえるとユーザーが入力したものですが、これは単にフォームなどのテキストボックスから入力されたものやURLに含まれるクエリ文字列だけではなく、ヘッダー要素に含まれるデータなどクライアントとサーバー間でやりとりされるすべてのデータも「ユーザーインプット」として含まれます。
HTTP 要求と応答は、ヘッダーとボディで構成されており、それぞれにデータが含まれています。
ちょっとしたツールを使えば、これらの中にWebアプリケーションの防御策をすりぬけるためのデータを忍び込ませることができてしまいます。
そのため、モジュールを書く際には、以下のデータを検証することを忘れてはいけません。
- Forms コレクション (hiddenフィールドも忘れずに)
- Cookie
- クエリ文字列
- Itemコレクション (DropDownListの項目が差し替えられる場合もある)
- HTTPヘッダーより取得したデータ(ブラウザのuser-agentに、悪意のあるコードを挿入される場合もある)
次にこれらのデータをどのように観点で検証してゆくべきかですが、その前にDotNetNuke Frameworkが持つ、非常に有効な機能を1つご紹介しておきます。
DotNetNuke Core Frameworkのフィルタリング機能
DotNetNukeはInputFilterと呼ばれるメソッドを持っています。
このフィルタリング機能を実行する上での検証内容として、以下のような列挙子が定義されています。
Enum FilterFlag MultiLine = 1 NoMarkup = 2 NoScripting = 4 NoSQL = 8End Enum
- MultiLine - この値はセキュリティとは直接的な関係はありません。CRLF(キャリッジリターン、ラインフィード)をHTMLの
タグに入れ替える場合に使用できます。
- NoMarkup - この値を使用すると、文字列がHTMLエンコードされます。これはクロスサイトスクリプティング攻撃に対してとても有効なメカニズムです。
プレーンテキストに含まれる<のような文字を同等のHTMLエンコード値(“<”)に変換します。これによりjavascriptなどのコードが不正に実行されるのを防げます。
ただしこれは、フォーラムやBBSなどでユーザーに対していくつかのHTMLマークアップを許可したい場合などには不向きです。
- NoScripting - この値を使用すると、文字列から疑わしいHTMLを検索し削除します。ハッカーがクロスサイトスクリプティング攻撃を試みる際によく使用されるスクリプトやHTMLを削除します。
- NoSQL - この値を使用すると、文字列からSQLを検索および削除し、SQLインジェクションを実行を防ぎます。
この列挙子に含まれるこれらの値は、単独またはOR演算子によるビット演算によって複合値として使用することができます。
例えば、以下のコードでは、NoScriptingフィルタとNoMarkupフィルタの両方を適用しています。
InputFilterメソッドに2つの値を使用した例
Dim objSecurity As New PortalSecurityDim myFilteredText As String = _ objSecurity.InputFilter(request.form("txtSearch"), _ PortalSecurity.FilterFlag.NoScripting Or _ PortalSecurity.FilterFlag.NoMarkup)lblSearchtext.Text=”Searching for :” & myFilteredText
以降説明するいくつかの例においては、このメソッドを利用して値を検証することで、基本的な対策をすることができます問題の回避が可能ですので、覚えておいてください。
それでは前編はこのあたりで。
後編に続く。
参考資料: DotNetNuke Security Documentation
投稿者: Tomotoshi Sugishita
2008年5月23日 16:38
今回のセキュリティ問題において、 DotNetNuke Corp. のShaun氏のBLOGによると、
It turned out that the problem was not as severe as anticipated, as only files with "safe" extensions could be uploaded to the server.
とあります。
パッチが発表されていない現在の状況でできる対策といえば、アップロード可能なファイルの種類を安全なもののみに限定するということです。
アップロード可能なファイルの種類の設定
- [ホスト]→[ホスト設定]を開きます。
- "高度な設定"内の"アップロードするファイルの種類"の入力ボックス内に可能な拡張子をカンマ区切りで入力します。
- 更新ボタンを押します。
投稿者: Tomotoshi Sugishita
2008年5月17日 20:36
今回、第6回の東京でした。
ネタということでは、ファーストサーバさんのフリーサービス使ってDNNサイトを運用する話と
認証システム（WindowsLiveID認証とCardSpace)の導入についての話をメインに行いました。
途中、DNNをShift-JISでとか、その他なかなか面白い話の脱線をして、とても面白かったと
思います。
また、サーバードメインさんをはじめ、参加いただいた方からもいろいろな情報提供がいただけて、
なかなか良い会になったきたなーという感触を受けました。
次回第7回を7月に開催予定です。また、6月にサーバードメインさんの会社のスペースをお借りして、
「続DNNを使ってファーストサーバさんのサーバーであそぼう！」イベントをやることになりました。
また詳細については、サイトで発表したいと思います。
とりあえず、参加いただいた方、ありがとうございました。
今回、参加できなかった方も次回はぜひご参加ください。
# 内容としては、初心者の方にはつらい内容だったかもしれないので、
# 次回はこのあたりも少し考えていきたいと思います。
今回の内容は、次回の大阪ミーティングでも少し報告させていただきますね。
フィード