Cuando un usuario inicia manualmente una nueva transacción, el sistema SAP comprueba automáticamente si el usuario está autorizado para ejecutarla. Sin embargo, estas comprobaciones no se hacen de forma predeterminada cuando un usuario inicia mediante programación una nueva transacción llamando a la instrucción CALL TRANSACTION. Si no se efectúa una comprobación de autorización explícita antes de esta instrucción, el usuario que ejecuta el programa ABAP podrá iniciar una transacción que de otro modo no está permitida.

Ejemplo 1: El código siguiente llama a una transacción que puede ejecutar cualquier programa ABAP.

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

En este caso, un usuario no autorizado que ejecuta el código podrá iniciar cualquier programa ABAP y de esta forma hacerse con el control completo del sistema potencialmente.

Si un usuario malintencionado puede suministrar los valores que la aplicación más tarde utiliza para determinar qué tipos de comprobaciones de autorización realizar al abrir un objeto MQ, existe la posibilidad de que un usuario malintencionado supere todas las comprobaciones de control de acceso cuando intente abrir de otro modo un objeto inaccesible.

Ejemplo: el siguiente fragmento de código COBOL lee los valores del terminal y los utiliza para controlar los campos MQOD-ALTERNATEUSERID y MQOD-ALTERNATESECURITYID del descriptor de objetos 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.
... 

En este ejemplo, un usuario malintencionado podría suministrar los valores que le permitan superar las comprobaciones del control de acceso del objeto MQ que se va a abrir.

En general, no permita que los datos proporcionados por el usuario o que de alguna otra forma no son de confianza controlen los valores confidenciales.

Normalmente, las comprobaciones de seguridad en una aplicación SAP se hacen para el usuario que ejecuta la aplicación (el usuario registrado). Sin embargo, es posible comprobar la autorización de un usuario diferente (otro que no sea el usuario registrado) mediante programación de los modos siguientes:
1. La instrucción AUTHORITY-CHECK se usa junto con la adición FOR USER
2. Se invoca el módulo de función AUTHORITY_CHECK con el usuario especificado
3. Se invoca el módulo de función SU_RAUTH_CHECK_FOR_USER con el usuario especificado

Si bien estas comprobaciones pueden ser necesarias algunas veces, a menudo suponen un riesgo de seguridad por extensión de privilegios. Un usuario malicioso con control de la entrada "id de usuario" sobre la que se hacen comprobaciones de autorización será capaz de engañar al sistema para que le ofrezca acceso, que de otro modo tiene prohibido, proporcionando un super-usuario conocido (SAP* o DDIC, por ejemplo).

Incluso en casos en los que un usuario no tiene control directo sobre la 'id de usuario' empleada para las comprobaciones de autorización, pedir la autorización para un usuario diferente no se considera una práctica recomendada y debe evitarse. El usuario registrado (sy-uname) no tiene que especificarse explícitamente cuando se efectúan las comprobaciones de autorización. Este es el comportamiento predeterminado, especificarlo explícitamente, solo abre la puerta a que un sy-uname sea manipulado antes de que se ejecute la comprobación. Por consiguiente, es buena idea omitir las autorizaciones de comprobación para un usuario diferente en general y especificar explícitamente el usuario registrado en concreto.

Ejemplo 1: El código siguiente comprueba las autorizaciones de usuario antes de llamar a una transacción que puede ejecutar cualquier programa ABAP.

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

En este caso un usuario, que de otro modo no estaría autorizado, podrá iniciar cualquier programa ABAP proporcionando un super-usuario conocido (como SAP* o DDIC) en la variable v_user.

Las API de Java que realizan tareas mediante la comprobación de cargadores de clases del autor de la llamada inmediato deben utilizarse con precaución. Estas API omiten la comprobación de SecurityManager que garantiza que todos los autores de llamadas de la cadena de ejecución dispongan del permiso de seguridad necesario. Las comprobaciones de acceso solo en la clase del autor de la llamada inmediato pueden provocar problemas de escalada de privilegios, en los que un autor de una llamada en la cadena de ejecución puede acceder a recursos sin disponer de los permisos necesarios. Por lo tanto, no se debe llamar a estas API en nombre de código que no es de confianza, ya que se pone en peligro la seguridad del sistema.



Los applets Java de un origen o un entorno que no sean de confianza con acceso a estas API pueden ejecutar código malintencionado y comprometer la seguridad del sistema.

Las aplicaciones de Salesforce utilizan reglas de colaboración para controlar los permisos de los usuarios y el acceso a los registros de la base de datos. Sin embargo, las reglas de uso compartido de usuarios no siempre se aplican en Apex porque las clases de Apex se pueden declarar con diferentes palabras clave de uso compartido que cambian la forma en que se aplican las reglas. Una clase se puede declarar con una de tres palabras clave de uso compartido:

- with sharing: Se aplicarán las reglas de uso compartido de usuarios.
- without sharing: Las reglas de uso compartido no se aplicarán.
- inherited sharing: Se aplicarán las reglas de uso compartido de la clase que realiza la llamada. Cuando la clase que realiza la llamada no especifica una palabra clave de uso compartido, o cuando la propia clase es un punto de entrada, como un controlador de Visualforce, las reglas de uso compartido de usuarios se aplicarán de forma predeterminada.

Cuando no se declara ninguna de las palabras clave compartidas, la clase heredará el modo compartido de la clase llamante, si existe. De lo contrario, no se aplicarán las reglas de uso compartido.

Ejemplo 1: Las siguientes tres clases de Apex tienen palabras clave de uso compartido no seguras para sus llamadas de consulta de base de datos.

    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');
        }
    }

Tanto TestClass1 como TestClass2 son inseguras porque los registros se pueden recuperar sin la aplicación de reglas de uso compartido de usuarios.

TestClass3 Es más seguro porque impone reglas de uso compartido de forma predeterminada. Sin embargo, aún se puede otorgar acceso no autorizado si se llama la función getAllTheSecrets() en una clase que declara explícitamente without sharing.

Un solo elemento <security constraint> sugiere que el programa no emplea control de acceso basado en roles, que es el procedimiento recomendado comúnmente aceptado para proteger operaciones sensibles en aplicaciones web seguras. Si la aplicación proporciona acceso a operaciones o datos confidenciales, es posible que no existan controles suficientes para evitar que usuarios no autorizados obtengan acceso. Además, si hay un comodín (*) en la etiqueta <url-pattern>, puede ser una indicación de que el patrón es demasiado amplio.

Muchas aplicaciones utilizan cookies para comunicar el identificador de sesión de un usuario. Cuando se accede a la aplicación a través de HTTPS, las cookies están protegidas (los atacantes no pueden examinarlas). Pero si los desarrolladores permiten el acceso HTTP a partes no sensibles de la aplicación, el identificador de sesión puede ser objeto de robo. Cuando un usuario se dirige a una parte no protegida del sitio, la cookie, que contiene el identificador de sesión, se envía sin cifrar. Si los atacantes examinan el tráfico, pueden ver el identificador de sesión y usarlo para tomar el control de la sesión del usuario.


El siguiente ejemplo muestra una configuración que mezcla canales poco seguros y 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>