OpenMeisterEnterprise® .NET 2005 / 2015 障害情報

既知の問題点につき、その解決情報を掲載しております。

.NET Framework 4.5 環境で発生する viewstate エラーの回避方法
Application_Startイベントでのログ出力エラー回避方法（IIS7 以降）
通信データ簡易暗号化機能の脆弱性
.NET Framework 4 環境で発生するデシリアライズエラーの回避方法
入力検証機能の問題の修正
.NET Remotingのファサード一括登録機能の問題の修正

2013/03/31

.NET Framework 4.5 環境で発生する viewstate エラーの回避方法

対象バージョン　OME.NET 2005 システム基盤 Ver.1.0 Ver.1.1 Ver.1.2 Ver.1.3 Ver.1.4

.NET Framework 4.5環境のWebFormアプリケーションにブラウザからリクエストを送信すると、サーバ処理で System.Web.UI.ViewStateException が発生することがあります。

この問題は、アプリケーション情報やユーザ情報等へのアクセスを提供する Common.Information.InformationManager クラスが、ユーザ情報をスレッドに関連する CallContext に保持しているために発生します。

.NET Framework 4.5 ではリクエストの処理パイプライン中に、ワーカースレッドを再割り当てする動作が発生しやすい傾向にあり、CallContext に保持しているユーザ情報がこの再割り当てによってクリアされてしまうことで、ViewState の検証に失敗してViewStateException が発生します。

この問題を回避するには、次のように修正します。

[C#の場合]　InformationManager.cs　（134から220行目付近）
InitializeForServer メソッドの、CallContextBoundObjectPool を RequestBoundObjectPool に変更します。
これはユーザ情報を、リクエストに関連する HttpContext に保持することで、スレッド再割り当てによる影響をなくすものです。

(修正前)
s_forUserInfo = new CallContextBoundObjectPool();
s_forAuthInfo = new CallContextBoundObjectPool();
s_forClientInfo = new CallContextBoundObjectPool();
s_forServerInfo = new CallContextBoundObjectPool();
s_forSharedInfo = new CallContextBoundObjectPool();

(修正後)
s_forUserInfo = new RequestBoundObjectPool();
s_forAuthInfo = new RequestBoundObjectPool();
s_forClientInfo = new RequestBoundObjectPool();
s_forServerInfo = new RequestBoundObjectPool();
s_forSharedInfo = new RequestBoundObjectPool();

[VBの場合]　InformationManager.vb　（142から219行目付近）
InitializeForServer メソッドの、CallContextBoundObjectPool を RequestBoundObjectPool に変更します。
これはユーザ情報を、リクエストに関連する HttpContext に保持することで、スレッド再割り当てによる影響をなくすものです。

(修正前)
s_forUserInfo = New NECST.OME2.Framework.Utility.ObjectPool.CallContextBoundObjectPool()
s_forAuthInfo = New NECST.OME2.Framework.Utility.ObjectPool.CallContextBoundObjectPool()
s_forClientInfo = New NECST.OME2.Framework.Utility.ObjectPool.CallContextBoundObjectPool()
s_forServerInfo = New NECST.OME2.Framework.Utility.ObjectPool.CallContextBoundObjectPool()
s_forSharedInfo = New NECST.OME2.Framework.Utility.ObjectPool.CallContextBoundObjectPool()

(修正後)
s_forUserInfo = New NECST.OME2.Framework.Utility.ObjectPool.RequestBoundObjectPool()
s_forAuthInfo = New NECST.OME2.Framework.Utility.ObjectPool.RequestBoundObjectPool()
s_forClientInfo = New NECST.OME2.Framework.Utility.ObjectPool.RequestBoundObjectPool()
s_forServerInfo = New NECST.OME2.Framework.Utility.ObjectPool.RequestBoundObjectPool()
s_forSharedInfo = New NECST.OME2.Framework.Utility.ObjectPool.RequestBoundObjectPool()

2011/11/30

Application_Startイベントでのログ出力エラー回避方法（IIS7 以降）

対象バージョン　OME.NET 2005 システム基盤 Ver.1.1 Ver.1.2 Ver.1.3 Ver.1.4

2012/08/02
回避方法として提示していたコード内容に誤りがありましたので、訂正いたしました。

Internet Information Services 7 以降の環境において、Global.asax の Application_Startイベントでログ出力を行うと、TextFileLogWriter または AsyncTextFileLogWriter によるログデータのフォーマット処理で System.Web.HttpException が発生します。

※この問題は、IIS7のマネージパイプラインモードが、統合モード（デフォルト設定）の場合のみ発生します。

※「IIS 7 での ASP.NET 2.0 の互換性に影響する変更点」に記載されている「16. global.asax 内の Application_Start の HttpContext.Current プロパティを通じて要求にアクセスできない」の影響です。

Application_Startイベントでログ出力する場合は、次のように修正します。

[C#の場合]
TextFileLogWriter.cs　（259から337行目付近）
AsyncTextFileLogWriter.cs　（333から400行目付近）
２つのファイルについて、FormatLogInfo メソッド内の
HttpContext current = HttpContext.Current;
という処理の後に、Request 取得で例外が発生した場合に null を設定しなおす try-catch 処理を追加します。

(修正前)
HttpContext current = HttpContext.Current;

(修正後)
HttpContext current = HttpContext.Current;
if (current != null)
{
try
{
HttpRequest request = current.Request;
}
catch (HttpException)
{
// IIS7以降の統合パイプラインモードにおけるApplication_Startイベント内等、
// Requestオブジェクトへのアクセスで例外が発生する場合はリクエスト情報を使用しない
current = null;
}
}

[VBの場合]
TextFileLogWriter.vb　（250から330行目付近）
AsyncTextFileLogWriter.vb　（328から403行目付近）
２つのファイルについて、FormatLogInfo メソッド内の
Dim current As System.Web.HttpContext = System.Web.HttpContext.Current
という処理の後に、Request 取得で例外が発生した場合に Nothing を設定しなおす Try-Catch 処理を追加します。

(修正前)
Dim current As System.Web.HttpContext = System.Web.HttpContext.Current

(修正後)
Dim current As System.Web.HttpContext = System.Web.HttpContext.Current
If current IsNot Nothing Then
Try
Dim request As System.Web.HttpRequest = current.Request
Catch ex As System.Web.HttpException
' IIS7以降の統合パイプラインモードにおけるApplication_Startイベント内等、
' Requestオブジェクトへのアクセスで例外が発生する場合はリクエスト情報を使用しない
current = Nothing
End Try
End If

2011/03/31

通信データ簡易暗号化機能の脆弱性

対象バージョン　OME.NET 2005 システム基盤 Ver.1.4

Ver.1.4 で追加された「通信データ簡易暗号化機能」に、パディングオラクル攻撃に対する脆弱性が発見されました。
この問題は、サーバに不正なリクエストを多数送信しそのエラー応答を解読することで、暗号化された通信内容が解読できてしまう可能性がある、というものです。
Windows アプリケーションにおいて、OMEの「通信データ簡易暗号化機能」を利用して、送受信データを暗号化している場合に影響があります。（デフォルトでは、この機能の利用はオフに設定されています）
OMEの「通信データ簡易暗号化機能」は .NET Remoting を利用したイントラネットの通信を主に対象としており、問題の影響度はあまり大きくないと考えられますが、この機能をご利用の場合は下記修正の対処をご検討ください。

※なお、「通信データ簡易暗号化機能」を利用している場合、単にこの機能を使わないようにする、という対処は行わないでください。通信内容が全く保護されなくなるため、セキュリティレベルはより低くなってしまいます。

※OMEの「通信データ簡易暗号化機能」を利用しているかどうかの確認方法はこちらを参照ください。

※OMEの「通信データ簡易暗号化機能」についての詳細は、共通機能利用ガイド「5.6.通信データ簡易暗号化機能」をご参照ください。

この問題を回避するには、次のように修正します。

[C#の場合]　ProtectionSinkHelper.cs　（130行目付近）　
GetDecryptedStream メソッド内の処理全体を try-catch で囲み、catch ブロックに、新しく例外をスローする処理を追加します。

public static Stream GetDecryptedStream(...
{
   try
   {
       既存の GetDecryptedStream メソッド内の処理全体
   }
   catch (Exception ex)
   {
       Common.Logging.LogManager.Log(Common.Logging.LogLevel.Trace,
           "Common.Remoting.ProtectionSinkHelper", "GetDecryptedStream",
           "暗号化ストリームの復号処理でエラーが発生しました。", ex);

       throw new InvalidOperationException(
                          "暗号化ストリームの復号に失敗しました。");
   }
}

[VBの場合]　ProtectionSinkHelper.vb　（144行目付近）　
GetDecryptedStream メソッド内の処理全体を Try-Catch で囲み、 Catch ブロックに、新しく例外をスローする処理を追加します。

Public Shared Function GetDecryptedStream( ...
   Try

       既存の GetDecryptedStream メソッド内の処理全体

   Catch ex As Exception

      Common.Logging.LogManager.Log(Common.Logging.LogLevel.Trace, _
         "Common.Remoting.ProtectionSinkHelper", "GetDecryptedStream", _
         "暗号化ストリームの復号処理でエラーが発生しました。", ex)

      Throw New InvalidOperationException( _
                          "暗号化ストリームの復号に失敗しました。")
   End Try
End Function

【補足】「通信データ簡易暗号化機能」を利用しているか確認する方法

クライアントアプリケーションの構成ファイル App.config（～.exe.config）をひらき、
下記【設定例】の、太字部分を確認します。

【設定例】App.config（～.exe.config）
.NET Remoting に関する設定（チャネル・フォーマッタの設定等）

<system.runtime.remoting>
<application>
<channels>
<channel ref="http client">
<clientProviders>
<formatter ref="binary"/>
:


<provider
type="Common.Remoting.ProtectionClientSinkProvider,
Common"
enableProtection="false"
/>
:
</clientProviders>
</channel>
</channels>
</application>
</system.runtime.remoting>

太字部分のタグの設定が、下記パターン１～４のいずれに該当するかによって、機能を利用しているかどうか確認してください。
なお、type=以降の部分は、"Common.Remoting.ProtectionClientSinkProvider, Common" であるものが対象ですのでご注意ください。

●パターン１　 enableProtection="false"になっている　→簡易暗号化機能を使わない設定

●パターン２　 enableProtection="true"になっている　　→簡易暗号化機能を使う設定

●パターン３　 enableProtectionの設定がない →簡易暗号化機能を使う設定

●パターン４　 下記タグ自体の記述がない →簡易暗号化機能を使わない設定

2010/10/01

.NET Framework 4 環境で発生するデシリアライズエラーの回避方法

対象バージョン　OME.NET 2005 システム基盤 Ver.1.0 Ver.1.1 Ver.1.2 Ver.1.3 Ver.1.4

.NET Framework 4 環境で WindowsForm や WPF アプリケーションから、 .NET Remoting を利用して型つき DataSet や DataTable をサーバに送信すると、サーバ側のデシリアライズ処理で System.Security.SecurityException が発生します。

※この問題は、「.NET Framework 4 におけるセキュリティの変更点」の影響です。
OpenMeisterEnterprise .NET 2005 に特有のものではありませんが、
サンプルアプリケーションでも上記に該当する処理をしていますので参考情報として提供いたします。
なおここでご紹介する回避方法は、妥当であることを Microsoft 社に確認しております。

この問題の回避方法として、以下 2 通りの方法があります。
状況に応じてどちらかの手段を選択してください。

■Webサイト全体にシリアライズレベルを設定する
サーバの構成ファイル（web.config）のリモーティングチャネル設定で、利用するフォーマッタの TypeFilterLevel を Full に設定します。
これはサーバ側でデシリアライズの対象にする型の制限をなしとするものです。

※この方法は、構成ファイルの設定だけで済み、リビルドする必要がありません。
対象のWebサイト下のアプリケーション全体に適用されます。

web.config 　※下記太字部分を追加します。

<system.runtime.remoting>
<application>
:
<channels>
<channel ref="http server">
<serverProviders>
:
<formatter ref="binary" typeFilterLevel="Full" />
</serverProviders>
:

■対象アセンブリにセキュリティモデルを指定する
サーバ送信用の DataSet と DataTable の定義をしているアセンブリのセキュリティモデルとして .NET Framework 2.0 のルール(透過性モデルレベル 1 )を指定します。
例えばサンプルアプリケーションの場合、BusinessEntity プロジェクトの AssemblyInfo.cs に、SecurityRules 属性の設定を追加します。

※この方法は、コードに設定を追加後、リビルドが必要です。
アセンブリ単位で設定するため、該当アセンブリ全てに同様の対応が必要です。

[C#の場合]　AssemblyInfo.cs ※下記コードを追加します。

using System.Security;

[assembly: SecurityRules(SecurityRuleSet.Level1)]

[VBの場合]　AssemblyInfo.vb 　※下記コードを追加します。

Imports System.Security

<Assembly: SecurityRules(SecurityRuleSet.Level1)>

2009/04/01

入力検証機能の問題の修正

対象バージョン　OME.NET 2005 システム基盤 Ver.1.2 Ver.1.3 Ver.1.4

入力検証機能において、複数のスレッドから同時に同じ検証IDで検証を行うと、
低い確率で InvalidCastException 例外がスローされることがあります。
この問題は、各検証IDでの初回検証実行時にのみ発生する可能性があります。
この問題を解決するには、次のように修正します。

[C#の場合]　ValidationMapper.cs　（44行目）

(修正前)
validator = (FieldValidatorBase)s_validatorTable[id];

(修正後)
validator = (IFieldValidator)s_validatorTable[id];

[VBの場合]　ValidationMapper.vb　（50行目）

(修正前)
validator = DirectCast(s_validatorTable(id), FieldValidatorBase)

(修正後)
validator = DirectCast(s_validatorTable(id), IFieldValidator)

2008/10/01

.NET Remotingのファサード一括登録機能の問題の修正

対象バージョン　OME.NET 2005 システム基盤 Ver.1.1 Ver.1.2 Ver.1.3

.NET Remoting のファサード一括登録機能で、public ファサード以外も自動登録の対象とする設定（publicOnly 属性を false に設定）にしても、 public ファサード以外が自動登録対象にならない問題がありました。
この問題を解決するには、次のように修正します。

※サービス公開用のファサードを public のみで定義している場合、修正の必要はありません。

[C#の場合]　RemotingConfigurator.cs　（60行目付近）

(修正前)
// アセンブリに含まれる型を一括処理
foreach (Type type in assembly.GetExportedTypes())

(修正後)
// アセンブリに含まれる型を一括処理
foreach (Type type in assembly.GetTypes())

[VBの場合]　RemotingConfigurator.vb　（70行目付近）

(修正前)
' アセンブリに含まれる型を一括処理
Dim type As Type
For Each type In assembly.GetExportedTypes()

(修正後)
' アセンブリに含まれる型を一括処理
For Each type As Type In assembly.GetTypes()

サイト内の現在位置を表示しています。