Salesforce CRM サービスプラットフォームのセキュリティに関する FAQ

セキュア Cookie
データ検証
クリックジャック攻撃
クロスサイトリクエストフォージェリ
クロスサイトスクリプティング
ファイルのアップロード
任意の SQL クエリの実行
FRONTDOOR.JSP SID
JSESSIONID
HTTP ヘッダー
その他

セキュア Cookie

salesforce.com ドメインから提供される特定の Cookie がセキュアまたは永続的として設定されていないのはなぜですか?
プラットフォームが機能強化を目的として使用する Cookie がいくつかあり、このような Cookie にはセッション情報が含まれていません。これらの Cookie は攻撃者によって変更されたりアクセスされたりした場合でも、アクセス権の取得や特権昇格に使用できません。セッション Cookie「sid」はセキュアおよび非永続的としてマークされます (つまり、ユーザーがブラウザーを閉じると、この Cookie は削除されます)。

セッション Cookie が HTTP Only フラグ付きで設定されないのはなぜですか?
組織に HTTPOnly Cookie を必須として設定できます。設定するには [設定] | [セキュリティのコントロール] | [セッションの設定] | [HttpOnly 属性が必要] を有効にします。これにより、SID セッション Cookie にのみ HttpOnly 属性が設定されます。

データ検証

特定の入力項目のデータがオブジェクトで保存されるまでサーバー側で検証されないのはなぜですか。
このようなデータ検証または品質に関する問題はセキュリティには該当しません。大半のデフォルトのデータ検証ルールや品質ルールはクライアント側で適用されます。

この例として、API 経由で選択リスト値を未定義の値に更新したり、標準ページ編集の POST を変更したりすることが挙げられます。

サーバー側で適用されるデータ検証ルールの例:

存在しないレコード ID へのルックアップ ID の設定
項目のデータ型 (たとえばテキスト値を含む数値項目は設定できません)
オブジェクト検証ルールまたは Apex トリガーでの、明示的なデータ検証ルールの設定

クリックジャック攻撃

プラットフォームにはクリックジャック攻撃防止機能がありますか?
クリックジャック攻撃防止機能は [設定] | [セキュリティのコントロール] | [セッションの設定] で有効にできます。この設定はすべての [Salesforce の設定] ページでデフォルトで有効になっています。

サイトのクリックジャック攻撃防止機能は次のいずれかのレベルに設定できます。

すべてのページでフレーム化を許可 (保護なし)
公開元が同じページでのみフレーム化を許可 (推奨)
すべてのページでフレーム化を許可しない (最大の防止)

Salesforce コミュニティには次の 2 つのクリックジャック攻撃防止機能があります。

Force.com コミュニティサイト (Force.com サイトの詳細ページで設定)
Site.com コミュニティサイト (Site.com 設定ページで設定)。両方を同じ値に設定することをお勧めします。

詳細は、クリックジャック攻撃防止機能の有効化に関するドキュメントを参照してください。

クロスサイトリクエストフォージェリ

プラットフォームにはクロスサイトリクエストフォージェリ (CSRF) 攻撃防止機能がありますか?
CSRF 攻撃防止機能はデフォルトで有効になっています。設定の確認や変更は [設定] | [セキュリティのコントロール] | [セッションの設定] で行うことができます。

Salesforce CSRF トークンが再利用されるのはなぜですか?
CSRF トークンのスコープは特定のユーザー、操作対象エンティティ、セッションに限定され、ユーザーのセッション内で再利用されます。

トークン自体はランダムに生成されるため、攻撃者に推測されることはありません。攻撃者にとって、ユーザーのセッション ID を取得するのは CSRF トークンを取得するのと同じくらい難しいと言えます。

クロスサイトスクリプティング

プラットフォームにはクロスサイトスクリプティング攻撃防止機能がありますか?
すべての標準ページでは、ユーザー制御データが使用される適切なコンテキストで出力エンコードされます。Visualforce ページの場合、すべての差し込み項目がデフォルトで HTML エンコードされます。

カスタム Visualforce ページに起因するクロスサイトスクリプティングへの脆弱性には、ベストプラクティスの推奨を採用したり、開発者向けに提供されるツールを使用したりして対処する必要があります。

Apex および Visualforce では他のコンテキスト用に追加のエンコードユーティリティが用意されています。html 以外のコンテキストの適切な出力エンコードについては開発者の責任となります。

詳細は、クロスサイトスクリプティング (XSS) に対する Apex および Visualforce のガイドラインに関するドキュメントを参照してください。

データをオブジェクトに保存する際に、クロスサイトスクリプティング攻撃防止のためのデータの入力エンコードが行われないのはなぜですか?
プラットフォームではユーザー制御データ用に、コンテキスト固有の出力エンコード機能が実装されています。Salesforce データはさまざまなコンテキストやシステムで表示される可能性があり、入力時にデータの適切なコンテキストを予測するのは難しい課題です。

標準ページは、データが表示される適切なコンテキストでデータを適切にエンコードするよう作られています。入力エンコードが必要な場合は、目的のオブジェクトまたは項目にカスタムトリガーを実装して入力エンコードが行われるようにしてください。

ファイルのアップロード

悪意のあるユーザーによりアップロードされたファイルには悪意のある内容が含まれている可能性があり、そのようなファイルがウイルス対策ソフトウェアで悪意のあるファイルとして検出されないと、ファイルをダウンロードしたユーザーが危険にさらされる可能性があることを Salesforce は認識しています。

また、Salesforce AppExchange にあるサードパーティのスキャン製品を活用して、Salesforce でアップロードまたはダウンロードしたファイルをスキャンすれば、エンドポイントのセキュリティを強化できます。

特定のファイル種別や、アップロードまたはダウンロードの動作の管理は、[設定] | [セキュリティのコントロール] | [ファイルのアップロードおよびダウンロードセキュリティ] で行うことができます。その他のファイル種別については、関連オブジェクトのカスタム Apex トリガーにより、アップロードされるファイル拡張子を制限できます。

保存されているファイルには、悪意のある内容がないかどうかのスキャンは行われますか?
ファイルには、悪意のある内容がないかどうかのスキャンは行われません。Salesforce サーバーではデータはバイナリ形式で保存されます。特定のファイル種別は検索インデックス化またはプレビュー表示用に解析されますが、これは限定的権限を使用して分離された環境で実行されるよう制御されています。

次のようなリソースも参考になります。

ファイルのアップロードおよびダウンロードのセキュリティ設定の定義 - ドキュメント
ファイルのアップロードおよびダウンロードのセキュリティ設定の定義 - 追加情報

ファイルと添付ファイルは独自の方法でサービス内に保存されています。この保存方法により、感染したファイルがアップロードされた場合でも、残りのサービスやその他のファイルに一切影響はありません。このように Salesforce はプラットフォームの保護に尽力していますが、Salesforce ではお客様のエンドポイントを制御することはできません。お客様の責任において、エンドポイントに最新のウイルス対策保護を適用するよう徹底してください。

アプリケーション層はマルチテナントモデル経由でインフラストラクチャ層から抽象化されています。このため、ここでは Salesforce が管理および保護するインフラストラクチャ層と、ユーザーが任意のファイルを安全な方法でアップロードできるアプリケーション層という 2 つの異なる部分について話していますが、Salesforce ではユーザーが感染したファイルをアップロードするかどうかを制御できません。感染していることを認識しているファイルを意図的にアップロードするかどうかについても同様です。

任意の SQL クエリの実行

検索結果には SQL ではなく SOQL が含まれるため、セキュリティへの影響はありません。

このリクエストは REST API への呼び出しです。これにより、組織の管理者が設定したアクセスコントロール設定に基づいて、ユーザーがアクセス権を持つオブジェクトと項目をユーザーがクエリできるようになります。

REST API は共有、CRUD、FLS などの適切なアクセス権を適用します。このため、ユーザーがアクセス権を持っていないものについてはユーザーに一切表示されません。秘密、機密情報、攻撃者にとって有用な情報も表示されません。

REST API と SOQL クエリについての詳細は、以下を参照してください。

FRONTDOOR.JSP SID

login.salesforce.com 経由で使用される FRONTDOOR.JSP SID は一時セッションであり、ログイン時に使用することはできません。Salesforce は API 経由で frontdoor.jsp?sid=<sessionid> を介してログインできることを認識しています (一時セッション ID は使用できませんが、ログイン時に作成された SID は使用できます)。

この動作に関するドキュメントについては、「Frontdoor.jsp を使用した既存のセッションから Salesforce へのアクセス」を参照してください。

JSESSIONID

JSESSIONID は一時セッション ID であり、Cookie が悪用されることはありません。メインのセッション Cookie は SID であり、安全です。

HTTP ヘッダー

X-Content-Type-Options: no sniff
HTTP ヘッダーは各組織が [設定] | [セキュリティのコントロール] | [セッションの設定] | [コンテンツ盗聴保護を有効化] でオンまたはオフに切り替えることができます。

ブラウザーはサーバーにより返されたコンテンツタイプヘッダーを無視して、ボディレスポンスの実際のコンテンツからコンテンツタイプを推測する可能性があります。これを利用して、ブラウザーに悪意のある JavaScript または CSS を強制的に実行させることができます。

HTTP ヘッダー X-Content-Type-Options: nosniff はブラウザーがファイルのコンテンツや埋め込みタグを基にファイルの種類を推測するのを防ぎます。ブラウザーはサーバーから送信されたコンテンツタイプに従います。

ディレクティブ: referrer

Aloha のみ
このディレクティブは Salesforce からサードパーティのドメインに移動するときに、完全な URL ではなく Salesforce ドメインのみを Referrer ヘッダーに含めることを示します。これにより、画像やスクリプトなどのアセットを読み込んだり、リンクをクリックしたりするときに URL から他のサイトに秘密情報が漏れないようにすることができます。

Referrer: https://domain.my.salesforce.com/page.jsp?oid=XXXXXX&secret=YYYYY becomes Referrer: https://domain.my.salesforce.com

Referrer ヘッダーは同じドメイン内では変更されません。

HTTP 公開鍵ピンニング

公開鍵ピンニング (HPKP) を使用すると、Web サイトはサーバーに送信される HPKP ヘッダーでこの Web サイトの有効な証明書のリストを宣言できます。HSTS と同様、この情報は HPKP ヘッダーで指定した期間に有効になります。

HPKP ヘッダーにはチェーン内の SSL 証明書のすべての有効な公開鍵のハッシュが含まれます。CSP と同様、違反のみを報告したり一致しない証明書をブロックしたりできます。

Salesforce ではレポート専用モードで HPKP を使用します。証明書がどの PIN とも一致しない場合、コンテンツはブロックされません。

コンテンツセキュリティポリシー (CSP) - レポート作成

Aloha のみ
Content-Security-Policy-Report-Only レスポンスヘッダーの使用により、Salesforce はサードパーティのアセットの使用をモニタリングして、HTTPS Web サイトで読み込まれた HTTP コンテンツを検出できます。

このヘッダーはポリシーを定義します。ポリシーは各ページでブラウザー (Chrome、Firefox、Safari。Internet Explorer は除く) によりチェックされますが、強制はされません。ブラウザーは各ポリシー違反について Salesforce にレポートを送信します。このヘッダーはすべてのページでデフォルトで有効になっています (Aloha の場合)。Lightning では独自の CSP を強制します。

コンテンツセキュリティポリシーはいくつかのディレクティブで構成されています。Aloha では、ディレクティブは画像や Web フォント、スタイルシートなどのアセットが HTTPS を介してまたはインラインで読み込み可能であることを示します。

frame-ancestor ディレクティブは salesforce.com および force.com のみを Salesforce サービスの IFRAME に含める必要があることを示します。

HTTP Strict Transport Security (HSTS)

HSTS は login.salesforce.com、MyDomain、Lightning + コンテンツドメイン、Visualforce、コミュニティのサブドメイン、コミュニティ以外のサイトサブドメインで有効になっています。

すべてのサイトおよびコミュニティの HSTS を有効にするには [設定] | [セキュリティのコントロール] | [セッションの設定] | [セキュアな接続 (HTTPS) が必要なデフォルトの force.com サブドメインを持つすべてのサイトおよびコミュニティで HSTS を有効化] を選択します。

すべてのカスタムドメインの HSTS を有効にするには [設定] | [ドメイン管理] | ドメイン名をクリック | [Strict Transport Security ヘッダーを有効化] を選択します。

X-FRAME Options ヘッダー

お客様はサードパーティのサイトで Salesforce IFRAME を含めないようにすることができます。それには [セキュリティのコントロール] | [セッションの設定] | [クリックジャック攻撃防止] の [Prevent Clickjacking] (クリックジャック攻撃の防止) を有効にします。

すべての Visualforce ページに対してこの機能を有効にすることをお勧めします。

その他

キャッシュ: プラットフォームからの特定の HTTP 応答がブラウザーによりキャッシュされるのはなぜですか? (Cache-Control が「非公開」に設定されている)
Salesforce ではパフォーマンスの理由によりキャッシュしており、これは HTTP ヘッダーキャッシュ応答ディレクティブにより制御されます。ここでの主なセキュリティ問題は、攻撃者がローカルクライアントマシンへのアクセス権を取得した場合です。

このシナリオでキャッシュに保存されたデータへのアクセスを軽減するには、リクエストをキャッシュしないようユーザーのブラウザーを設定します。 Salesforce ではキャッシュに保存されるコンテンツに基づいて、特定のページまたはリソースをキャッシュすべきか否かを個々の状況に応じて確認します。

Salesforce は RC4 と 3DES の暗号の使用を廃止しますか?
HTTPS の RC4 と 3DES の暗号についてはサポートを終了しました。