WCF セキュリティの侵害 [ スターティングポイント]

1. WCFセキュリティの侵害[スターティングポイント]WCFセキュリティの侵害[スターティングポイント] マーク・シェーネフェルト Marc Schönefeld バンベルク大学

2. スピーカー • マーク・シェーネフェルト（Marc Schönefeld）、経済コンピュータ科学学士（Diplom-Wirtschaftsinformatiker） • 学術: バンベルク大学（ドイツ・ババリア地方）応用コンピュータサイエンス科博士課程 • 論文テーマ: 分散型JAVAコンポーネントにおけるセキュリティ・アンチパターンのリファクタリング • 職業: ドイツ大手金融機関のセキュリティ管理者

3. WCFはNET 3.0の一部である • NET 3.0とは • 旧WinFX（Windowsフレームワークの拡張） • Microsoftの図式によれば、 NET 2.0に以下を付加したものである • WPF（プレゼンテーション）、コードネームAvalon • WCF（通信）、コードネームIndigo • WWF（ワークフロー） • Windows XP SP2、Windows Server 2003、Windows Vistaに対応

4. NET 3.0の一部をなすＷＣＦ

5. NET 3.0は新たな.NETではない • .NET 3.0は、 .NET 2.0に新たな一連のアセンブリを加えただけのものである

6. WCFは通信処理を統一する • 通信 • WCFは既存の各種通信やホストランタイムモデルをサポートする • ASP.NET • COM+ • WSE • NET-Remoting • パイプおよびキュー

7. WCFは… • .NETクラスをサービスとして公開できる • サービスから.NETクラスへのインポート • サービスプロトコル、型変換、マーシャリングを処理する相互運用コードを含む • 開発者はアプリケーションとWebサービスを容易に連結できる

8. WCFは… • 非機能性要求をサポートする（信頼性の高いコール、非同時性、トランザクション性、セキュリティ） • 定義済みのアダプタが付随する • 標準外のシナリオに応じて、カスタムハンドラにより拡張できる • 大半のクラスはSystem.ServiceModel名前空間に存在する • 物理的にはSystem.ServiceModel.dllアセンブリに位置する

9. WCF関連用語 • SOA（サービス指向アーキテクチャ）は、クライアントで使用するローカルサービスまたはリモートサービスのインフラへの配備を支援するものである。 • クライアントは、サービスの言語、プラットフォーム、バージョンを認識する必要はない。 • サービスは、機能を提供し、新たに記述されたコードまたは修飾したCOM+サービスなどになり得る。 • クライアントは、サービスにより提供される機能を使用し、ASP.NETページ、 Windows Formなどになり得る。 • プロキシは、クライアントからサービスを分離する。

10. WCFのサポートするローカルシナリオ

11. WCFのサポートするリモートシナリオ

12. WCF認証と認証 • 認証とは、サービス呼び出し側のＩＤを確認することである： • Noauth 匿名のアクセスを許可する • Windows　ワークグループのWindowsドメインまたはＮＴＬＭのためのケルベロス（デフォルト） • UID+PWD　Windowsアカウントまたはデータベースエントリに照らしてクレデンシャルを確認する • X509 cert 　PKI環境において、クライアントは既知の証明書により認証する • セキュアトークン連合型の信頼できる環境をサポートする（WS-Trust） • カスタム認証任意の認証を登録する。たいていの場合は好ましい手法ではない • WCF認証は、以下を用いてサービス呼び出し側の許可を決定する • Windowsグループ • ASP.NETプロバイダ（データベースなど）

13. トランスポート: 有線のセキュリティ • 目標は、データ送信中のメッセージの完全性とプライバシー維持である。以下の段階的オプションを利用できる： • トランスポートセキュリティ • TCP、HTTP、IPC、MSMQ上の安全なトランスポートレイヤを使用する • メッセージセキュリティ • メッセージを暗号化する • トランスポートとメッセージの混合 • トランスポートセキュリティでプライバシーと安全性を確保し、メッセージセキュリティでクライアントの信用を確保する。完全に近い • 両方 • まず、メッセージのコンテンツをメッセージセキュリティメカニズムで保護し、付加的にトランスポートセキュリティを用いる。ほぼ完全

14. サービス B サービス A A A B B アドレス（場所） C C バインディング（方法） コントラクト（内容） WCFは場所、内容、方法を分離する サーバ クライアント A B C

15. サービスエンドポイント • クライアントとサーバは、WCF通信においてサービスエンドポイントを用いる。 • クライアントは1-nサーバエンドポイントと通信する。 • クライアントは二重メッセージ交換のためのエンドポイントを開くこともある（DualHttpBinding） • サービスエンドポイントは以下を特定する。 • エンドポイントアドレス：サービスの場所 • バインディング:サービスとの結合方法 • コントラクト:クライアントとサーバで交換される内容 • 動作：バインディング動作の拡張

16. エンドポイント URI ヘッダ ヘッダ ID情報 エンドポイントアドレス（場所） • エンドポイントの物理的アドレス（URIなど） • ヘッダ（オプション）、複数のサーバが1つのURIを共有する場合に必要 • ID情報

17. バインディング設定（方法） • 名前と名前空間がサービスを識別 • バインディング要素が通信詳細を調整（信頼性、SOAPメッセージセキュリティ、TCPレイヤ保護） • 多数のプリセット バインディング 名前 名前空間 バインディング要素 バインディング要素

18. WCFコントラクト（内容） コントラクト • ここでも名前と名前空間がサービスを識別 • 操作記述がタイプを決定（送信/無視、要求/返答) • 二重のオペレーションがクライアントに応答 名前 名前空間 操作記述セット 操作記述 メッセージ記述セット メッセージ記述 コントラクト動作セット コントラクト動作

19. サービス記述はサーバコンフィギュレーションサービス記述はサーバコンフィギュレーション サービス記述 • サービスはタイプ分けされ、複数の動作設定を持つ • 複数のエンドポイント（1つは通常のTCP、もう1つはHTTPなど …）上で達成できる サービスタイプ サービス動作セット サービス動作 サービスエンドポイントセット サービスエンドポイント エンドポイントアドレス バインディング コントラクト

20. チャネル記述はクライアントコンフィギュレーションチャネル記述はクライアントコンフィギュレーション チャネル記述 • チャネルはクライアントにより使用され、複数の動作設定を持つ • 1つのエンドポイントを持つ（1つは通常のTCP、もう1つはHTTPなど…） チャネル動作セット チャネル動作 サービスエンドポイント エンドポイントアドレス バインディング コントラクト

21. WCFランタイム環境のコンセプト • メッセージ • SOAPメッセージInfosetとして表現されるメッセージは、WCF情報の中心となる要素である • XMLテキスト、バイナリ（WCF2WCF）、カスタムフォーマット（JSON、XML-RPC）を使用してメッセージをシリアル化できる。 • チャネル • エンドポイントからエンドポイントへメッセージを送信する経路。チャネルは階層化されている。 • トランスポートチャネルは、物理的データを送信するメディアを定義する（UDP、MQ、パイプ、TCP）。 • プロトコルチャネルは、データの操作方法を定義する（SOAPプロトコルなど）。 • セキュリティチャネルは、メッセージの保護方法を定義する。

22. WCFスタートアップ手順 • サーバはServiceHostオブジェクトを初期化し、エンドポイントを開く（XMLコンフィギュレーションまたはハードコード) • クライアントはChannelFactoryオブジェクトを初期化する（コンフィギュレーションまたはコード）

23. イントラネットバインディング • BasicHttpBinding • ASMXベースのWebサービス、クライアント、およびWS-I Basic Profile 1.1と互換性のある他のサービス • セキュリティはデフォルトでオフ • テキストエンコード、UTF-8 • NetTcpBinding • 複数マシンをまたぐ通信セキュリティを確保 • トランスポートセキュリティ • バイナリメッセージエンコード

24. イントラネットバインディング • NetPeerTcpBinding • TCPを用いたピアツーピア通信 • インプット、アウトプット、全二重通信路 • トランスポートセキュリティがデフォルトでオン • NetNamedPipe • オンマシン通信向け • トランスポートセキュリティがデフォルトでオン • パイプ名はBase64でエンコードされたサービス名

25. インターネットバインディング • WSHttpBinding • Webサービス機能向けのhttpバインディング • メッセージセキュリティ • トランザクション、信頼できるメッセージング、WS-Addressingによる安全で信頼性の高いバインディング • WSFederationHttp • WSHttpBindingと同様だが、SSO機能を持つ • セキュアトークンには理想的な選択肢 (http://weblogs.asp.net/cibrax/archive/2006/03/14/440222.aspx)

26. インターネットバインディング • WSDualHttpBinding • サービスとクライアントの両方でメッセージの送受信が可能な二重モードのサービスコントラクトで使用可能 • SOAPセキュリティのみをサポート。信頼できるメッセージングが必要 • NetMsmqBinding • Microsoft Message Queuing（MSMQ）上のトランスポートをサポート • 緩やかに結合したアプリケーションの設計、問題分離、負荷平準化、切断オペレーション向け • 初期バージョンでは、 64Kを越える容量のメッセージでDOS問題が見られた

27. 脅威モデリング：WCFとOWASPのインテグリティ A1 許可されていないパラメータ A2 アクセス制御の不具合 A3 アカウントおよびセッション管理の不具合 A4 クロスサイトスクリプティング（XSS）の脆弱性 A5 バッファオーバーフロー A6 コマンドインジェクションの脆弱性 A7 エラー処理の問題 A8 安全ではない暗号の使用 A9 リモート管理の脆弱性 A10 不適当なサーバ設定

28. WCF & OWASP • A1: 許可されていないパラメータ : • 許可されていないパラメータに対する防御策はない。.NET 3.0には汚染モデルはない • A4: XSS: • したがってXSSに対するサポートはない • A5: バッファオーバーフロー • COM+レガシーコード（C/C++）は、WCF経由で接続してもオーバーフローの危険性がある • A6: コマンドインジェクション: • 信頼できない値を持つデータフローを、アプリケーションがどのように処理し、SQLパラメータへ伝播しているかによって異なる。 • A10: 不適当なサーバ設定 • アプリケーション内のハードコード設定は脆弱性につながる危険があり、配置人員は選択肢の多さに混乱する可能性がある。（CipherSuiteをどこに設定するか？）

29. 脅威モデリング： WCF & COM+ • WCFでは、COM+とComSvcConfigツールを統合できる • COM+には2つのホスティングモードが使用可能： • COM+デフォルト： コンポーネントをDLLHOST内で実行 • Webベース：コンポーネントをIIS内で実行、要求により有効化 • 脆弱性のある古いコンポーネントを復活させないように注意が必要 • 配備に先立ちコンポーネントをチェックすること！

30. 脅威モデリング：機密性 • 以下のような通信に関する脅威モデリング設定があるとする • アリスはボブと通信したい • マロリーは妨害したい • WCFは、きわめて効果的に通信傍受を防止する • トランスポートワイヤの上に座るマロリー • WCFは、通信妨害を防止できない • アリスと彼女のエンドポイント、またはボブと彼のエンドポイントのあいだに座るマロリー（パッチを当てたCLR、アプリケーションのように） • WCFは、クレデンシャルの盗難を防止できない • マロリーがアリスからキーやコードを盗んだり、アリスからそれらが漏洩した場合は、マロリーは完全にアクセスできる

31. 脅威モデリング：コードセキュリティ • WCFは、タイプの混乱を防止する • 強力なコントラクトを使用 • Javaシリアライゼーションよりも格段に優れている • .NETは、整数オーバーフローを防止する • Javaとは対照的に、フィリッピングの兆候を警告する • XMLパーサーはきわめて安定しているようである • 大規模なメッセージ攻撃に対して • 複数のXML異常攻撃に対して

32. WCFにおける安全なコーディング • 静的コードチェックにより、自身およびサードパーティのコードのなかで問題領域を見つけ出す • すべてのコードをすぐに利用できるわけではない • サードパーティのライブラリは、暗号化されているか、でなければ保護されていることがあるので、コードを入手する際には、しばしばsalamanderの無料ツールが役に立つ • http://www.remotesoft.com/deprotector/ • ソースコードがないことは問題ではない：MSILバイナリがすべてを備えている！ • 偽陽性が多いが、静的MSILチェッカーは役に立つことがある • FXCopは良いスターティング・ポイントである。以下で無料入手可能 http://www.gotdotnet.com/Team/FxCop • 定義済みのセキュリティルールセットが付随！

33. WCFにおける安全なコーディング • 一部の関連するFXCopは、コーディングガイドラインの安全を確保する。これは、WCFでコーディングする際に役立つ。 • 強制的セキュリティを確認する • SQLクエリを確認し、セキュリティ上の脆弱性をチェックする • ポインタは見えないようにすべきである • リンクデマンドを伴うメソッドを間接的に公開しない • 読み取り専用の可変参照タイプを宣言しない • Aptcaメソッドは Aptcaメソッドのみを呼び出すべきである • Aptcaタイプは Aptca基本タイプのみを拡張すべきである • 独自のルールをコード化し、既存のものを変更する： • http://weblogs.asp.net/pglavich/archive/2005/07/19/419869.aspx • http://www.futureware.biz/blog/index.php?title=writing_your_own_fxcop_rules_library

34. 要望 • パフォーマンスの向上 • XMLにおけるWCF動作が遅い • XML + セキュリティにおけるWCF動作は、極端に遅い（3Ghzマシン使用時でも） • 覚えておくべきこと:可用性はセキュリティに関わる問題！ • ホームフォンの問題 • WCFが証明書の有効性を確認し、HTTPリクエストをMicrosoftに送信する • 安全な文字列インプリメンテーションの使用 • クレデンシャルが通常の文字列内に安全ではない状態で保存されている • サービスからの受信後、 .NETがデータを直接SecureStringフィールド内に保存するようにすれば有効であると思われる • 利用可能なパターンがなく、以下が開発者の負担となる • 関連するオプションの組み合わせの発見 • 保護レベルおよびパフォーマンスの調整

35. まとめ • WCFは新たなベースラインセキュリティモデルを提供する。 • 各種の配備および設定機能により、デフォルトのセキュリティモデルが侵害される。 • レガシー（COM+）統合の容易さにより、脆弱性のあるコードがバックエンドで呼び出される。 • 安全なトランスポートフレームワークにもかかわらず、安全なコーディングが依然として必要である。

36. Q&A どうもありがとう Domo arigato marc.schoenefeld ät gmx dot org.ilasm