When present, the open_basedir configuration option attempts to prevent PHP programs from operating on files outside of the directory trees specified in php.ini. If no directories are specified using the open_basedir option, then programs running under PHP are given full access to arbitrary files on the local file system, which can allow attackers to read, write or create files that they should not be able to access.

Failing to specify a restrictive set of directories with open_basedir can make it easier for attackers to exploit other vulnerabilities.

Although the open_basedir option is an overall boon to security, the implementation suffers from a race condition that can permit attackers to bypass its restrictions in some circumstances [2]. A time-of-check, time-of-use (TOCTOU) race condition exists between the time PHP performs the access permission check and when the file is opened. As with file system race conditions in other languages, this race condition can allow attackers to replace a symlink to a file that passes an access control check with another for which the test would otherwise fail, thereby gaining access to the protected file.

The window of vulnerability for such an attack is the period of time between when the access check is performed and when the file is opened. Even though the calls are performed in close succession, modern operating systems offer no guarantee about the amount of code that will be executed before the process yields the CPU. Attackers have a variety of techniques for expanding the length of the window of opportunity in order to make exploits easier, but even with a small window, an exploit attempt can simply be repeated over and over until it is successful.

When safe_mode is enabled, the safe_mode_exec_dir option restricts PHP to executing commands from only the specified directories. Although the absence of a safe_mode_exec_dir entry does not represent a security vulnerability itself, this added leniency can be exploited by attackers in conjunction with other vulnerabilities to make exploits more dangerous.

When present, the open_basedir configuration option attempts to prevent PHP programs from operating on files outside of the directory trees specified in php.ini. If the working directory is specified with ., this can potentially be changed by an attacker by using chdir().

Although the open_basedir option is an overall boon to security, the implementation suffers from a race condition that can permit attackers to bypass its restrictions in some circumstances [2]. A time-of-check, time-of-use (TOCTOU) race condition exists between the time PHP performs the access permission check and when the file is opened. As with file system race conditions in other languages, this race condition can allow attackers to replace a symlink to a file that passes an access control check with another for which the test would otherwise fail, thereby gaining access to the protected file.

The window of vulnerability for such an attack is the period of time between when the access check is performed and when the file is opened. Even though the calls are performed in close succession, modern operating systems offer no guarantee about the amount of code that will be executed before the process yields the CPU. Attackers have a variety of techniques for expanding the length of the window of opportunity in order to make exploits easier, but even with a small window, an exploit attempt can simply be repeated over and over until it is successful.

When enabled, the register_globals option causes PHP to register all EGPCS (Environment, GET, POST, Cookie, and Server) variables globally, where they can be accessed in any scope in any PHP program. This option encourages programmers to write programs that are more-or-less unaware of the origin of values they rely on, which can lead to unexpected behavior in benign environments and leaves the door open to attackers in malicious environments. In recognition the dangerous security implications of register_globals, the option was disabled by default in PHP 4.2.0 and was deprecated and removed in PHP 6.

Example 1: The following code is vulnerable to cross-site scripting. The programmer assumes the value of $username originates from the server-controlled session, but an attacker may supply a malicious value for $username as a request parameter instead. With register_globals enabled, this code will include a malicious value submitted by an attacker in the dynamic HTML content it generates.

<?php
if (isset($username)) {
    echo "Hello <b>$username</b>";
} else {
    echo "Hello <b>Guest</b><br />";
    echo "Would you like to login?";

}
?>

The safe_mode option is one of the most important security features in PHP. When safe_mode is disabled, PHP operates on files with the permissions of the user that invoked it, which is often a privileged user. Although configuring PHP with safe_mode disabled does not introduce a security vulnerability itself, this added leniency can be exploited by attackers in conjunction with other vulnerabilities to make exploits more dangerous.

When enabled, the session.use_trans_sid causes PHP to pass the session ID on the URL, which makes it much easier for attackers to hijack active sessions or trick users into using an existing session already under the attackers' control.

Parameters passed on the URL are more visible than POST parameters and cookie values because they often appear in browser histories, bookmarks, log files, and other highly exposed locations. If attackers learn the secret session identifier for an active session on a system, then they could possibly supply the session identifier back to the program in order to hijack the user's session.

Beyond session hijacking, exposing the session ID on the URL also facilitates session fixation attacks. In the canonical exploit of session fixation vulnerabilities, an attacker creates a new session on a web application and records the associated session identifier. The attacker then causes the victim to authenticate against the server using that session identifier, giving the attacker access to the user's account through the active session. Passing the session identifier on the URL allows attackers to reach a large number of potential victims by sending URLs that include a compromised session identifier to victims via email or another mass communication mechanism.

When present, the open_basedir configuration option attempts to prevent PHP programs from operating on files outside of the directory trees specified in php.ini. Although the open_basedir option is an overall boon to security, the implementation suffers from a race condition that can permit attackers to bypass its restrictions in some circumstances [2]. A time-of-check, time-of-use (TOCTOU) race condition exists between the time PHP performs the access permission check and when the file is opened. As with file system race conditions in other languages, this vulnerability can allow attackers to replace a symlink to a file that passes the access control check with another for which the test would otherwise fail, thereby gaining access to the protected file.

The window of vulnerability for such an attack is the period of time between when the access check is performed and when the file is opened. Even though the calls are performed in close succession, modern operating systems offer no guarantee about the amount of code that will be executed before the process yields the CPU. Attackers have a variety of techniques for expanding the length of the window of opportunity in order to make exploits easier, but even with a small window, an exploit attempt can simply be repeated over and over until it is successful.

SAML messages are cryptographically signed to guarantee validity and integrity of the assertion. There are a few steps that the service provider should perform for signature verification. One of these steps is the transformation of the data that is pointed to by the Reference element. Usually, the Transform operation aims at selecting just a subset of the referenced data. However, an attacker could use some types of transforms to cause a denial of service and in some environments even arbitrary code execution. Examples of such insecure types are XSLT (Extensible Stylesheet Language Transformations) and XPath transforms.

SAML messages are cryptographically signed to guarantee validity and integrity of the assertion. Man-in-the-middle attacks can tamper with the SAML Response message without signatures. The attacker can modify the permissions and user for the service provider and gain access to the application.

Duplicate form-bean names serve no purpose since only the last entry will be registered when the same name is used in multiple <form-bean> tags.

Example 1: The following configuration has two form-bean entries with the same name.

<form-beans>
  <form-bean name="loginForm" type="org.apache.struts.validator.DynaValidatorForm">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
  <form-bean name="loginForm" type="org.apache.struts.validator.DynaActionForm">
    <form-property name="favoriteColor" type="java.lang.String" />
  </form-bean>
</form-beans>

Struts uses the path attribute to locate the resource necessary to handle a request. Since the path is a module-relative location, it is an error if it does not begin with a "/" character.

Example 1: The following configuration contains an empty path.

<global-exceptions>
  <exception key="global.error.invalidLogin" path="" scope="request" type="InvalidLoginException" />
</global-exceptions>

Example 2: The following configuration uses a path that does not start with a "/" character.

<global-forwards>
  <forward name="login" path="Login.jsp" />
</global-forwards>

The struts specification requires an input attribute whenever a named action returns validation errors[2]. The input attribute specifies the page used to display error messages when validation errors occur.
Example 1: The following configuration defines a named validating action, but does not specify an input attribute.

<action-mappings>
  <action   path="/Login"
            type="com.LoginAction"
            name="LoginForm"
            scope="request"
            validate="true" />
</action-mappings>

The <exception> tag requires that an exception type be defined. A missing or empty type attribute is indicative of either a superfluous exception handler or an accidental omission. If a developer intended to handle an exception, but forgot to define the exception type, then the application might leak sensitive information about the system.
Example 1: The following configuration omits the type from the <exception> tag.

  <global-exceptions>
    <exception
      key="error.key"
      handler="com.mybank.ExceptionHandler"/>
  </global-exceptions>

Struts uses form-bean entries to map HTML forms to actions. If the name attribute in an <action> tag does not correspond with the name of a form-bean, the action cannot be mapped and indicates either a superfluous definition or a typographical error.

Example 1: The following configuration does not contain a mapping for bean2.

<form-beans>
  <form-bean name="bean1" type="coreservlets.UserFormBean" />
</form-beans>

<action-mappings>
  <action path="/actions/register1" type="coreservlets.RegisterAction1" name="bean1" scope="request" />
  <action path="/actions/register2" type="coreservlets.RegisterAction2" name="bean2" scope="request" />
</action-mappings>

Struts uses the form-bean name to map HTML forms to actions. If a form-bean does not have a name, it cannot be mapped to an action and indicates either a superfluous definition or an accidentally omitted bean.
Here is a proper form-bean example:
Example 1: The following form-bean has an empty name attribute.

<form-beans>
  <form-bean name="" type="org.apache.struts.validator.DynaValidatorForm">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
</form-beans>

Struts uses form-bean entries to map HTML forms to actions. If a form-bean does not have a type, it cannot be mapped to an action.
Example 1: The following form-bean has an empty type attribute.

<form-beans>
  <form-bean name="loginForm" type="">
    <form-property name="name" type="java.lang.String" />
    <form-property name="password" type="java.lang.String" />
  </form-bean>
</form-beans>

Struts requires <form-property> tags to include a type attribute. Struts will throw an exception when processing a form that defines a form-property with no type.

Example 1: The following configuration omits a type for the name property.

<form-bean name="loginForm" type="org.apache.struts.validator.DynaValidatorForm">
  <form-property name="name" />
  <form-property name="password" type="java.lang.String" />
</form-bean>

A <forward> tag must have name and path attributes. Without a name, the forward will never be used.

Example 1: The following <forward> tag has an empty name attribute.

    <forward name="" path="/results.jsp"/>

A <forward> tag must have name and path attributes. It is an error to omit a path or to specify a blank path. Furthermore, all paths must start with the "/" character.

Example 1: The following <forward> tag has a missing path attribute.

    <forward name="success" />

If the display_errors option is enabled, errors are displayed to the Web, which can illustrate potential weaknesses to an attacker. For example, a database error message can reveal that the application is vulnerable to a SQL injection attack. Other error messages can reveal more oblique clues about the system.