The use of encoding functions such as mysql_real_escape_string() will prevent some, but not all SQL injection vulnerabilities. Relying on such encoding functions is equivalent to using a weak deny list to prevent SQL injection and might allow the attacker to modify the statement's meaning or to execute arbitrary SQL commands. Since it is not always possible to determine statically where input will appear within a given section of dynamically interpreted code, the Fortify Secure Coding Rulepacks may present validated dynamic SQL data as "SQL Injection: Poor Validation" issues, even though the validation may be sufficient to prevent SQL Injection within that context.

SQL injection errors occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a SQL query.

Example 1: The following example demonstrates how the configuration of the database can alter the behavior of mysqli_real_escape_string(). When the SQL mode is set to "NO_BACKSLASH_ESCAPES" the backslash character is treated as a normal character, and not an escape character[5]. Since mysqli_real_escape_string() takes this into account, the following query is vulnerable to SQL injection as " is no longer escaped to \" due to the database configuration.

  mysqli_query($mysqli, 'SET SQL_MODE="NO_BACKSLASH_ESCAPES"');
  ...
  $userName = mysqli_real_escape_string($mysqli, $_POST['userName']);
  $pass = mysqli_real_escape_string($mysqli, $_POST['pass']);
  $query = 'SELECT * FROM users WHERE userName="' . $userName . '"AND pass="' . $pass. '";';
  $result = mysqli_query($mysqli, $query);
  ...

If an attacker leaves the password field blank and enters " OR 1=1;-- for userName the quotation marks will not be escaped and the resulting query is as follows:

  SELECT * FROM users
  WHERE userName = ""
  OR 1=1;
  -- "AND pass="";

Since OR 1=1 causes the where clause to always evaluate to true and the double hyphens cause the rest of the statement to be treated as a comment, the query becomes logically equivalent to the much simpler query:

  SELECT * FROM users;

One traditional approach to preventing SQL injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SQL statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SQL queries can help, but it will not make your application secure from SQL injection attacks.

Another solution commonly proposed for dealing with SQL injection attacks is to use stored procedures. Although stored procedures prevent some types of SQL injection attacks, they fail to protect against many others. Stored procedures typically help prevent SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SQL injection attacks.

SQL injection errors related to SubSonic occur when:

1. Data enters a program from an untrusted source.

2. The data is used to dynamically construct a query.
Example 1: The following code dynamically constructs and executes a SubSonic query that searches for items matching a specified name. The query restricts the items displayed to those where owner matches the user name of the currently-authenticated user.

...
string userName = ctx.getAuthenticatedUserName();
string query = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ ItemName.Text + "'";

IDataReader responseReader = new InlineQuery().ExecuteReader(query);
...

The query intends to execute the following code:

	SELECT * FROM items
	WHERE owner = <userName>
	AND itemname = <itemName>;

However, because the query is constructed dynamically by concatenating a constant base query string and a user input string, the query only behaves correctly if itemName does not contain a single-quote character. If an attacker with the user name wiley enters the string "name' OR 'a'='a" for itemName, then the query becomes the following:

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name' OR 'a'='a';

The addition of the OR 'a'='a' condition causes the where clause to always evaluate to true, so the query becomes logically equivalent to the much simpler query:

	SELECT * FROM items;

This simplification of the query allows the attacker to bypass the requirement that the query must only return items owned by the authenticated user. The query now returns all entries stored in the items table, regardless of their specified owner.

Example 2: This example examines the effects of a different malicious value passed to the query constructed and executed in Example 1. If an attacker with the user name wiley enters the string "name'); DELETE FROM items; --" for itemName, then the query becomes the following two queries:

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	--'

Many database servers, including Microsoft(R) SQL Server 2000, allow multiple SQL statements separated by semicolons to be executed at once. While this attack string results in an error on Oracle and other database servers that do not allow the batch-execution of statements separated by semicolons, on databases that do allow batch execution, this type of attack allows the attacker to execute arbitrary commands against the database.

Notice the trailing pair of hyphens (--), which specifies to most database servers that the remainder of the statement is to be treated as a comment and not executed [4]. In this case the comment character serves to remove the trailing single-quote left over from the modified query. On a database where comments are not allowed to be used in this way, the general attack could still be made effective using a trick similar to the one shown in Example 1. If an attacker enters the string "name'); DELETE FROM items; SELECT * FROM items WHERE 'a'='a", the following three valid statements will be created:

	SELECT * FROM items
	WHERE owner = 'wiley'
	AND itemname = 'name';

	DELETE FROM items;

	SELECT * FROM items WHERE 'a'='a';

One traditional approach to preventing SubSonic injection attacks is to handle them as an input validation problem and either accept only characters from an allow list of safe values or identify and escape a list of potentially malicious values (deny list). Checking an allow list can be a very effective means of enforcing strict input validation rules, but parameterized SubSonic statements require less maintenance and can offer more guarantees with respect to security. As is almost always the case, implementing a deny list is riddled with loopholes that make it ineffective at preventing SubSonic SQL injection attacks. For example, attackers may:

- Target fields that are not quoted
- Find ways to bypass the need for certain escaped metacharacters
- Use stored procedures to hide the injected metacharacters

Manually escaping characters in input to SubSonic queries can help, but it will not make your application secure from SubSonic SQL injection attacks.

Another solution commonly proposed for dealing with SubSonic injection attacks is to use stored procedures. Although stored procedures prevent some types of SubSonic injection attacks, they fail to protect against many others. Stored procedures typically help prevent SubSonic SQL injection attacks by limiting the types of statements that can be passed to their parameters. However, there are many ways around the limitations and many interesting statements that can still be passed to stored procedures. Again, stored procedures can prevent some exploits, but they will not make your application secure against SubSonic injection attacks.

Any server containing sensitive information or privileged functionality, such as a remote administration panel, must require authentication for access. If this is not the case, an attacker can steal sensitive information or take control of a target host by simply guessing common user names.

The client can use the NoneAuth authentication method to determine the available authentication methods.

Example 1: The following Paramiko code tries to authenticate with the server using the "none" authentication request.

    client = SSHClient()
    client.connect(host, port, auth_strategy=NoneAuth("user"))

Single sign-on enables a service provider to use a single identity system across multiple applications without requiring that each application manage credential information separately. An identity provider verifies the user credentials and provides a token to the service provider to prove the user's validity. These tokens are the primary artifact the service provider uses to authenticate and authorize users into the service. These tokens are susceptible to replay attacks and can enable an attacker to impersonate a valid user and gain unauthorized access to the service. A network intruder with man-in-the-middle access or browser cache on a public kiosk could reveal this type of authentication token to malicious vectors. After attackers have access to a valid token, user credentials are not required, which could be secured with an additional two factor provision. Security Assertion Markup Language (SAML) tokens are a popular example of SSO tokens. A service provider can take several measures to prevent replay attacks for SAML tokens. These include setting a short token validity period and assigning a unique ID to each token request and response.

String termination errors occur when:

1. Data enters a program via a function that does not null-terminate its output.

2. The data is passed to a function that requires its input to be null-terminated.
Example 1: The following code reads from cfgfile and copies the input into inputbuf using strcpy(). The code mistakenly assumes that inputbuf will always contain a null-terminator.

#define MAXLEN 1024
...
char *pathbuf[MAXLEN];
...
read(cfgfile,inputbuf,MAXLEN); //does not null-terminate
strcpy(pathbuf,inputbuf); //requires null-terminated input
...

The code in Example 1 will behave correctly if the data read from cfgfile is null-terminated on disk as expected. But if an attacker is able to modify this input so that it does not contain the expected null character, the call to strcpy() will continue copying from memory until it encounters an arbitrary null character. This will likely overflow the destination buffer and, if the attacker may control the contents of memory immediately following inputbuf, can leave the application susceptible to a buffer overflow attack.

Example 2: In the following code, readlink() expands the name of a symbolic link stored in the buffer path so that the buffer buf contains the absolute path of the file referenced by the symbolic link. The length of the resulting value is then calculated using strlen().

...
char buf[MAXPATH];
...
readlink(path, buf, MAXPATH);
int length = strlen(buf);
...

The code in Example 2 will not behave correctly because the value read into buf by readlink() will not be null-terminated. In testing, vulnerabilities such as this one might not be caught because the unused contents of buf and the memory immediately following it may be null, thereby causing strlen() to appear as if it is behaving correctly. However, in the wild strlen() will continue traversing memory until it encounters an arbitrary null character on the stack, which results in a value of length that is much larger than the size of buf and may cause a buffer overflow in subsequent uses of this value.

Example 3: The following code uses snprintf() to copy a user input string and place it in multiple output strings. Despite providing additional guardrails compared to sprintf(), notably the specification of a maximum output size, the snprintf() function is still susceptible to a string termination error when the specified output size is larger than the prospective input. String termination errors can lead to downstream problems such as a memory leak or buffer overflow.

...
char no_null_term[5] = getUserInput();

char output_1[20];
snprintf(output_1, 20, "%s", no_null_term);

char output_2[20];
snprintf(output_2, 20, "%s", no_null_term);


printf("%s\n", output_1);
printf("%s\n", output_2);
...

The code in Example 3 demonstrates a memory leak. When output_2 is populated with no_null_term, snprintf() must read from the location of no_null_term until a null character is encountered or the specified size limit is reached. Because there is no termination in no_null_term, snprintf continues to read into the data of output_1 where it eventually reaches a null terminating character provided by the first call of snprintf(). The memory leak is demonstrated by the printf() of output_2, which contains the character sequence of no_null_term twice.

Traditionally, strings are represented as a region of memory containing data terminated with a null character. Older string-handling methods frequently rely on this null character to determine the length of the string. If a buffer that does not contain a null-terminator is passed to one of these functions, the function will read past the end of the buffer.

Malicious users typically exploit this type of vulnerability by injecting data with unexpected size or content into the application. They may provide the malicious input either directly as input to the program or indirectly by modifying application resources, such as configuration files. In the event that an attacker causes the application to read beyond the bounds of a buffer, the attacker may be able to use a resulting buffer overflow to inject and execute arbitrary code on the system.

Apache Struts 2.x included the new Aware interfaces to allow developers to easily inject maps with relevant runtime information into their Actions code. These interfaces include: org.apache.struts2.interceptor.ApplicationtAware, org.apache.struts2.interceptor.SessionAware and org.apache.struts2.interceptor.RequestAware. In order to get any of these data maps injected into their Actions code, developers need to implement the setter specified in the interface (eg: setSession for SessionAware Interface):

public class VulnerableAction extends ActionSupport implements SessionAware {

  protected Map<String, Object> session;

  @Override
  public void setSession(Map<String, Object> session) {
    this.session = session;
  }

On the other hand, Struts 2.x automatically binds the request data coming from the user to the Action's properties through public accessors defined in the Action. As the Aware interfaces require the implementation of the public setter defined in the Aware interface, this setter will also be automatically bound to any request parameter that matches the Aware interface setter name which might allow remote attackers to modify run-time data values via a crafted parameter to an application that implements an affected interface, as demonstrated by the SessionAware, RequestAware, ApplicationAware interfaces.

The following URL will let an attacker overwrite the "roles" attribute in the session map. This can potentially allow the attacker to become an administrator.

http://server/VulnerableAction?session.roles=admin


While these interfaces only require the implementation of the setter accessors, if the corresponding getter is also implemented, the changes to these map collections will be session-scoped persisted, rather than just affect the current request scope.

Struts 2 introduced a feature called "Dynamic Method Invocation" which allow an Action to expose methods other than execute(). The ! (bang) character or the method: prefix can be used in the Action URL to invoke any public method in the Action if "Dynamic Method Invocation" is enabled. Developers that are not aware of this feature can inadvertently expose internal business logic to attackers.

As an example, if the Action contains a public method called getUserPassword() that takes no arguments and fails to disable the "Dynamic Method Invocation" feature, an attacker will be able to take advantage of this visiting the following URL: http://server/app/recoverpassword!getPassword.action

Apache Struts 2.x included the new Aware interfaces to allow developers to easily inject maps with relevant runtime information into their Actions code. These interfaces include: org.apache.struts2.interceptor.ApplicationtAware, org.apache.struts2.interceptor.SessionAware and org.apache.struts2.interceptor.RequestAware. In order to get any of these data maps injected into their Actions code, developers need to implement the setter specified in the interface (eg: setSession for SessionAware Interface):

public class VulnerableAction extends ActionSupport implements SessionAware {

  protected Map<String, Object> session;

  @Override
  public void setSession(Map<String, Object> session) {
    this.session = session;
  }

On the other hand, Struts 2.x automatically binds the request data coming from the user to the Action's properties through public accessors defined in the Action. As the Aware interfaces require the implementation of the public setter defined in the Aware interface, this setter will also be automatically bound to any request parameter that matches the Aware interface setter name which might allow remote attackers to modify run-time data values via a crafted parameter to an application that implements an affected interface, as demonstrated by the SessionAware, RequestAware, ApplicationAware interfaces.

The following URL will let an attacker overwrite the "roles" attribute in the session map. This can potentially allow the attacker to become an administrator.

http://server/VulnerableAction?session.roles=admin


While these interfaces only require the implementation of the setter accessors, if the corresponding getter is also implemented, the changes to these map collections will be session-scoped persisted, rather than just affect the current request scope.

Apache Struts 2.x included the new Aware interfaces to allow developers to easily inject maps with relevant runtime information into their Actions code. These interfaces include: org.apache.struts2.interceptor.ApplicationtAware, org.apache.struts2.interceptor.SessionAware and org.apache.struts2.interceptor.RequestAware. In order to get any of these data maps injected into their Actions code, developers need to implement the setter specified in the interface (eg: setSession for SessionAware Interface):

public class VulnerableAction extends ActionSupport implements SessionAware {

  protected Map<String, Object> session;

  @Override
  public void setSession(Map<String, Object> session) {
    this.session = session;
  }

On the other hand, Struts 2.x automatically binds the request data coming from the user to the Action's properties through public accessors defined in the Action. As the Aware interfaces require the implementation of the public setter defined in the Aware interface, this setter will also be automatically bound to any request parameter that matches the Aware interface setter name which might allow remote attackers to modify run-time data values via a crafted parameter to an application that implements an affected interface, as demonstrated by the SessionAware, RequestAware, ApplicationAware interfaces.

The following URL will let an attacker overwrite the "roles" attribute in the session map. This can potentially allow the attacker to become an administrator.

http://server/VulnerableAction?session.roles=admin


While these interfaces only require the implementation of the setter accessors, if the corresponding getter is also implemented, the changes to these map collections will be session-scoped persisted, rather than just affect the current request scope.

One or more Action Fields do not have a corresponding validation definition. Each field should have an explicit validation routine referenced in ActionClass-validation.xml.

It is easy for developers to forget to update validation logic when they remove or rename action form mappings. One indication that validation logic is not being properly maintained is the lack of a validator definition.

It is critically important that validation logic be maintained and kept in sync with the rest of the application. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.

More than one field validator definition with the same name exist in ActionClass-validation.xml. Duplicate validation definitions with the same name may result in unexpected behavior.

Example 1: The following entry shows two duplicate field validator definitions.

   <field name="emailField">
      <field-validator type="email" short-circuit="true">
          <message>You must enter a value for email.</message>
      </field-validator>
      <field-validator type="email" short-circuit="true">
          <message>Not a valid email.</message>
      </field-validator>
  </field>
  

It is critically important that validation logic be maintained and kept in sync with the rest of the application. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.

More than one ActionClass-validation.xml file was discovered for this Struts2 Action definition. For each Struts2 Action defined in the form of ActionClass, Struts2 searches for a corresponding ActionClass-validation.xml for the necessary validation constraints. Having multiple validation definitions for one Action included in the deployment may result in unexpected behavior.

If two validation forms have the same name, the Struts Validator arbitrarily chooses one of the forms to use for input validation and discards the other. This decision might not correspond to the programmer's expectations. Moreover, it indicates that the validation logic is not being maintained, and can indicate that other, more subtle, validation errors are present.

It is critically important that validation logic be maintained and kept in sync with the rest of the application. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.

More than one validator definition was discovered in validators.xml. Multiple validation definitions with the same name may result in unexpected behavior.

If two validation classes are defined with the same name, the Struts Validator arbitrarily chooses one of the forms to use for input validation and discards the other. This decision might not correspond to the programmer's expectations. Moreover, it indicates that the validation logic is not being maintained, and can indicate that other, more subtle, validation errors are present.

It is critically important that validation logic be maintained and kept in sync with the rest of the application. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.

Struts2 requires that custom validators be defined in validators.xml before being used in a Action validator definition. Missing validator definitions are an indication that validation is not up to date.

Example 1: The following Action validator was not defined in validators.xml.

<validators>
    <validator name="required" class="com.opensymphony.xwork2.validator.validators.RequiredFieldValidator"/>
</validators>

It is critically important that validation logic be maintained and kept in sync with the rest of the application. Unchecked input is the root cause of some of today's worst and most common software security problems. Cross-site scripting, SQL injection, and process control vulnerabilities all stem from incomplete or absent input validation. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.

Unchecked input is the leading cause of vulnerabilities in J2EE applications. Unchecked input can lead to numerous vulnerabilities, including cross-site scripting, process control, and SQL injection. Although J2EE applications are not generally susceptible to memory corruption attacks, if a J2EE application interfaces with native code that does not perform array bounds checking, an attacker may be able to use an input validation mistake in the J2EE application to launch a buffer overflow attack.

To prevent such attacks, use the Struts Validation framework to check all program input before it is processed by the application. Use Fortify Static Code Analyzer to ensure that there are no holes in your configuration of the Struts Validator.

Example uses of the validator include checking to ensure that:

- Phone number fields contain only valid characters in phone numbers

- Boolean values are only "T" or "F"

- Free-form strings are of a reasonable length and composition

A Struts2 Validation file was discovered without a matching Struts2 Action. For each ActionClass, Struts2 searches for a corresponding ActionClass-validation.xml for the necessary validation constraints. In this case, a validation file in the form of ActionClass-validation.xml was found, but ActionClass does not match an Action defined in the Struts2 configuration file.

It is easy for developers to forget to update validation logic when they remove or rename action form mappings. One indication that validation logic is not being properly maintained is the presence of an unused validation form.

A Struts2 validator definition refers to an action field that does not exist.

It is easy for developers to forget to update validation logic when they remove or rename action form mappings. One indication that validation logic is not being properly maintained is the presence of an orphaned validator definition.

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>