Sempre que um usuário inicia manualmente uma nova transação, o sistema SAP verifica automaticamente se ele está autorizado a executar essa transação. No entanto, essas verificações não são feitas por padrão quando um usuário inicia programaticamente uma nova transação chamando a instrução CALL TRANSACTION. Se não for feita uma verificação de autorização explícita antes dessa instrução, o usuário que executar o programa ABAP será capaz de iniciar uma transação que, de outra forma, não seria permitida.

Exemplo 1: O código a seguir chama uma transação capaz de executar qualquer programa ABAP.

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

Nesse caso, um usuário de outra forma não autorizado que estiver executando o código poderá iniciar qualquer programa ABAP, podendo assim obter o controle total do sistema.

Se um invasor puder fornecer valores que o aplicativo, em seguida, usa para determinar quais tipos de verificação de autorização devem ser realizadas na abertura de um objeto MQ, existe a possibilidade de que um invasor passe todas as verificações de controle de acesso ao tentar abrir um objeto que, de outra forma, seria inacessível.

Exemplo: O seguinte trecho de código COBOL lê os valores do terminal e os usa para controlar os campos MQOD-ALTERNATEUSERID e MQOD-ALTERNATESECURITYID do descritor do objeto MQ.

...
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.
... 

Nesse exemplo, um invasor pode fornecer valores que permitem que ele passe pelas verificações de controle de acesso no objeto MQ sendo aberto.

Em geral, não permita que dados fornecidos pelo usuário ou de qualquer outra forma não confiáveis controlem valores confidenciais.

Normalmente, as verificações de autorização em um aplicativo SAP são feitas para o usuário que executa o aplicativo (usuário conectado). No entanto, é possível verificar a autorização para outro usuário (diferente do usuário conectado) programaticamente das seguintes maneiras:
1. A instrução AUTHORITY-CHECK é usada junto com a adição FOR USER
2. O módulo de função AUTHORITY_CHECK é chamado com o usuário especificado
3. O módulo de função SU_RAUTH_CHECK_FOR_USER é chamado com o usuário especificado

Embora essas verificações possam ser necessárias de vez em quando, muitas vezes elas representam um risco de segurança relacionado à escalação de privilégios. Um usuário mal-intencionado com controle sobre a entrada "user id", com base na qual são realizadas verificações de autorização, será capaz de enganar o sistema e fazer com que este conceda um nível de acesso que de outra forma seria proibido para esse usuário. Para tanto, o usuário fornece um superusuário conhecido (como SAP* ou DDIC, por exemplo).

Mesmo nos casos em que um usuário não tem controle direto sobre a entrada "user id" usada para verificações de autorização, a sondagem da autorização para um usuário diferente é considerada uma prática imprópria, devendo assim ser evitada. O usuário conectado (sy-uname) não precisa ser explicitamente especificado ao realizar verificações de autorização. Esse é o comportamento padrão - especificá-lo explicitamente apenas abre as portas para explorações nas quais sy-uname pode ser manipulado antes que a verificação chegue a ser executada. Portanto, é uma boa ideia ignorar a verificação de autorizações para um usuário diferente em geral e a especificação explícita do usuário conectado em particular.

Exemplo 1: O código a seguir verifica autorizações de usuários antes de chamar uma transação capaz de executar qualquer programa ABAP.

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

Nesse caso, um usuário de outra forma não autorizado poderá iniciar qualquer programa ABAP fornecendo um superusuário conhecido (como *SAP * ou DDIC) à variável v_user.

APIs Java que realizam tarefas usando a verificação do carregador de classes do chamador imediato devem ser usadas com cautela. Essas APIs ignoram a verificação de SecurityManager que garante que todos os chamadores na cadeia de execução tenham recebido a permissão de segurança necessária. Verificações de acesso com base apenas no carregador de classes do chamador imediato podem resultar em problemas de escalação de privilégios, segundo os quais um chamador na cadeia de execução é capaz de acessar recursos sem as permissões necessárias. Portanto, essas APIs não devem ser invocadas em nome de um código não confiável, pois isso pode comprometer a segurança do sistema.



Applets Java de uma fonte não confiável ou em um ambiente não confiável com acesso a essas APIs podem executar código mal-intencionado e comprometer a segurança do sistema.

Os aplicativos Salesforce usam regras de compartilhamento para controlar as permissões do usuário e o acesso aos registros do banco de dados. No entanto, as regras de compartilhamento do usuário nem sempre são aplicadas no Apex porque as classes do Apex podem ser declaradas com diferentes palavras-chave de compartilhamento que alteram a forma como as regras são aplicadas. Uma classe pode ser declarada com uma das três palavras-chave de compartilhamento diferentes:

- with sharing: As regras de compartilhamento do usuário serão aplicadas.
- without sharing: As regras de compartilhamento não serão aplicadas.
- inherited sharing: As regras de compartilhamento da classe de chamada serão aplicadas. Quando a classe de chamada não especificar uma palavra-chave de compartilhamento ou quando a própria classe for um ponto de entrada, como um controlador do Visualforce, as regras de compartilhamento do usuário serão impostas por padrão.

Quando nenhuma das palavras-chave de compartilhamento for declarada, a classe herdará o modo de compartilhamento da classe de chamada, se houver. Caso contrário, as regras de compartilhamento não serão aplicadas.

Exemplo 1: As três classes do Apex a seguir têm palavras-chave de compartilhamento não seguras para suas chamadas de consulta de banco de dados.

    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 e TestClass2 não são seguros porque os registros podem ser recuperados sem a imposição de regras de compartilhamento do usuário.

TestClass3 é mais seguro porque impõe regras de compartilhamento por padrão. No entanto, o acesso não autorizado ainda poderá ser concedido se a função getAllTheSecrets() for chamada em uma classe que declarar explicitamente without sharing.

Um único elemento <security constraint> sugere que o programa não emprega controle de acesso baseado em função, que é a melhor prática comumente aceita para proteger operações confidenciais em aplicativos da web seguros. Se o aplicativo fornecer acesso a operações ou dados confidenciais, pode não haver controles suficientes para impedir que usuários não autorizados obtenham acesso. Além disso, se houver um caractere curinga (*) no <url-pattern>, isso pode ser uma indicação de que o padrão é excessivamente amplo.

Muitos aplicativos usam cookies para comunicar o identificador de sessão de um usuário. Quando o aplicativo é acessado por HTTPS, os cookies são protegidos (os invasores não conseguem detectá-los). Mas se os desenvolvedores permitirem acesso HTTP a partes não confidenciais do aplicativo, o identificador de sessão pode ser roubado. Quando um usuário navega para uma parte desprotegida do site, o cookie, contendo o ID da sessão, é enviado sem proteção. Se os invasores detectam o tráfego, eles poderão ver o ID da sessão e usá-lo para assumir o controle da sessão do usuário.


O exemplo a seguir mostra uma configuração que combina canais inseguros e seguros:

  <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>