Injection errors related to LINQ 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 an LINQ 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 + "'";

var items = dataContext.ExecuteCommand<Item>(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 LINQ 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 LINQ 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 LINQ 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 LINQ queries can help, but it will not make your application secure from LINQ injection attacks.

Another solution commonly proposed for dealing with LINQ injection attacks is to use stored procedures. Although stored procedures prevent some types of LINQ injection attacks, they fail to protect against many others. Stored procedures typically help prevent LINQ 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 LINQ injection attacks.

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.



MyBatis Mapper XML files allow you to specify dynamic parameters in SQL statements and are typically defined by using the # characters, as follows:

    <select id="getItems" parameterType="domain.company.MyParamClass" resultType="MyResultMap">
        SELECT *
        FROM items
        WHERE owner = #{userName}
    </select>

The # character with braces around the variable name indicate that MyBatis will create a parameterized query with the userName variable. However, MyBatis also allows you to concatenate variables directly to SQL statements using the $ character, opening the door for SQL injection.

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

    <select id="getItems" parameterType="domain.company.MyParamClass" resultType="MyResultMap">
        SELECT *
        FROM items
        WHERE owner = #{userName}
        AND itemname = ${itemName}
    </select>

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 should 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 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 guarantee that an application is secure against 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 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 code dynamically constructs and executes a SQL 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 + "'";
	List items = sess.CreateSQLQuery(query).List();
	...

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 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 an 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 types of exploits, but they will not make your application secure against SQL injection attacks.

SQL Injection: PartiQL issues occur when:

1. Data enters a program from an untrusted source.

2. The data is used to dynamically construct a PartiQL query.
Example 1: The following code dynamically constructs and executes a PartiQL 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 = identity.getUser();
String itemName = apiGatewayProxyRequest.getQueryStringParameters('item');
String statement = String.format("SELECT * FROM items WHERE owner = '%s' AND itemname = '%s'", userName, itemName);
ExecuteStatementRequest executeStatementRequest = new ExecuteStatementRequest();
executeStatementRequest.setStatement(statement);
ExecuteStatementResponse executeStatementResponse = dynamoDBClient.executeStatement(executeStatementRequest);
return displayResults(executeStatementResponse.items());
...

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:
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 PartiQL queries can help, but it will not make your application secure from PartiQL injection attacks.

SQL injection errors occur when:

1. Data enters a program from an untrusted source.

In this case, Fortify Static Code Analyzer could not determine that the source of the data is trusted.

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

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

...
        String userName = ctx.getAuthenticatedUserName();
        String itemName = request.getParameter("itemName");
        String query = "SELECT * FROM items WHERE owner = '"
                                + userName + "' AND itemname = '"
                                + itemName + "'";
        ResultSet rs = stmt.execute(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 used 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';

Some think that in the mobile world, classic web application vulnerabilities, such as SQL injection, do not make sense -- why would the user attack themself? However, keep in mind that the essence of mobile platforms is applications that are downloaded from various sources and run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which necessitates expanding the attack surface of mobile applications to include inter-process communication.

Example 3: The following code adapts Example 1 to the Android platform.

...
        PasswordAuthentication pa = authenticator.getPasswordAuthentication();
        String userName = pa.getUserName();
        String itemName = this.getIntent().getExtras().getString("itemName");
        String query = "SELECT * FROM items WHERE owner = '"
                                + userName + "' AND itemname = '"
                                + itemName + "'";
        SQLiteDatabase db = this.openOrCreateDatabase("DB", MODE_PRIVATE, null);
        Cursor c = db.rawQuery(query, null);
...

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.

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.

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.

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.

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.

Example 1: Two validation forms with the same name.

<form-validation>
    <formset>
        <form name="ProjectForm">
        ...
        </form>
        <form name="ProjectForm">
        ...
        </form>
    </formset>
</form-validation>

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.

The Struts Validator uses a form's validate() method to check the contents of the form properties against the constraints specified in the associated validation form. That means the following classes have a validate() method that is part of the validation framework:

    ValidatorForm
    ValidatorActionForm
    DynaValidatorForm
    DynaValidatorActionForm

If you create a class that extends one of these classes and if your class implements custom validation logic by overriding the validate() method, you must call super.validate() in your validate() implementation. If you do not, the Validation Framework cannot check the contents of the form against a validation form. In other words, the validation framework will be disabled for the given form.

Disabling the validation framework for a form exposes the application to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like 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.

In order to use the Struts Validator, a form must extend one of the following:

ValidatorForm
ValidatorActionForm
DynaValidatorActionForm
DynaValidaorForm

You must extend one of these classes because the Struts Validator ties in to your application by implementing the validate() method in these classes.

Forms derived from the following classes cannot use the Struts Validator:

ActionForm
DynaActionForm

Bypassing the validation framework for a form exposes the application to numerous types of attacks. Unchecked input is the root cause of vulnerabilities like 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.

Omitting validation for even a single input field can allow attackers the leeway they need.

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.

Some applications use the same ActionForm for more than one purpose. In situations such as this, some fields may go unused under some action mappings. It is critical that unused fields be validated too. Preferably, unused fields should be constrained so that they can only be empty or undefined. If unused fields are not validated, shared business logic in an action could allow attackers to bypass the validation checks that are performed for other uses of the form.