進行状況の追跡を始めよう
Trailhead のホーム
Trailhead のホーム

Lightning セキュリティの使用開始

メモ

メモ

Trailblazer の皆さん!

Salesforce には Lightning Experience と Salesforce Classic の 2 種類のデスクトップユーザインターフェースがあります。このモジュールは Lightning Experience 向けです。

インターフェース間の切り替え、Lightning Experience の有効化などについての詳細は、Trailhead の「Lightning Experience の基本」モジュールを参照してください。

学習の目的

この単元を完了すると、次のことができるようになります。

  • セキュアな Lightning コンポーネントの開発とセキュアな Visualforce ページの開発はどう違うかを説明する。
  • Lightning Locker で適用されるセキュリティ保護について要約する。
  • セキュリティテストを実行する特別な Developer Edition 組織にサインアップする。

Lightning セキュリティアーキテクチャ

Lightning は多くの期待を集めています。それは Salesforce Platform の未来であり、Visualforce と比べ複数の改良点が提供されています。最適なユーザエクスペリエンスをどう提供するか、顧客データをどう保護するかに影響する多くの変更が内部的に加えられています。

このモジュールでは、Lightning に組み込まれたセキュリティの利用方法について説明します。内容は、「Lightning Experience 向けの開発」 トレイルの概念に基づいて作成されています。このトレイルのモジュールをまだ終了していない場合は、まずそちらに取り組んでください。

メモ

メモ

Spring '19 リリース (API バージョン 45.0) では、Lightning Web コンポーネントモデルと従来の Aura コンポーネントモデルの 2 つのプログラミングモデルを使用して Lightning コンポーネントを作成できます。Lightning Web コンポーネントと Aura コンポーネントは、ページ上に共存可能で、同時に使用できます。このコンテンツでは、Aura コンポーネントについて説明します。 

Lightning Web コンポーネントについての詳細は、「Introducing Lightning Web Components (Lightning Web コンポーネントの概要)」を参照してください。

Lightning コンポーネントフレームワークでは、UI とコンポーネントがイベントに応答することで互いに通信します。コンポーネントはサーバや他のコンポーネントとやりとりできます。各コンポーネントは、Lightning 環境内で各自のセキュリティの責任を負います。つまり、コンポーネントの作成やメンテナンスの担当者はすべて、Lightning でセキュアなコードを記述する方法を理解する必要があります。

Aura と Visualforce の比較

Aura と Visualforce のセキュリティ処理方法は異なります。Visualforce で多くの作業をしたことがあれば、これらの違いを理解しやすいでしょう。セキュリティの観点では、Visualforce と Aura には、共有リソース、カプセル化、データセキュリティという 3 つの主要な違いがあります。

共有リソース 

Visualforce では、完全なページを作成し、ページの素材を再利用するのは困難です。Aura では、基本的なビルディングブロックは、再利用可能で簡単に交換できるコンポーネントです。コンポーネントを使用する Aura アプリケーションは、ページ内でそのコンポーネントを複数回インスタンス化できます。 

Aura アプリケーションでは、Lightning ユーザインターフェースのすべてのコンポーネントは同じページに読み込まれるため、再利用できます。これらのコンポーネントは、グローバルウィンドウや JavaScript インタープリタなどの主要なリソースを共有します。JavaScript アラートやグローバルコールなど、ウィンドウ全体を制御する関数を使用する場合、または、多くの JavaScript 処理が必要なコードを記述する場合は、同じウィンドウの他のコンポーネントに影響を与えるので慎重に行ってください。

カプセル化 

Salesforce では、Aura フレームワーク外のページにあるコンポーネントの変更を試みるコードはサポートされていません。コンポーネント内のデータをその属性、メソッド、Aura フレームワークメソッドを使用せずに変更するものはサポートされません。この種のコードは、アプリケーションの不安定性や脆弱性につながります。

データセキュリティ

Visualforce では、ページに Salesforce オブジェクトが表示されるとき、有効なユーザの CRUD および FLS 権限が適用されます。Aura では、クライアント側の認証は行わないため、これらの権限は考慮されません。次のコードは、参照権限がないユーザも含め、すべてのユーザにデータを表示します。

<b>Hello <i>{!v.User.FirstName}</i>.</b>


Aura コンポーネントを記述するときには、Apex コントローラで独自にデータアクセスチェックを行います。

コンポーネントインターフェースの保護

Aura コンポーネントは非常に強力です。データの表示などの操作は難なく実行でき、レコードの作成や変更など、より複雑な操作もできます。コンポーネントは、Aura の属性とメソッドを使用して互いにやりとりします。Aura を使用することで、作成した属性とメソッドにアクセスできるユーザを制御できます。アクセス制御については後の単元で取り上げます。ここでは、アクセス制御を使用できることだけを覚えておいてください。 

サーバ側の操作を実行する場合は、そのアクションの Apex ハンドラを記述します。そのためには、Apex で @AuraEnabled アノテーションを付加して関数を記述します。別のコンポーネントがサーバ側の Apex 関数をコールしないようにするには、各 @AuraEnabled メソッドでユーザに標準のアクセス制御 (CRUD/FLS/共有) を使用します。

具体的な操作を実行するコンポーネントを記述する

当然のことながら、悪意のある入力に対してそれぞれのコンポーネントを保護する必要があります。世の中には多くの悪者がいるので、コンポーネントで処理する入力はどれも信頼できません。とはいえ、悪意のある入力をはどう識別すればよいのでしょうか? 

自問しましょう。コンポーネントには具体的な目的がありますか? コンポーネントで処理する入力はどのようなものですか? それをどう使用しますか? 良い入力がどのようなものかが明確であるほど、その定義に合わないものに対する保護を適切に行えるようになります。 

過度に汎用的なコンポーネントは保護が難しくなります。コンポーネントの処理が「入力を表示」のように大まかだと、入力が良いか悪いかがわかりません。以下は汎用的なコンポーネントの例です。

<aura:component access="global"> 
<aura:attribute name="iframeURL" type="string" access="global" /> 
<iframe src="{!v.iframeUrl}" /> 
</aura:component>

この iframe はどこで発生したのでしょうか? どこで発生すべきかがわかっていれば、そのドメインをホワイトリストに登録し、他のソースからのフレームをブロックできます。ただし、他の開発者がその汎用的なコンポーネントを使用して別のものを表示しようとする場合、ホワイトリストは新しい使用事例では機能しないかもしれません。 

多機能で汎用的なコンポーネントではなく、具体的な使用事例のためのコンポーネントを作成します。具体的なコンポーネントであれば、その仕様からセキュリティ要件がわかりますが、汎用的なコンポーネントでは不正な入力に対する保護方法の判断が難しくなります。 

Lightning Locker

Lightning Lockerは、Salesforce の Aura コンポーネント用セキュリティアーキテクチャです。Lightning Locker は個々の Aura コンポーネントを独自のコンテナ内に分離し、Aura の属性やイベントなど、フレームワークで提供されるツールを使用しない限り、互いに直接やりとりできないようにします。 

このコンポーネントレベルの分離によって、アプリケーションは他の開発者が作成した悪意のあるコンポーネントから保護され、明示的に宣言したやりとりのみが許可されます。 

Lightning Locker は、コンポーネントに明示的なセキュリティ対策も提供します。たとえば、コンテンツセキュリティポリシー (CSP) は、クロスサイトスクリプティング (XSS) 攻撃とリソース制限を抑制して画像とスクリプトがセキュアに読み込まれるようにします。

Lightning Locker にはソフトウェアエンジニアリングに関するオプションもあります。これにより、サポートされる API へのアクセスのみを許可し、公開されていないフレームワーク内部を隠すことで、コードでサポートしやすくなります。Lightning Locker はまた、すべての JavaScript コードに厳格モードを適用することで、コード関連の劇的な事象を最小限に抑えます。劇的なことが起きなくても仕事は十分面白いですよね。

厳格モードの JavaScript

ブラウザで実行される JavaScript コードは、ユーザの個人情報にアクセスできます。この情報を保護するために、Lightning Locker では ECMAScript (ES5) 厳格モードの使用が義務付けられ、コードにも適用されます。このモードにより、セキュアな JavaScript を記述しやすくなります。少しコードを調整して ES5 に準拠することで、実行時のデータチェックの必要性が大幅に低下します。

次の簡単な例は、厳格モードで JavaScript によるコールスタックのトラバースや他の関数の変更を防ぐ方法を示しています。厳格モードなしだと、次の関数は primaryFunction() をコールした関数の名前を返します。 

JavaScript コード:

function primaryFunction() { 
  'use strict' 
  console.log("The function calling the current method is: “+ primaryFunction.caller.name); 
} 
function callerFunction() { 
  return primaryFunction(); 
} 
callerFunction();

出力:

  Uncaught TypeError: 'caller' and 'arguments' are restricted function properties and cannot be accessed in this context. 
  at primaryFunction (<anonymous>:3:72) at callerFunction (<anonymous>:6:10) at <anonymous>:8:1

厳格モードでは、他の複数のエンティティへのアクセスが制限されます。たとえば、厳格モードが適用されると、JavaScript 変数 this を使用して window オブジェクトを参照できなくなります。こうした制限により、多くの潜在的なセキュリティ脆弱性が排除されます。 

コンテンツセキュリティポリシー (CSP)

Salesforce のコンテンツセキュリティポリシーでは、コード内のインライン JavaScript と JavaScript eval 関数を禁止しています。これにより、クロスサイトスクリプティングのような攻撃に対してコンポーネントを保護できます。Salesforce Lightning CLI ツールを起動し、コードとその連動関係を検索して、この機能を使用しているものがあるか確認します。見つかったコールをすべて削除します。いずれかのライブラリがインライン JavaScript またはローカルスコープで eval を使用している場合、変更するか、CSP で機能する別のライブラリを探すことが必要になる可能性があります。

メモ

メモ

CSP が適用されないブラウザもあります。たとえば、Internet Explorer 11 は CSP を使用しません。CSP が適用されるブラウザのリストについては、「Can I use...Content Security Policy」(コンテンツセキュリティポリシーを使用可能なブラウザ) を参照してください。

Developer Edition 組織で学ぶ

Trailhead の Challenge に取り組むにはハンズオン組織を使用します。この組織は、Aura コンポーネントのセキュリティ脆弱性の修正を練習できる安全な環境です。このトレイルのすべてのモジュール用に特別な組織 Kingdom Management 開発者組織が作成されています。この組織には、複数の脆弱なアプリケーションが含まれているため、自分で脆弱な Force.com コードを書かずに、その時間をセキュリティスキルの向上に投じることができます。

各 Challenge の目的はシンプルです。脆弱性を識別して修正することです。これらの Challenge には Kingdom Management 開発者組織を使用します。既存の Developer Edition 組織や Trailhead Playground 組織をこのトレイルのモジュールに使用することはできません。

Kingdom Management Developer Edition 組織にサインアップする手順は、次のとおりです。Summer '19 リリースに合わせて、この Developer Edition 組織がアップグレードされている可能性があります。このバッジに記載されているスクリーンショットや手順の一部が、組織に表示されるものと一致しないことがあります。

  1. Kingdom Management 開発者組織のカスタムサインアップページに移動します。
  2. 有効なメールアドレスを使用してフォームに入力し、[サインアップ] をクリックします。

    サインアップページのスクリーンショット




  3. 有効化を要求するメールを確認します。
  4. メールのリンクをクリックし、新しいパスワードと確認の質問を設定して登録を完了します。

Kingdom Management 開発者ユーザ名とパスワードを設定したら、アプリケーションセキュリティを使用してユーザやデータを保護する方法を学ぶ準備が整います。

メモ

メモ

Kingdom Management アプリケーションのコードは、特定の攻撃に対して脆弱です。これらの脆弱性が Developer Edition 組織に損害を与えることはありませんが、本番の Salesforce 環境に入り込むと大混乱を引き起こすおそれがあります。Kingdom Management アプリケーションは、セキュリティと脆弱性について学習するためにだけ使用してください。

次の単元では、HTML/Aura マークアップを使用してセキュアな Lightning コンポーネントを作成する方法を学習します。

リソース

Aura フレームワーク

Lightning コンポーネントフレームワークとは?

Introducing the Lightning Locker for Lightning Components (Lightning コンポーネント用の Lightning Locker のご紹介)

Lightning Aura Components Developer Guide (Lightning Aura コンポーネント開発者ガイド)

ECMAScript 厳格モード

クロスサイトスクリプトについて

ECMAScript 5