SharePoint 2010 での開発者のためのセキュリティに関するベスト プラクティス

概要:  Microsoft SharePoint 2010 を使用して開発を行うときに推奨されるセキュリティに関するベスト プラクティスについて説明します。

最終更新日: 2015年3月9日

適用対象: Business Connectivity Services | Open XML | SharePoint Designer 2010 | SharePoint Foundation 2010 | SharePoint Online | SharePoint Server 2010 | Visual Studio

この記事の内容
SharePoint のセキュリティに関するベスト プラクティスの概要
SharePoint のセキュリティに関するベスト プラクティス: クロスサイト スクリプティング
SharePoint のセキュリティに関するベスト プラクティス: クロスサイト リクエスト フォージェリ
SharePoint のセキュリティに関するベスト プラクティス: 権限の昇格
SharePoint のセキュリティに関するベスト プラクティス: サービス拒否
SharePoint のセキュリティに関するベスト プラクティス: 情報流出
まとめ
参考資料

提供元:  Matt Swann、Microsoft Corporation

目次

• SharePoint のセキュリティに関するベスト プラクティスの概要

• SharePoint のセキュリティに関するベスト プラクティス: クロスサイト スクリプティング

• SharePoint のセキュリティに関するベスト プラクティス: クロスサイト リクエスト フォージェリ

• SharePoint のセキュリティに関するベスト プラクティス: 権限の昇格

• SharePoint のセキュリティに関するベスト プラクティス: サービス拒否

• SharePoint のセキュリティに関するベスト プラクティス: 情報流出

• まとめ

• 参考資料

SharePoint のセキュリティに関するベスト プラクティスの概要

この記事では、Microsoft SharePoint 2010 を使用して開発を行うときに考慮する必要のある、推奨されるセキュリティに関するベスト プラクティスについて説明します。クロスサイト スクリプティング (XSS)、クロスサイト リクエスト フォージェリ (CSRF または XSRF)、権限の昇格、サービス拒否、情報流出などが含まれます。

SharePoint のセキュリティに関するベスト プラクティス: クロスサイト スクリプティング

クロスサイト スクリプティング (XSS) 攻撃は、クライアント側スクリプト コードを挿入することで、Web ページ検証の脆弱性を悪用するものです。Web アプリケーションがクロスサイト スクリプティング攻撃を受けやすくなる一般的な脆弱性としては、適切な入力検証の不備、出力のエンコードの不備、共有データベースから取得されたデータの信頼などがあります。

以下のセクションでは、これらの脆弱性について説明し、推奨事項を示します。XSS の詳細については、「How To: ASP.NET でクロスサイト スクリプトを防止する方法」を参照してください。

SPHttpUtility のメソッドを使用して出力を適切にエンコードする

攻撃者は、自分の ECMAScript (JavaScript、JScript) スクリプトを攻撃対象の Web サイトで実行しようとします。それが成功すると、攻撃者は認証 cookie を盗みだし、管理者に悪質なアクションを実行させることができます。

このような攻撃者は、ユーザーの入力が正しくエンコードされていない場所を探します。このような場所では、ユーザー入力を HTML または JavaScript として解釈できます。たとえば、<script>alert()</script> というタグが付いているリスト アイテムは、クライアントでレンダリングされる前に Microsoft.SharePoint.Utilities.SPHttpUtility.HtmlEncode を使用して HTML でエンコードされていない場合、JavaScript を実行します。

推奨事項

ユーザー データをクライアントでレンダリングする前に、SPHttpUtility クラスの適切なメソッドを使用してデータをエンコードします。ユーザー データのソースとしては次のようなものがあります。

• SharePoint オブジェクト モデルからのデータ (たとえば、フィールド値やリスト タイトル)

• クエリ文字列、ヘッダー、cookie、または要求のフォーム本体からのパラメーター

• Web サービスのパラメーター

使用するエンコード メソッドは、表 1 で示すように、クライアントでのデータの使用方法によって異なります。

表 1. エンコードに使用する SPHttpUtility メソッド

種類	使用する Microsoft.SharePoint.Utilities.SPHttpUtility クラスのメソッド
HTML タグの内部のテキスト	HtmlEncode
HTML タグの内部のテキスト、基本的な書式設定を許可	HtmlEncodeAllowSimpleTextFormatting
HTML タグの属性、URL 以外	HtmlEncode
HTML タグの属性、URL	HtmlUrlAttributeEncode
JavaScript	EcmaScriptStringLiteralEncode
既知の安全な値 (たとえば、クエリ パラメーターからの GUID)	NoEncode

SPHttpUtility.NoEncode を呼び出すと、ソース コードでのエンコードに関する問題を監査するときに役に立ちます。SPHttpUtility.NoEncode を呼び出すことで、その値をエンコードする必要があるかどうかを検討したことがわかります。

Microsoft .NET Framework HttpUtility エンコーダーを代わりに使用できるでしょうか。

いいえ、使用しないでください。.NET Framework HttpUtility エンコード ライブラリでは、すべての文字が十分にエンコードされません。たとえば、SharePoint の SPHttpUtility では一重引用符は &#39; としてエンコードされますが, .NET Framework HttpUtility では一重引用符はエンコードされません。これにより、次のコードで示すように XSS のバグが発生します。

Response.Write("<a href='http://contoso/" + 
HttpUtility.HtmlAttributeEncode(Request.QueryString["target"]) + 
"'>test</a>");

共同作成者ユーザーにサイトへのスクリプトの追加を許可しない

SharePoint 2010 の一部の機能では、ユーザーがサイト上で JavaScript を作成できる場合があります。次のような機能です。

• コンテンツ エディター Web パーツを使用すると、任意の JavaScript をページに追加できます。

• 一部のドキュメントの種類はダウンロードされたときにブラウザーで HTML としてレンダリングでき、スクリプトを実行できます。

ページの追加とカスタマイズ アクセス許可を持たないユーザーは、信頼できないものとみなし、前記のような機能を使用してサイトにスクリプトを追加できないようにする必要があります。共同作成者アクセス許可レベルを持つユーザーには、この権限はありません。

注意

SharePoint 2010 でのアクセス許可に関する詳細については、「Chapter 11: Users and Permissions」を参照してください。

推奨事項

ユーザーによるサイトへのスクリプトの追加を許可する機能を作成する場合は、次のコードで示すように、機能で現在のユーザーのアクセス許可を調べて、SPBasePermissions.AddAndCustomizePages アクセス許可を持たないユーザーは阻止する必要があります。

if (!SPContext.Current.Web.DoesUserHavePermissions(SPBasePermissions.AddAndCustomizePages))
{
   // User does not have permission to add script to the site. 
   // Either disable the feature or throw an access denied exception.
   throw new UnauthorizedAccessException();
}

ユーザーがアップロードしたドキュメントを表示またはダウンロードする機能では、ドキュメントを返すときに X-Content-Type-Options: nosniff HTTP 応答ヘッダーを追加する必要があります。ブラウザーでドキュメントを表示する必要がない場合は、2 つの追加 HTTP 応答ヘッダーを送信して、表示されないようにする必要があります。送信する HTTP 応答ヘッダーを次に示します。

• X-Download-Options: noopen

• Content-Disposition: attachment

Content-Type HTTP 応答ヘッダーで常に文字セットを設定する

開発者は、山かっこ < および > などのような特殊文字を含む入力を遮断することで、XSS を防ぐことがよくあります。残念ながら、攻撃者は、ブラウザーにページを UTF-7 または別の文字セットとして解釈させることができれば、山かっこを使用しなくても <script> タグを挿入できます。

推奨事項

常に、Content-Type HTTP 応答ヘッダーで文字セットを指定してください。通常は、次の例で示すように UTF-8 形式を指定する必要があります。

Content-Type: text/html; charset=UTF-8

このように文字セットを指定すると、攻撃者はページのコンテンツ内からブラウザーの文字セットを制御できません。

文字セットの指定に加えて、nosniff ヘッダーを指定して MIME スニッフィングを防ぐことをお勧めします。

スタイル属性およびイベント属性ではユーザー指定の値を許可しない

style および event 属性でユーザー指定の値を許可することは不適切なことですが、しばしば行われます。ユーザー指定のデータに関しては次のようにすることをお勧めします。

推奨事項

ユーザー指定の値を style 属性に反映しないようにします。HTML エンコードを使用しても役に立ちません。以下の例に示すように、HTML エンコードを使用したときの脅威の軽減は場合によります。

例 1: 次の style 属性値全体はエンコードされますが、すべてのブラウザーは属性を使用する前に属性値を HTML デコードするので、やはりスクリプトが実行されます。この場合、HTML エンコードは役に立たず、脆弱性を軽減する妥当な方法はありません。

<html>
  <body>
     <div style="&#119;&#58;&#101;&#120;&#112;&#114;&#101;&#115;&#115;&#105;&#111;&#110;&#40;&#97;&#108;&#101;&#114;&#116;&#40;&#41;&#41;"></div>
  </body>
</html>

**例 2:**font-family の場合は、安全であることがわかっているフォント名だけを許可できます。background-image の場合は、使用されるプロトコル ハンドラーを確認し、さらに URL を調べて新しい style トークンが挿入されていないことを確認することが必要になる場合があります。

ユーザー指定の値をイベント属性に反映しないでください。やはり、HTML エンコードを使用しても役に立ちません。HTML エンコードを使用したときの脅威の軽減は場合によります。

代わりに、JavaScript エンコードを使用し、場合によってはユーザー指定のデータを 2 回エンコードする必要があります。以下はその一例です。

例 1: 次の場合は、JavaScript エンコードで十分です。

<a href="#" onclick="alert(__USER_PROVIDED_DATA__)">

例 2: 次の場合は、最初に HTML でエンコードした後、JavaScript でエンコードする必要があります。

<a href="#" onclick="document.write(__USER_PROVIDED_DATA_)">

例 3: 次の場合は本質的に脆弱です。この脆弱性を軽減する妥当な方法はありません。

<a href="#" onclick="__USER_PROVIDE_DATA__">

SharePoint のセキュリティに関するベスト プラクティス: クロスサイト リクエスト フォージェリ

クロスサイト リクエスト フォージェリ (CSRF または XSRF) は、攻撃対象のブラウザーを錯覚させ、攻撃対象のユーザーに代わって望ましくないアクションを実行する攻撃です。たとえば、この種の攻撃により、金銭の移動、パスワードの変更、商品の購入などが行われる可能性があります。

CSRF の詳細については、「Cross-Site Request Forgery Attack Explained(英語)」を参照してください。

ポストバックを処理する前にフォーム ダイジェスト カナリアを調べる

攻撃者は、ドメイン内でスクリプトを実行できない場合であっても、SharePoint でページをポストできます。攻撃者によって所有されているページを閲覧すると、攻撃者は閲覧したユーザーの資格情報を使用して SharePoint で操作を実行できます。

たとえば、攻撃者が http://contoso123 でページを制御しているものとします。ユーザーが攻撃者のページを閲覧すると、ページはユーザーの資格情報を使用して http://wingtip/_layouts/deleteweb.aspx にポストします。ーザーが http://wingtip に対する管理者権限を持っていた場合、http://wingtip Web サイトが削除されます。

推奨事項

SharePoint では、動的カナリアを使用して、POST 要求がサーバーと同じドメインからのものであることが確認されます。

それには、2 つのことを行う必要があります。

• すべてのポストバックまたは Web サービス要求でカナリアを送信します。

• ポストバックまたは Web サービス要求を処理する前にカナリアを確認します。

手順は次のとおりです。

1. すべてのポストバックまたは Web サービス要求でカナリアを送信します。

   カナリア値は、SharePoint マスター ページを使用するすべてのページに非表示の __REQUESTDIGEST フォーム要素として既に存在しています。すべてのポストバックで自動的に送信されます。

   SharePoint マスター ページを継承したくない場合は、Microsoft.SharePoint.WebControls.FormDigest コントロールを使用して、値をページに書き込む必要があります。Web サービスの呼び出しを行う場合は、次の例に示すように、__REQUESTDIGEST 値を取得して、X-RequestDigest HTTP 要求ヘッダーに含める必要があります。

   var canaryValue = document.getElementById('__REQUESTDIGEST').value;
   request.SetRequestHeader("X-RequestDigest", canaryValue);
   

   ブラウザーの外部のクライアント アプリケーションでは、Sites.asmx SOAP Web サービスの GetUpdatedFormDigestInformation(英語) Web メソッドを呼び出して、手動でカナリア値をフェッチする必要があります。この値が、すべての Web サービス呼び出しの X-RequestDigest ヘッダーに含まれている必要があります。

   注意

   カナリア値は 30 分後にタイムアウトするので (構成可能、GetUpdatedFormDigestInformation で返されます)、クライアント アプリケーションはサーバーで古すぎるカナリア値が破棄された場合に有効なカナリアを再要求できるようにしておく必要があります。ブラウザーの場合はこのような問題はありません。FormDigest コントロールは、JavaScript を使用して __REQUESTDIGEST フォーム値を適切に更新します。

2. ポストバックまたは Web サービス要求を処理する前にカナリアを確認します。

   ポストバックまたは Web サービス呼び出しの結果として何らかのアクションを実行する前に、ValidateFormDigest() を呼び出して、カナリアが有効であることを確認する必要があります。カナリアが有効でない場合は例外がスローされます。

   注意

   これには、たとえばユーザーが送信したコンテンツでのページの更新などの、状態が変化しないポストバックも含まれます。

AllowUnsafeUpdates の使用は可能な限り避ける

SharePoint 2010 では、開発者が GET 要求で状態が変化する操作を実行することは禁止されています。たとえば、リスト アイテムまたは Web プロパティが GET を使用してフェッチされている場合、Microsoft ASP.NET ページでリスト アイテムまたは Web プロパティの内容を更新することはできません。

これと __REQUESTDIGEST カナリアの組み合わせにより、CSRF 攻撃を防ぎます。ただし、一部の機能では遅延初期化を実行することが必要な場合があります。

推奨事項

GET 要求で状態が変化する操作を実行する必要がある場合は、最初に機能が適切に動作しているかどうかを検討する必要があります。__REQUESTDIGEST カナリアは CSRF 攻撃から機能を防御するので、状態が変化する操作は POST 要求でのみ実行することをお勧めします。

機能の設計上、状態が変化する操作をどうしても GET 要求で行う必要がある場合は、現在の Microsoft.SharePoint.SPWeb クラスの AllowUnsafeUpdates プロパティを true に設定することで、この検査を無効にできます。次の例で示すように、操作を実行した後でプロパティをリセットし、try-catch-finally ブロックを使用することで例外によってプロパティが true に設定されたままにならないようにしてください。

try
{
   SPContext.Current.Web.AllowUnsafeUpdates = true;
   // State-changing operation occurs here.
}
catch
{
   // Handle or re-throw an exception.
}
finally
{
   SPContext.Current.Web.AllowUnsafeUpdates = false;
}

カナリア検証エラーを回避するために AllowUnsafeUpdates を使用しないでください。ポストバックまたは Web サービス要求でカナリア検証エラーを受け取った場合は、適切にカナリアを送信して検証する必要があります。

SPUtility を使用して異なるページにリダイレクトする

フォームでは、ユーザーが [OK] または [キャンセル] をクリックした後で、異なるページにリダイレクトすることがよくあります。多くの場合、このページの URL はクエリ パラメーター (たとえば Source パラメーター) で渡されます。この URL が検証されない場合、攻撃者はこのパラメーターを使用してユーザーを危険な場所にリダイレクトできます。

推奨事項

ユーザーを別のページにリダイレクトするには、Microsoft.SharePoint.Utilities.SPUtility.Redirect メソッドを呼び出します。Redirect メソッドは、リダイレクト先の URL が現在のドメイン上にあることを確認し、必要に応じてリダイレクト先が現在の Web ページの別の _layouts ページであることを確認できます。

SharePoint のセキュリティに関するベスト プラクティス: 権限の昇格

権限の昇格は、最初に付与されていたものより高い承認アクセス許可を攻撃者に与えることで発生します。たとえば、"読み取り専用" アクセス許可の権限セットを持つ攻撃者が、何らかの方法で "読み取りと書き込み" を含むようにセットを昇格させるような場合です。

詳細については、「権限の昇格」を参照してください。

ユーザーのアクセス許可を適切に検査する

機能でアクセス許可を自動的に検査できない場合があります。次のような場合です。

• Microsoft.SharePoint.SPSecurity.Elevated RunWithElevatedPrivileges 操作は、ユーザーのアクセス許可に関係なく常に成功します。

• 一部の操作は、SharePoint オブジェクト モデルを使用していない場合、アクセス許可の検査を行わないことがあります。

どちらの場合も、機能では手動でアクセス許可を検査する必要があります。

推奨事項

最初に、アクセス許可を検査する必要のある Microsoft.SharePoint.SecurableObject (SPListItem オブジェクト、SPList オブジェクト、または SPWeb オブジェクト) を決定します。機能が Web に影響を与える場合、セキュリティ保護可能なオブジェクトは現在のコンテキスト Web です。機能がリストごとに動作する場合は、セキュリティ保護可能なオブジェクトは現在のコンテキスト リストです。

次に、ユーザーがアクセス許可を持っていない場合の機能での対応として、特別なアクションを実行するのか (一部のユーザー インターフェイス要素を非表示する、など)、またはアクセスを拒否するのかを決定します。

• ユーザーのアクセス許可に基づいてアクションを実行する必要がある場合は、セキュリティ保護可能なオブジェクトで DoesUserHavePermissions を呼び出し、戻り値を使用します。

  注意

  ユーザーが必要なアクセス許可を持っていない場合、DoesUserHavePermissions メソッドは例外をスローしません。false を返すだけです。

• 機能でアクセス拒否例外をスローする必要がある場合は、セキュリティ保護可能なオブジェクトで Microsoft.SharePoint.SPSecurableObject.CheckPermissions を呼び出します。このメソッドはアクセス拒否例外をスローし、この情報をユーザーに適切に返します。

SPSite オブジェクトを安全に作成する

Microsoft.SharePoint.SPSite コンストラクターでは、次の 2 つの問題がよく発生します。

• 新しい SPSite オブジェクトは、完全修飾ドメイン名 (たとえば http://contoso1.example.com) を使用して作成できます。このドメイン名が現在の要求コンテキストと異なっている場合、クロスドメイン セキュリティの問題が発生する可能性があります。

• 新しい SPSite オブジェクトは、サイト識別子 (ID) とオプションのユーザー トークンを使用し、完全修飾 URL または Microsoft.SharePoint.Administration.SPUrlZone 列挙を使用しないで作成できます。現在の要求コンテキストが Default ゾーンではない場合、これにより Web アプリケーション ポリシーをバイパスできます。

推奨事項

サイト ID とユーザー トークンだけを使用して、SPSite オブジェクトを作成しないでください。代わりに、Microsoft.SharePoint.Administration.SPUrlZone 列挙子の値またはサイトの完全修飾ドメイン名を渡すようにします。

ユーザーから提供された GUID または完全修飾ドメイン名を使用して新しい SPSite オブジェクトを作成する場合は、Microsoft.SharePoint.SPSite.ValidateDomainCompatibility を呼び出す必要があります。次の例に示すように、このようにすることで、新しい SPSite のドメイン名が現在の要求コンテキストのドメイン名と同じであることを確認します。

String siteUrl = Page.Request.QueryString["site"]; 
// This can be a fully qualified domain names (FQDN), for example,
// http://contoso/sites/example.
 
if (!SPSite.ValidateDomainCompatibility(SPContext.Current.Site.Url, siteUrl))
{
   // If the domain of siteUrl differs from the current context, block cross-domain operations.
   throw new UnauthorizedAccessException();
}

SPSite オブジェクトの安全な作成に関する追加情報

あるドメイン (たとえば https://contoso.com) のスクリプトは、他のドメイン (たとえば http://wingtip.com) 上のデータにアクセスできません。これは同一生成元ポリシーと呼ばれます。

ただし、両方のドメインが同じファームでホストされている場合、SharePoint オブジェクト モデルは両方のドメインにアクセスできます。Microsoft.SharePoint.SPSite.ValidateDomainCompatibility を使用して遮断しない場合、攻撃者はこれを悪用して異なるドメインのデータにアクセスできます。

それとは別に、ファーム管理者は、Web アプリケーション ポリシーを使用することで、Web サイトの異なるゾーンごとに異なるアクセス許可をユーザーに付与できます。たとえば、サイトの既定ゾーンでは フル コントロール をユーザーに付与し、インターネット ゾーンに対しては 読み取り アクセスだけを許可できます。

Microsoft.SharePoint.Administration.SPUrlZone 列挙値または FQDN を使用して SPSite コンストラクターにゾーンの情報を渡さない場合、オブジェクト モデルは既定ゾーンが意図されているものとみなします。これにより、前に説明した権限の昇格の問題が発生する可能性があります。

サーバー側 HTTP 要求を慎重に制限する

一部の機能が原因で、ユーザーに代わってサーバーが発信 HTTP 要求を行う場合があります。たとえば、Microsoft Business Connectivity Services (BCS) では、ユーザーは接続するデータベースおよび Web サービスの URL を指定できます。

このような要求はファイアウォールの背後にあって SharePoint を実行しているサーバーから発信されるので、この要求を使用して、データ センター内の他のコンピューターに接続したり、コンピューターを攻撃したりできます。

推奨事項

ユーザーが SharePoint の接続先として任意の URL を指定できないようにします。代わりに、ファーム管理者が安全な URL のリストを構成できるようにします。

または、ユーザーが入力した各 URL を正規のインターネット プロトコル (IP) アドレスに解決し、ファーム管理者が IP とサブネット マスクによってネットワーク範囲を遮断できるようにします (たとえば、192.168.0.0/255.255.0.0)。

昇格されたオブジェクトを RunWithElevatedPrivileges ブロックの内部に留めておく必要がある

サービス アカウントの資格情報を使用してコードのブロックを実行するには、Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges を使用します。この方法は、ユーザーがアクションを直接実行するためのアクセス許可を持たない場合に、ユーザーに代わってアクションを実行するためによく使用されます。

たとえば、ユーザーは新しいサイト コレクションを準備するためのアクセス許可を持たない場合がありますが、SharePoint はユーザーのためにサイトを準備する必要があります。RunWithElevatedPrivileges ブロック内でサイト コレクションを準備することで、アクションは成功します。

一般に、RunWithElevatedPrivileges は次のように使用されます。

SPSecurity.RunWithElevatedPrivileges(delegate()
{
   using (SPSite elevatedSite = new SPSite(SPContext.Current.Site.Id))
   {
      using (SPWeb elevatedWeb = elevatedSite.OpenWeb(SPContext.Current.Web.Id))
      {
         // Perform administrative actions by using the elevated site and web objects.
      }
   }
});

昇格された Microsoft.SharePoint.SPSite オブジェクトおよび Microsoft.SharePoint.SPWeb オブジェクトを使用して作成またはアクセスされた SharePoint オブジェクト モデルのオブジェクトは、作成されたときのアクセス許可を維持します。RunWithElevatedPrivileges ブロックの外側でこのようなオブジェクトを返すと、権限の昇格の問題が発生する可能性があります。

推奨事項

Microsoft.SharePoint.SPSecurity.RunWithElevatedPrivileges オブジェクト内で作成またはアクセスされた SharePoint オブジェクト モデルのオブジェクトは、RunWithElevatedPrivileges ブロックの外側では返さないようにする必要があります。

その他の情報

SPSite オブジェクトをインスタンス化すると、SharePoint では、ネイティブ コード内の基になっている SPRequest オブジェクトによってそのオブジェクトをバックアップします。SPRequest オブジェクトは、オブジェクトをインスタンス化したユーザーについての情報を保持しています。SPRequest オブジェクトは、その SPSite オブジェクトによってアクセスされるすべてのオブジェクトで共有されます。

注意

SPRequest オブジェクトの詳細については、「オブジェクトの破棄」を参照してください。

SPSite オブジェクトが RunWithElevatedPrivileges ブロック内で準備されるとき、SPRequest オブジェクトは現在のユーザーがシステム アカウントであることを記録します。SPSite オブジェクトが Microsoft.SharePoint.SPListItem オブジェクトへのアクセスに使用された場合、そのリスト アイテムは同じ SPRequest オブジェクトを共有します。これは、SPSite オブジェクトと同じように "昇格された" オブジェクトです。

SPListItem オブジェクトが RunWithElevatedPrivileges ブロックの外部で渡される場合は、基になっている SPRequest オブジェクトを保持し、昇格された状態が続きます。現在のユーザーの資格情報で実行することを想定しているコードでは、この SPListItem オブジェクトを使用した場合、権限の昇格の問題が発生します。

SharePoint のセキュリティに関するベスト プラクティス: サービス拒否

サービス拒否は、システムの負荷が高くなり、メッセージを処理できない、またはメッセージの処理が非常に遅い状態になると発生します。詳細については、「サービス拒否」を参照してください。

1 回の要求で実行できる処理の量を制限する

一部の機能は、ユーザー入力を解析し、要求内の各要素に対するアクションを実行します。機能で解析する要素の数を制限しないと、サービス拒否攻撃が発生する可能性があります。

推奨事項

1 回の要求で機能が処理するユーザー入力の数に、妥当な上限を適用します。

SharePoint のセキュリティに関するベスト プラクティス: 情報流出

情報流出があると、攻撃者はシステムについての重要な情報を取得できます。したがって、公開している情報の内容、およびそれが悪意のあるユーザーに使用されても問題ないかどうかを、常に検討する必要があります。

詳細については、「情報の漏えい」を参照してください。

Web サービスの例外を呼び出し元に返す前に不適切な情報を除去する

Web サービスの呼び出しでスローされる例外によって、サーバーについての過剰なデータが返される場合があります。たとえば、内部サーバー名やファイル システム パスなどです。

攻撃者はこの情報を使用して SharePoint ファームを分析し、対象を絞った攻撃を実行できます。

推奨事項

次の例に示すように、SOAP Web メソッドを実装するときは、すべての例外をキャッチし、ユーザーに返す前に SoapServerException.HandleException に渡します。

try 
      {
          return new SoapXml.SoapXmlElement(
              m_ListSchemaImpl.GetListAndView(listName, viewName));
      } 
      catch (Exception e) 
      {
          throw SoapServerException.HandleException(e);
 
      }

まとめ

この記事では、SharePoint 2010 を使用してソリューションを開発するときの推奨されるセキュリティに関するベスト プラクティスについて説明しました。推奨事項では、クロスサイト スクリプティング (XSS)、クロスサイト リクエスト フォージェリ (CSRF または XSRF)、権限の昇格、サービス拒否、情報流出などについて説明しました。

参考資料

詳細については、次のリソースを参照してください。

• Forms Authentication in SharePoint Products and Technologies (Part 1): Introduction

• Steve Peschka のブログ: Share-n-dipity(英語)

• セキュリティのコマンドレット (SharePoint Foundation 2010)

• セキュリティ ブログ、リソース センター、および SharePoint フォーラム

• クレームに関するヒント 1 : SharePoint 2010 のクレームベース認証についての説明

• クレームに関するヒント 2 : SharePoint 2010 のクレームベース認証についての説明

• クレームに関するチュートリアル: SharePoint 2010 のクレーム プロバイダーを記述する

• クレームに関するチュートリアル: SharePoint 2010 の信頼済みログイン プロバイダー用のクレーム プロバイダーを作成する

• クレームに関するチュートリアル: ASP.NET SQL のメンバーシップ プロバイダーとロール プロバイダーを使用したクレーム ベースの SharePoint 2010 Web アプリケーション用のフォーム ベース認証の作成

• クレームに関するチュートリアル: SharePoint 2010 における信頼済みログイン プロバイダー (SAML サインイン) の作成

• Microsoft SharePoint 2010 のクレーム プロバイダー

• 受信クレーム: SharePoint にサインインする

• クレームベース ID の用語の定義

• Microsoft.SharePoint.Administration.Claims

• 計画、アップグレード、移行、管理、構成、およびセットアップ

• SharePoint 2010 でのセキュリティに関するビデオ プレゼンテーション(英語)

• SharePoint 2010 Advanced Developer Training

• Security Resource Center | SharePoint 2010(英語)

• SharePoint デペロッパー センター