If an attacker can supply values that the application then uses to determine what kinds of authorization checks to perform on opening an MQ object, the potential exists for an attacker to pass all the access control checks when attempting to open otherwise inaccessible object.

Example 1: The following COBOL code snippet reads values from the terminal and uses them to control MQOD-ALTERNATEUSERID and MQOD-ALTERNATESECURITYID fields of the MQ object descriptor.

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

In this example, an attacker could supply values that allow them to pass access control checks on the MQ object eing opened.

In general, do not allow user-provided or otherwise untrusted data to control sensitive values.

Normally authorization checks in an SAP application are done for the user executing the application (logged on user). However, it is possible to check authorization for a different user (other than the logged on user) programmatically in the following ways:
1. Statement AUTHORITY-CHECK is used together with the addition FOR USER
2. Function module AUTHORITY_CHECK is invoked with the specified user
3. Function module SU_RAUTH_CHECK_FOR_USER is invoked with the specified user

While such checks may be necessary at times, often they pose a security risk of privilege escalation. A malicious user with control over the input 'user id' against which authorization checks are done will be able to trick the system into providing access that is otherwise prohibited to the user by supplying a known super-user (like SAP* or DDIC, for example).

Even in cases where a user has no direct control over the 'user id' used for authorization checks, probing the authorization for a different user is considered a bad practice and has to be avoided. Logged on user (sy-uname) need not be explicitly specified when performing authorization checks. That is the default behavior - specifying it explicitly only opens door to exploitation where sy-uname may be manipulated before the check is actually executed. It is therefore a good idea to skip checking authorizations for a different user in general and explicitly specifying the logged on user in particular.

Example 1: The following code checks user authorizations before calling a transaction that can execute any ABAP program.

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

In this case, an otherwise unauthorized user will be able to start any ABAP program by supplying a known super-user (like SAP* or DDIC) to the variable v_user.

Java APIs that perform tasks using the immediate caller's class loader check should be used with caution. These APIs bypass the SecurityManager check that ensures all callers in the execution chain have been granted the requisite security permission. Access checks against the immediate caller's class loader alone can result in privilege escalation issues whereby some caller in the execution chain is able to access resources without the required permissions. These APIs, thus, should not be invoked on behalf of untrusted code, as it may compromise system security.



Java Applets from an untrusted source or in an untrusted environment with access to these APIs can execute malicious code and compromise system security.

Salesforce applications use sharing rules to control user permissions and access to database records. However, user sharing rules are not always enforced in Apex because Apex classes can be declared with different sharing keywords that change the way the rules are enforced. A class can be declared with one of three different sharing keywords:

- with sharing: The user sharing rules will be enforced.
- without sharing: The sharing rules will not be enforced.
- inherited sharing: The sharing rules of the calling class will be enforced. When the calling class does not specify a sharing keyword, or when the class itself is an entrypoint such as a Visualforce controller, the user sharing rules will be enforced by default.

When none of the sharing keywords are declared, the class will inherit the sharing mode of the calling class if there is one. Otherwise, sharing rules will not be enforced.

Example 1: The following three Apex classes all have unsafe sharing keywords for their database query calls.

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

Both MyClass1 and MyClass2 are unsafe because the records can be retrieved without the enforcement of user sharing rules.

MyClass3 is safer because it enforces sharing rules by default. However, unauthorized access can still be granted if function getAllTheSecrets() is called in a class that explicitly declares without sharing.

A single <security constraint> element suggests the program does not employ role-based access control, which is commonly accepted best practice for protecting sensitive operations in secure web applications. If the application provides access to sensitive operations or data, there might not be sufficient controls in place to prevent unauthorized users from gaining access. Furthermore, if there is a wildcard (*) in the <url-pattern>, it can be an indication that the pattern is overly broad.

The AccessibleObject API allows the programmer to get around the access control checks provided by Java access specifiers. In particular it enables the programmer to allow a reflected object to bypass Java access controls and in turn change the value of private fields or invoke private methods, behaviors that are normally disallowed.

Many applications use cookies to communicate a user's session identifier. When the application is accessed over HTTPS, cookies are protected (attackers are unable to sniff them). But if developers allow HTTP access to non-sensitive parts of the application, the session identifier can be stolen. When a user browses to an unprotected part of the site, the cookie, containing the session ID, is sent in the clear. If attackers sniff the traffic, they can see the session ID and use it to take control of the user's session.


The following example shows a configuration that mixes insecure and secure channels:

  <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 allows for temporarily replacing the Authentication object in the SecurityContext during the secure object callback phase. This only occurs if the original Authentication object was successfully processed by the AuthenticationManager and AccessDecisionManager. The RunAsManager creates this Authentication object.
Typically developers use RunAsManager to configure one or more additional roles for an authenticated user for the duration of a method invocation. This is useful for a secure bean that needs to access a remote application. Since the remote application might demand different credentials, this allows translating between calling roles and those needed by the remote application so that the remote access can succeed. The new Authentication object (called RunAsUserToken) will be simply accepted as a valid Authentication object without any further authentication or authorization check.
Adding new roles or privileges to the new Authentication object has the potential to temporarily elevate the user's privileges, allowing the user to take an unauthorized action.
The following configuration shows using RunAsManager to add the role "UBER_BOSS" to a user who has the role "ROLE_PEON", thus temporarily elevating this user to have manager privileges, which enables all peons to get data from the 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>

By default, task flows in a Fusion application are not directly accessible from a GET request: whenever a URL attempts to invoke the task flow, it receives an HTTP 403 status code. However, relying on an implicit setting always lacks clarity and can potentially lead to unwanted behavior if the default setting changes underneath.

Example 1: The following snippet from a task flow definition file shows an example of a task flow configured with the implicit default url-invoke-disallowed setting.

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

In a regular JSF application, values are converted and validated using converters and validators specified by the UI components. The conversion and validation itself happens when the page is submitted. A bookmarkable view in a Fusion application results in no page submission, and therefore no similar conversion or validation is performed by default.

Example 1: The following configuration file snippet shows a sample bookmarkable view that is configured to perform no conversion or validation of the paramName URL parameter.

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

The values of attributes for Oracle ADF Faces components can ordinarily be set only on the server. However, a number of components allow the developer to define a list of attributes that can be set on the client. unsecure attribute of these components can specify such a list.

Currently, the only attribute that can appear inside the unsecure attribute is disabled, and it allows the client to define which components are enabled and which ones are not. It is never a good idea to let the client control the values of attributes that should only be settable on the server.

Example 1: The following code demonstrates an inputText component that collects password information from the user and uses the unsecure attribute.

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

Storing encryption keys in static class fields allows easy recovery by an entity that can access the process memory (e.g. rooted device) or process memory dumps (e.g. crash dumps).

While it is a good idea to define separate read and write permissions for content providers, defining only the writePermission could be misleading. Due to the nature of SQL, generating true write-only queries is generally impossible: even when the user does not have direct access to the data, an attacker may reconstruct the stored data by manipulating the where clause.

Example 1: The following is an example of a content provider declared with only the writePermission.

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

A common development practice is to add "back door" code specifically designed for debugging or testing purposes that is not intended to be shipped or deployed with the application. When this sort of debug code is accidentally left in the application, the application is open to unintended modes of interaction. These back door entry points create security risks because they are not considered during design or testing and fall outside of the expected operating conditions of the application.

Receiver registered without the broadcaster permission will receive messages from any broadcaster. If these messages contain malicious data or come from a malicious broadcaster, the application may be compromised.

Example 1: The following code registers a receiver without specifying the broadcaster permission.

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

Any application can access public components that are not explicitly assigned an access permission in their manifest definition.

The default value of the exported attribute for the activity, receiver, and service components in an Android application depends on the presence or absence of an intent-filter. Presence of an intent-filter implies, the component is intended for external use, thus setting the exported attribute to true. This component is now accessible to any other applications on the Android platform.

Example 1: The following is an example of an Android activity with an intent-filter and no explicit access permission set.

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

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

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

   </intent-filter> 

    ... 

 </activity> 

This activity can be exploited by malicious applications.

Any application can access public components that are not explicitly assigned an access permission in their manifest definition. Android content providers are exported by default for applications that set either android:minSdkVersion or android:targetSdkVersion to "16" or earlier. For applications that set either of these attributes to "17" or later, the default is "false".

Example 1: The following is an example of an Android content provider declared without an explicit access permission or exported flag.

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

Android relies on a security Provider to provide secure network communications. However, from time to time, vulnerabilities are found in the default security provider. To protect against these vulnerabilities, Google Play services provides a way to automatically update a device's security provider to protect against known exploits. By calling Google Play services methods, your app can ensure that it's running on a device that has the latest updates to protect against known exploits.

The Network Security Configuration feature lets apps customize their network security settings in a safe, declarative configuration file without modifying app code. These settings can be configured for specific domains and for a specific app. The key capabilities of this feature are as follows:
- Custom trust anchors: Customize which Certificate Authorities (CA) are trusted for an app's secure connections. For example, trusting particular self-signed certificates or restricting the set of public CAs that the app trusts.
- Debug-only overrides: Safely debug secure connections in an app without added risk to the installed base.
- Cleartext traffic opt-out: Protect apps from accidental usage of cleartext traffic.
- Certificate pinning: Restrict an app's secure connection to particular certificates.

Broadcasts sent without the receiver permission are accessible to any receiver. If these broadcasts contain sensitive data or reach a malicious receiver, the application may be compromised.

Example 1: The following code sends a broadcast without specifying the receiver permission.

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