사용자가 수동으로 새로운 트랜잭션을 시작할 때마다 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. AUTHORITY-CHECK 문을 추가 FOR USER와 함께 사용
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는 시스템 보안을 손상시킬 수 있으므로 신뢰할 수 없는 코드 대신에 호출하지 말아야 합니다.



이러한 API에 접근 가능한 신뢰할 수 없는 소스 또는 신뢰할 수 없는 환경의 Java Applet은 악성 코드를 실행하고 시스템 보안을 손상시킬 수 있습니다.

Salesforce 응용 프로그램은 공유 규칙을 사용하여 사용자 권한 및 데이터베이스 레코드에 대한 액세스를 제어합니다. 그러나 Apex에서 사용자 공유 규칙이 항상 적용되는 것은 아닙니다. 규칙이 적용되는 방식을 변경하는 다른 공유 키워드를 사용하여 Apex 클래스를 선언할 수 있기 때문입니다. 다음의 세 가지 공유 키워드 중 하나로 클래스를 선언할 수 있습니다.
- 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 의 경우에는 기본적으로 공유 규칙을 적용하므로 더 안전합니다. 그러나 without sharing을 명시적으로 선언하는 클래스에서 getAllTheSecrets() 함수를 호출하는 경우에는 여전히 무단 액세스 권한을 부여할 수 있습니다.

단일 <security constraint> 요소는 프로그램에 RBAC(Role-Based Access Control)가 사용되고 있지 않음을 암시합니다. RBAC는 보안 웹 응용 프로그램에서 민감한 작업의 보호를 위해 널리 용인되는 모범 사례입니다. 민감한 작업 또는 데이터에 대한 액세스를 제공하는 응용 프로그램의 경우 권한이 없는 사용자의 액세스를 차단하는 충분한 제어가 없을 수 있습니다. 또한 <url-pattern>에 와일드카드(*)가 있는 경우 패턴이 지나치게 광범위하다는 표시일 수 있습니다.

많은 응용 프로그램은 쿠키를 사용하여 사용자 세션 ID를 통신합니다. HTTPS를 통해 응용 프로그램에 액세스하면 쿠키가 보호됩니다(공격자가 쿠키를 스니핑할 수 없음). 그러나 개발자가 응용 프로그램의 민감하지 않은 부분에 대한 HTTP 접근을 허용할 경우, 세션 ID를 도난당할 수 있습니다. 사용자가 사이트의 보호되지 않은 부분을 탐색하면 세션 ID가 포함된 쿠키가 자유롭게 전송됩니다. 공격자가 트래픽을 스니핑하면 세션 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>