Salesforce アプリケーションは、共有ルールを使用して、ユーザー権限とデータベース レコードへのアクセスを制御します。ただし、Apex クラスは、ルールの適用方法を変えるさまざまな共有キーワードを使用して宣言できるため、ユーザー共有ルールが Apex で常に適用されるわけではありません。クラスは、次の 3 つの異なる共有キーワードのいずれかで宣言できます。

- with sharing: ユーザー共有ルールが適用されます。
- without sharing: 共有ルールは適用されません。
- inherited sharing: 呼び出し元のクラスの共有ルールが適用されます。呼び出し元のクラスで共有キーワードが指定されていない場合、またはクラス自体が Visualforce コントローラーなどのエントリポイントである場合、デフォルトでユーザー共有ルールが適用されます。

共有キーワードが宣言されていない場合、クラスは呼び出し元のクラスの共有モードを継承します (ある場合)。そうしないと、共有ルールが適用されません。

例 1: 次の 3 つのすべての Apex クラスには、データベース クエリ呼び出しについて安全でない共有キーワードがあります。

    public class MyClass1 {
        public List<Contact> getAllTheSecrets() {
            return Database.query('SELECT Name FROM Contact');
        }
    }

    public without sharing class MyClass2 {
        public List<Contact> getAllTheSecrets() {
            return Database.query('SELECT Name FROM Contact');
        }
    }

    public inherited sharing class MyClass3 {
        public List<Contact> getAllTheSecrets() {
            return Database.query('SELECT Name FROM Contact');
        }
    }

MyClass1 と MyClass2 はどちらも安全ではありません。ユーザー共有ルールを強制しなくてもレコードを取得できるためです。

MyClass3 の方が、デフォルトで共有ルールが適用されるため、より安全です。ただし、関数 getAllTheSecrets() が、without sharing を明示的に宣言するクラスで呼び出されると、不正アクセスが許可される可能性はあります。

単一の <security constraint> 要素は、プログラムがロールベースのアクセス制御を採用していないことを示しています。これは、安全な Web アプリケーションで機密性の高い操作を保護するため、一般的に受け入れられているベスト プラクティスです。アプリケーションが機密性の高い操作やデータへのアクセスを提供している場合に、権限のないユーザーによるアクセスを防ぐための十分な制御策が講じられていないことがあります。さらに、<url-pattern> にワイルドカード (*) が含まれている場合、パターンが広すぎることを示している可能性があります。

AccessibleObject API によって、プログラマは Java アクセス指定子によって行われる Access Control チェックを回避できます。特に、これによってプログラマは、反映されたオブジェクトが Java Access Control を迂回することでプライベートフィールドの値を変更するかまたはプライベートメソッドを呼び出せるようにすることができます。通常これらは許可されない挙動です。

多くのアプリケーションは、cookie を使用してユーザーのセッション ID を伝達します。アプリケーションが HTTPS 経由でアクセスされる場合、cookie は保護されます (攻撃者は cookie を盗聴できません)。ただし、開発者が、アプリケーションの機密性の低い部分への HTTP アクセスを許可すると、セッション ID が盗まれる可能性があります。ユーザーがサイトの保護されていない部分を閲覧すると、セッション ID を含む cookie が平文で送信されます。攻撃者は、トラフィックの盗聴時にセッション ID を閲覧し、それを使用してユーザーのセッションを制御します。


次の例は、安全でないチャネルと安全なチャネルが混在した設定を示しています。

  <property name="filterInvocationDefinitionSource">
    <value>
      CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
      \A/secure/.*\Z=REQUIRES_SECURE_CHANNEL
      \A/acegilogin.jsp.*\Z=REQUIRES_SECURE_CHANNEL
      \A/j_acegi_security_check.*\Z=REQUIRES_SECURE_CHANNEL
      \A.*\Z=REQUIRES_INSECURE_CHANNEL
    </value>
  </property>

Acegi Security では、セキュア オブジェクトのコールバック フェーズ中に、SecurityContext の Authentication オブジェクトを一時的に置き換えることができます。これは、元の Authentication オブジェクトが AuthenticationManager および AccessDecisionManager によって正常に処理された場合にのみ発生します。RunAsManager はこの認証オブジェクトを作成します。
通常開発者は、メソッド呼び出しの間、RunAsManager を使用して、認証済みユーザー用に 1 つ以上の追加のロールを設定します。これは、リモート アプリケーションへのアクセスが必要なセキュア Bean に役立ちます。リモート アプリケーションは異なる資格情報を要求する場合があるため、これにより、呼び出し元のロールとリモート アプリケーションに必要なロールを変換して、リモート アクセスを成功させることができます。新しい Authentication オブジェクト (RunAsUserToken と呼ばれる) は、それ以上の認証または承認のチェックを受けずに、有効な Authentication オブジェクトとしてそのまま受け入れられます。
新しい Authentication オブジェクトに新しいロールまたは特権を追加すると、ユーザーの特権が一時的に引き上げられ、ユーザーが不正なアクションを実行できるようになる可能性があります。
次の設定は、RunAsManager を使用してロール "ROLE_PEON" を持つユーザーにロール "UBER_BOSS" を追加することで、このユーザーの権限を一時的にマネージャー特権に引き上げます。これにより、すべての Peon が PrivateCatalog からデータを取得できるようになります。

<bean id="bankManagerSecurity" class="org.acegisecurity.intercept.method.aopalliance.MethodSecurityInterceptor">
...
 <property name="objectDefinitionSource">
   <value>
     com.example.service.PrivateCatalog.getData=ROLE_PEON,RUN_AS_UBER_BOSS
...
   </value>
 </property>
</bean>

デフォルトでは、Fusion アプリケーションのタスク フローは GET リクエストから直接アクセスできません。URL がタスク フローを呼び出そうとするたびに、HTTP 403 ステータス コードを受け取ります。しかし、暗黙的な設定に依存すると明確性に欠け、デフォルト設定が変更された場合、望ましくない動作が発生する可能性があります。

例 1: タスク フロー定義ファイルの次のスニペットは、暗黙のデフォルト url-invoke-disallowed 設定を使用して設定されたタスク フローの例を示します。

...
    <task-flow-definition id="password">
        <default-activity>PasswordPrompt</default-activity>
        <view id="PasswordPrompt">
            <page>/PasswordPrompt.jsff</page>
        </view>
        <use-page-fragments/>
    </task-flow-definition>
...

通常の JSF アプリケーションでは、UI コンポーネントで指定されたコンバーターとバリデーターを使用して、値が変換および検証されます。変換と検証自体は、ページが送信されたときに行われます。Fusion アプリケーションでブックマーク可能なビューを使用すると、ページが送信されないため、デフォルトでは同様の変換や検証は実行されません。

例 1: 次の設定ファイル スニペットは、paramName URL パラメーターの変換または検証を実行しないように設定された、ブックマーク可能なビューのサンプルを示しています。

...
    <bookmark>
        <method>#{paramHandler.handleParams}</method>
        <url-parameter>
            <name>paramName</name>
            <value>#{requestScope.paramName}</value>
        </url-parameter>
    </bookmark>
...

Oracle ADF Faces コンポーネントの属性値は、通常は、サーバーでのみ設定できます。ただし、多数のコンポーネントにより開発者はクライアント上で設定可能な属性のリストを定義できます。これらのコンポーネントの unsecure 属性によりこのようなリストを指定できます。

現在、unsecure 属性内に表示できる属性は、disabled のみです。この属性を使用して、クライアントはどのコンポーネントを有効または無効にするかを定義できるようになります。本来サーバーでのみ設定可能にする必要がある属性値を、クライアントが制御できるようにするのは良いアイデアではありません。

例 1: 次のコードは、ユーザーからパスワード情報を収集して unsecure 属性を使用する inputText コンポーネントを示しています。

...
    <af:inputText id="pwdBox"
                  label="#{resources.PWD}"
                  value=""#{userBean.password}
                  unsecure="disabled"
                  secret="true"
                  required="true"/>
...

静的クラス フィールドに暗号鍵を保持すると、プロセス メモリ (ルート化されたデバイスなど) やプロセス メモリ ダンプ (クラッシュ ダンプなど) にアクセスできるエンティティによって簡単に発見されてしまいます。

コンテンツ プロバイダーに対して読み取り権限と書き込み権限を個別に定義することをお勧めしますが、writePermission のみを定義すると誤解を招く可能性があります。SQL の性質上、真の書き込み専用クエリを生成することは一般的に不可能です。ユーザーがデータに直接アクセスできない場合でも、攻撃者が where 句を操作して保存されたデータを再構築する可能性があります。

例 1:writePermission のみを使用して宣言されたコンテンツプロバイダの例を次に示します。

 <provider android:name=".ContentProvider" android:writePermission="content.permission.WRITE_CONTENT"/> 

一般的な開発方法では、アプリケーションで配布または実装されることのないデバッグまたはテスト用の「裏口」コードを追加します。 この種のデバッグコードが誤ってアプリケーションに残された場合、アプリケーションは意図しない相互作用に対して開放されていることになります。 これらの裏口エントリポイントは、設計やテスト中に想定されるアプリケーションの操作状況で考慮されていないため、セキュリティリスクを発生させることになります。

ブロードキャストの送信者の権限を指定せずに登録された受信者は、すべてのブロードキャストの送信者からのメッセージを受信できます。これらのメッセージに悪意のあるデータが含まれる場合や、悪意のあるブロードキャスト送信者からメッセージが送信されると、アプリケーションが危険にさらされる可能性があります。

例 1: 次のコードは、ブロードキャスト送信者の権限を指定せずに受信者を登録しています。

...
context.registerReceiver(broadcastReceiver, intentFilter);
...

すべてのアプリケーションが、マニフェスト定義でアクセス許可が明示的に割り当てられていないパブリック コンポーネントにアクセスできます。

Android アプリケーションのアクティビティ、レシーバー、およびサービスコンポーネントの exported 属性のデフォルト値は、intent-filter の有無に依存します。intent-filter が存在している場合、コンポーネントでは外部使用が意図されていることを意味しているため、exported 属性には true が設定されます。このコンポーネントは、Android プラットフォーム上の他のどのアプリケーションからもアクセスできるようになります。

例 1:intent-filter は設定されているが明示的なアクセス権限は設定されていない場合の Android アクティビティの例を次に示します。

 <activity android:name=".AndroidActivity"/> 

   <intent-filter android:label="activityName"/> 

    <action android:name=".someFunAction"/> 

   </intent-filter> 

    ... 

 </activity> 

このアクティビティは、悪意のあるアプリケーションによって悪用される可能性があります。

すべてのアプリケーションが、マニフェスト定義でアクセス許可が明示的に割り当てられていないパブリック コンポーネントにアクセスできます。android:minSdkVersion または android:targetSdkVersion を "16" またはそれ以前に設定するアプリケーションの場合、Android コンテンツ プロバイダーはデフォルトでエクスポートされます。これらの属性のいずれかを "17" またはそれ以降に設定するアプリケーションの場合、デフォルトは "false" です。

例 1: 明示的なアクセス権限もエクスポートされたフラグもなしで宣言された Android コンテンツプロバイダの例を次に示します。

 <provider android:name=".ContentProvider"/> 

Android は、安全なネットワーク通信の実現のため、セキュリティ プロバイダーに依存しています。ただし、デフォルトのセキュリティ プロバイダーに脆弱性が見つかることがあります。これらの脆弱性に対処するため、Google Play サービスは、デバイスのセキュリティ プロバイダーを自動的に更新して、既知のエクスプロイトから保護する手段を提供しています。Google Play サービスのメソッドを呼び出すことで、最新のアップデートが適用されたデバイスでアプリが実行され、既知のエクスプロイトから保護されていることを保証できます。

ネットワーク セキュリティ設定機能により、アプリは、アプリ コードを変更せずに、安全な宣言型設定ファイルでネットワーク セキュリティ設定をカスタマイズできます。これらの設定は、特定のドメインおよび特定のアプリについて設定できます。この機能の主な機能は次のとおりです。
- カスタム信頼アンカー: アプリの安全な接続のため、どの証明機関 (CA) を信頼するかをカスタマイズします。たとえば、特定の自己署名証明書だけを信頼したり、アプリが信頼するパブリック CA のセットを制限します。
- デバッグのみのオーバーライド: インストール ベースのリスクを高めることなく、アプリ内で安全な接続を安全にデバッグします。
- クリアテキスト トラフィックのオプトアウト: クリアテキスト トラフィックの誤った使用からアプリを保護します。
- 証明書のピン留め: アプリの安全な接続を特定の証明書に制限します。

受信者の権限を設定せずに送信されたブロードキャストはすべての受信者がアクセスできます。これらのブロードキャストに重要なデータが含まれる、あるいは不正な受信者にアクセスする場合には、アプリケーションが危険にさらされる可能性があります。

例 1: 次のコードは、受信者の権限を指定せずにブロードキャストを送信しています。

...
context.sendBroadcast(intent);
...

システム ブロードキャストはプライベート コンポーネントに送信できます。サードパーティからの非システム ブロードキャストを受信するには、コンポーネントをパブリックにする必要があります。システム ブロードキャストと非システム ブロードキャストの両方を単一のコンポーネントで受信するように登録すると、コンポーネントの機能の一部 (システム部分) が不必要にサードパーティに公開されます。

カスタム権限を宣言する場合、権限の保護レベルを指定するための 4 つのオプションがあります: normal、dangerous、signature、および signature or system。Normal 権限は、それらを要求するすべてのアプリケーションに付与されます。Dangerous 権限は、ユーザーの確認後にのみ付与されます。Signature 権限は、権限を定義するパッケージと同じ開発者キーによって署名されたアプリケーションにのみ付与されます。Signature or system 権限は signature 権限と似ていますが、Android システム イメージのパッケージにも付与されます。

例 1:normal 保護レベルで宣言されたカスタム権限の例を次に示します。

 <permission android:name="custom.PERMISSION"
                     android:label="@string/label_permission"
                     android:description="@string/desc_permission"
                     android:protectionLevel="normal">
      </permission>

読み取りと書き込みの permission を組み合わせて宣言されたコンテンツ プロバイダーには、そのプロバイダーに読み取りまたは書き込みアクセスを要求するエンティティがアクセスできるようになります。しかし、多くの場合、ファイル システム上のファイルの場合と同様に、プロバイダーによって保存されたデータへの読み取りアクセスを必要とするエンティティに、データの変更を許可すべきではありません。permission 属性を設定した場合、データ ユーザーとデータの整合性に影響を与える相互作用を区別できません。

例 1: 読み取りおよび書き込みを組み合わせたアクセス permission をコンテンツプロバイダで宣言した例を次に示します。

 <provider android:name=".ContentProvider" android:permission="content.permission.READ_AND_WRITE_CONTENT"/>