Database access control errors occur when:

1. Data enters a program from an untrusted source.

2. The data is used to specify a data value in an LDAP query.
Example 1: The employee ID of the current authenticated user is automatically submitted with each request by the client-side interface. The following code properly validates an employee ID as an integer before using it to construct an LDAP query. This validation prevents LDAP injection vulnerabilities, but may still leave the code vulnerable.

...
env.put(Context.SECURITY_AUTHENTICATION, "none");
DirContext ctx = new InitialDirContext(env);

String empID = request.getParameter("empID");

try
{
  int id = Integer.parseInt(empID);

  BasicAttribute attr = new BasicAttribute("empID", empID);

  NamingEnumeration employee =
            ctx.search("ou=People,dc=example,dc=com",attr);
...

The problem is that the developer has failed to consider what would happen if an attacker provides alternate values of empID. Although the interface automatically submits the employee ID of the current user, an attacker could submit an alternative value as part of a malicious request. Because the code in this example executes the query under an anonymous bind, it will return the directory entry for any valid employee ID, regardless of the identity of the current authenticated 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.

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