ユーザーが手動で新しいトランザクションを開始する場合、SAP システムでユーザーがトランザクションの実行を許可されているかどうかが自動的にチェックされます。ただし、ユーザーがプログラミングにより CALL TRANSACTION ステートメントを呼び出すことによって新しいトランザクションを開始する場合、デフォルトではこれらのチェックが実行されません。このステートメントの前に認証チェックが明示的に実行されない場合、ABAP プログラムを実行するユーザーは、本来は実行を許可されていないトランザクションを実行する可能性があります。

例 1: 次のコードは、ABAP プログラムを実行できるトランザクションを呼び出します。

...
CALL TRANSACTION 'SA38'.
...

この場合、このコードを実行しているユーザーは、本来はこの操作は許可されていないにも関わらず、ABAP エディタを開始できるため、システムを完全に制御できる可能性があります。

MQ オブジェクトを開くときに実施する権限チェックのタイプを決定するのにアプリケーションが後で使用する値を攻撃者が指定できる場合、攻撃者はすべての Access Control チェックに合格して、本来はアクセスできないオブジェクトを開いてしまう可能性があります。

例: 次の COBOL コード部分は、ターミナルから値を読み取って、MQ オブジェクトディスクリプタの MQOD-ALTERNATEUSERID および MQOD-ALTERNATESECURITYID フィールドの制御にその値を使用しています。

...
10 MQOD.
**    Alternate user identifier
   15 MQOD-ALTERNATEUSERID     PIC X(12).
**    Alternate security identifier
   15 MQOD-ALTERNATESECURITYID PIC X(40).
   ...
...
ACCEPT MQOD-ALTERNATEUSERID.
ACCEPT MQOD-ALTERNATESECURITYID.
CALL 'MQOPEN' USING HCONN, MQOD, OPTS, HOBJ, COMPOCODE REASON.
... 

この例では、開かれている MQ オブジェクトに対する Access Control チェックに合格することが可能となる値が、攻撃者によって指定される可能性があります。

一般的に、ユーザー入力などの信頼できないデータを使用して機密データを管理できないようにします。

通常、SAP アプリケーションでの認証チェックは、アプリケーションを実行するユーザー (ログオンしているユーザー) に対して行われます。しかし、次の方法で、別のユーザー (ログオンしているユーザー以外) に対する認証をプログラミングによりチェックすることができます。
1. FOR USER と一緒にステートメント AUTHORITY-CHECK を使用する
2. ユーザーを指定して関数モジュール AUTHORITY_CHECK を呼び出す
3. ユーザーを指定して関数モジュール SU_RAUTH_CHECK_FOR_USER を呼び出す

このようなチェックが必要な場合がありますが、権限昇格のセキュリティ リスクが発生する可能性があります。認証チェックの実行対象となる「ユーザー ID」の入力を制御する悪意のあるユーザーが、既知のスーパーユーザー (たとえば、SAP* や DDIC など) を指定することによって、本来はユーザーに対して禁止されているアクセスの許可を行うようにシステムに仕向けることが可能になります。

認証チェックに使用される「ユーザー ID」をユーザーが直接制御できない場合でも、別のユーザーに対する認証をプローブすることは好ましくない方法とみなし、避けるべきです。認証チェックを実行する場合、ログオンしているユーザー (sy-uname) を明示的に指定する必要がありません。これはデフォルトの動作です。明示的に指定しても、実際にチェックが実行される前に sy-uname が搾取される可能性が生じるだけです。そのため、一般的に別のユーザーの認証チェックをスキップしてから、特にログオンしているユーザーを明示的に指定することをお勧めします。

例 1: 次のコードは、ABAP プログラムを実行できるトランザクションを呼び出す前に、ユーザー認証をチェックします。

...
AUTHORITY-CHECK OBJECT 'S_TCODE' FOR USER v_user
ID 'TCD' FIELD 'SA38'.
IF sy-subrc = 0.
CALL TRANSACTION 'SA38'.
ELSE.
...

この場合、許可されていないユーザーが、既知のスーパーユーザー (SAP* や DDIC など) を変数 v_user に指定することによって、ABAP プログラムを開始できます。

直接呼び出し元のクラスローダーチェックを使用してタスクを実行するJava APIは、注意して使用する必要があります。これらのAPIは、実行チェーン内のすべての呼び出し元が必要なセキュリティ権限を持っていることを確認するSecurityManagerチェックをバイパスします。直接呼び出し元のクラスローダーだけにアクセスチェックを実行すると権限昇格の問題が発生し、実行チェーン内の一部の呼び出し元が必要な権限なしでリソースにアクセスできる可能性があります。したがって、これらの API は信頼のないコードで呼び出すべきではありません。システムのセキュリティを損なう恐れがあります。



信頼のないソースから、または信頼のない環境内のJava AppletはこれらのAPIにアクセスし、悪意のあるコードを実行してシステムのセキュリティを損ないます。

Salesforce アプリケーションは、共有ルールを使用して、ユーザー権限とデータベース レコードへのアクセスを制御します。ただし、Apex クラスは、ルールの適用方法を変えるさまざまな共有キーワードを使用して宣言できるため、ユーザー共有ルールが Apex で常に適用されるわけではありません。クラスは、次の 3 つの異なる共有キーワードのいずれかで宣言できます。
- with sharing: ユーザー共有ルールが適用されます。
- without sharing: 共有ルールは適用されません。
- inherited sharing: 呼び出し元のクラスの共有ルールが適用されます。呼び出し元のクラスで共有キーワードが指定されていない場合、またはクラス自体が Visualforce コントローラーなどのエントリポイントである場合、デフォルトでユーザー共有ルールが適用されます。
共有キーワードが宣言されていない場合、クラスは呼び出し元のクラスの共有モードを継承します (ある場合)。そうしないと、共有ルールが適用されません。
例 1: 次の 3 つのすべての Apex クラスには、データベース クエリ呼び出しについて安全でない共有キーワードがあります。

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

TestClass1 と TestClass2 はどちらも安全ではありません。ユーザー共有ルールを強制しなくてもレコードを取得できるためです。
TestClass3 の方が、デフォルトで共有ルールが適用されるため、より安全です。ただし、関数 getAllTheSecrets() が、without sharing を明示的に宣言するクラスで呼び出されると、不正アクセスが許可される可能性はあります。

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

多くのアプリケーションは、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>