DotNetNuke 対応ホスティングサービスに、「at link 専用サーバサービス」を追加
Written by: Sugishita Tomotoshi 2008/05/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 = 8 End 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 PortalSecurity Dim myFilteredText As String = _ objSecurity.InputFilter(request.form("txtSearch"), _ PortalSecurity.FilterFlag.NoScripting Or _ PortalSecurity.FilterFlag.NoMarkup) lblSearchtext.Text=”Searching for :” & myFilteredText 以降説明するいくつかの例においては、このメソッドを利用して値を検証することで、基本的な対策をすることができます問題の回避が可能ですので、覚えておいてください。 それでは前編はこのあたりで。 後編に続く。 参考資料: DotNetNuke Security Documentation
Enum FilterFlag MultiLine = 1 NoMarkup = 2 NoScripting = 4 NoSQL = 8 End Enum
Dim objSecurity As New PortalSecurity Dim myFilteredText As String = _ objSecurity.InputFilter(request.form("txtSearch"), _ PortalSecurity.FilterFlag.NoScripting Or _ PortalSecurity.FilterFlag.NoMarkup) lblSearchtext.Text=”Searching for :” & myFilteredText
参考資料: DotNetNuke Security Documentation
0 comments so far...