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

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.

The identified field does not disable iOS' keyboard caching mechanism. As a result, any sensitive information recently entered into the field will be cached by iOS in an effort to improve its autocorrection feature.

Example 1: Input entered into a sensitive text field is stored in the system's keyboard cache:

ViewController.h
...

@property (nonatomic, retain) IBOutlet UITextField *ssnField;

...

The code in Example 1 indicates that the app utilizes an input control designed to collect sensitive information. As iOS caches input into text fields in order to improve the performance of its autocorrection feature, any information recently entered into such an input control may be cached within a keyboard cache file saved to the file system. Because the keyboard cache file is stored on the device, if the device is lost, it may be recovered, thereby revealing any sensitive information contained within.

Private data can enter a program in a variety of ways:

- Directly from the user in the form of a password or personal information.

- Accessed from a database or other data store by the application.

- Indirectly from a partner or other third party.

- Retrieved from mobile data stores including: Address book, snapped photos, geolocation, configuration files, archived SMS messages, etc.

Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates student identification based on student social security numbers, then the identification numbers should be considered private.

Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can create additional risk.

Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable to store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, it does not guarantee that the individuals who do have access can be trusted with certain data. For example, in 2004, an unscrupulous employee at AOL sold approximately 92 million private customer email addresses to a spammer marketing an offshore gambling web site [1].

In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Despite these regulations, privacy violations continue to occur with alarming frequency.

The identified UIViewController subclass does not implement the appropriate methods used to hide screen elements before iOS caches the screen's contents. This will reveal any sensitive information that has been entered within input controls before an app is backgrounded.

Example 1: Input entered into iOS text controls may be stored in a screenshot taken when an app is backgrounded (i.e. the "Home" button is pressed while the app is active).

ViewController.h
...

@property (nonatomic, retain) IBOutlet UITextField *ssnField;

...

The code in Example 1 indicates that the app utilizes an input control designed to collect sensitive information. As iOS takes a screenshot of the active view of an app when it is backgrounded in order to improve animation performance, any information displayed in such input controls during the background event may be cached within an image saved to the file system. Because these screen cache screenshots are stored on the device, if the device is lost, they may be recovered, thereby revealing any sensitive information contained within.

Private data can enter a program in a variety of ways:

- Directly from the user in the form of a password or personal information.

- Accessed from a database or other data store by the application.

- Indirectly from a partner or other third party.

- Retrieved from mobile data stores including: address book, snapped photos, geolocation, configuration files, archived SMS messages, etc.

Sometimes data that is not labeled as private can have a privacy implication in a different context. For example, student identification numbers are usually not considered private because there is no explicit and publicly-available mapping to an individual student's personal information. However, if a school generates student identification based on student social security numbers, then the identification numbers should be considered private.

Security and privacy concerns often seem to compete with each other. From a security perspective, you should record all important operations so that any anomalous activity can later be identified. However, when private data is involved, this practice can create additional risk.

Although there are many ways in which private data can be handled unsafely, a common risk stems from misplaced trust. Programmers often trust the operating environment in which a program runs, and therefore believe that it is acceptable to store private information on the file system, in the registry, or in other locally-controlled resources. However, even if access to certain resources is restricted, it does not guarantee that the individuals who do have access can be trusted with certain data. For example, in 2004, an unscrupulous employee at AOL sold approximately 92 million private customer email addresses to a spammer marketing an offshore gambling web site [1].

In response to such high-profile exploits, the collection and management of private data is becoming increasingly regulated. Depending on its location, the type of business it conducts, and the nature of any private data it handles, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [3]

- Gramm-Leach Bliley Act (GLBA) [4]

- Health Insurance Portability and Accountability Act (HIPAA) [5]

- California SB-1386 [6]

Despite these regulations, privacy violations continue to occur with alarming frequency.

When storing data into the Keychain, an accessibility level needs to be set up which defines when it will be possible to access the item. The possible accessibility levels include:

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
The data in the Keychain item cannot be accessed after a restart until the device has been unlocked once by the user.
After the first unlock, the data remains accessible until the next restart. This is recommended for items that need to be accessed by background applications. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

-kSecAttrAccessibleAlways:
The data in the Keychain item can always be accessed regardless of whether the device is locked.
This is not recommended for application use. Items with this attribute migrate to a new device when using encrypted backups.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
The data in the Keychain can only be accessed when the device is unlocked. Only available if a passcode is set on the device.
This is recommended for items that only need to be accessible while the application is in the foreground. Items with this attribute never migrate to a new device. After a backup is restored to a new device, these items are missing. No items can be stored in this class on devices without a passcode. Disabling the device passcode causes all items in this class to be deleted.
Available in iOS 8.0 and later.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
The data in the Keychain item can always be accessed regardless of whether the device is locked.
This is not recommended for application use. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenUnlocked:
The data in the Keychain item can be accessed only while the device is unlocked by the user.
This is recommended for items that need to be accessible only while the application is in the foreground. Items with this attribute migrate to a new device when using encrypted backups.
This is the default value for Keychain items added without explicitly setting an accessibility constant.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
The data in the Keychain item can be accessed only while the device is unlocked by the user.
This is recommended for items that need to be accessible only while the application is in the foreground. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

The accessibility levels which do not contain the ThisDeviceOnly will be backed up to iCloud and backed up to iTunes even if using unencrypted backups which can be restored to any device. Depending on how sensitive and private the stored data is, this may raise a privacy concern.

Example 1: In the following example the Keychain item is protected at all times, except when the device is powered on and unlocked but the Keychain item will be backed up to iCloud and to unencrypted iTunes backups:

...
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

    // Configure KeyChain Item
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:(__bridge id)kSecAttrAccessibleWhenUnlocked forKey:(__bridge id) kSecAttrAccessible];

    OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...

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.



iBatis Data Maps allow you to specify dynamic parameters in SQL statements and are typically defined by using the # characters, as follows:

    <select id="getItems" parameterClass="MyClass" resultClass="items">
        SELECT * FROM items WHERE owner = #userName#
    </select>

The # characters around the variable name indicate that iBatis will create a parameterized query with the userName variable. However, iBatis also allows you to concatenate variables directly to SQL statements using $ characters, 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" parameterClass="MyClass" resultClass="items">
        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 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 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 occur when:

1. Data enters a program from an untrusted source.



2. The data is used to dynamically construct a SQL or JDOQL 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 itemName = request.getParameter("itemName");
	String sql = "SELECT * FROM items WHERE owner = '"
				+ userName + "' AND itemname = '"
				+ itemName + "'";
	Query query = pm.newQuery(Query.SQL, sql);
	query.setClass(Person.class);
	List people = (List)query.execute();
	...

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.

Mapping of the application attack surface and discovering hidden or restricted resources is a primary goal of an attacker and is often achieved through automated crawling methods. Similarly, search engines discover information about your site by employing software known as "spiders" to crawl the web. After the spiders find a site, they follow links within the site to gather information about all the pages. The spiders periodically revisit sites to find new or changed content.

Sitemap programs provide a detailed view of a website and its organization. Attackers and search bots can use these programs in addition to crawling and indexing a site. Including sensitive and otherwise restricted resources in the sitemap output could expose sensitive functionality to compromise and aid in the attacker discovery process.

The Keychain accessibility constants are designed to let applications declare when items in the Keychain should be accessible. By specifying one of accessibility constants for a given Keychain item, a developer can instruct the underlying file system to encrypt it either using a key derived from both the device's UID and the user's passcode or using a key solely based on the device's UID (as well as when to automatically decrypt it).

The Keychain accessibility constants are meant to be assigned as the value for the kSecAttrAccessible key in the Keychain attribute dictionary. The definitions for the various Keychain accessibility constants are as follows:

-kSecAttrAccessibleAfterFirstUnlock:
The data in the Keychain item cannot be accessed after a restart until the device has been unlocked once by the user.
After the first unlock, the data remains accessible until the next restart. This is recommended for items that need to be accessed by background applications. Items with this attribute migrate to a new device when using encrypted backups.
Available in iOS 4.0 and later.

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
The data in the Keychain item cannot be accessed after a restart until the device has been unlocked once by the user.
After the first unlock, the data remains accessible until the next restart. This is recommended for items that need to be accessed by background applications. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

-kSecAttrAccessibleAlways:
The data in the Keychain item can always be accessed regardless of whether the device is locked.
This is not recommended for application use. Items with this attribute migrate to a new device when using encrypted backups.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
The data in the Keychain can only be accessed when the device is unlocked. Only available if a passcode is set on the device.
This is recommended for items that only need to be accessible while the application is in the foreground. Items with this attribute never migrate to a new device. After a backup is restored to a new device, these items are missing. No items can be stored in this class on devices without a passcode. Disabling the device passcode causes all items in this class to be deleted.
Available in iOS 8.0 and later.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
The data in the Keychain item can always be accessed regardless of whether the device is locked.
This is not recommended for application use. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenUnlocked:
The data in the Keychain item can be accessed only while the device is unlocked by the user.
This is recommended for items that need to be accessible only while the application is in the foreground. Items with this attribute migrate to a new device when using encrypted backups.
This is the default value for Keychain items added without explicitly setting an accessibility constant.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
The data in the Keychain item can be accessed only while the device is unlocked by the user.
This is recommended for items that need to be accessible only while the application is in the foreground. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

So, while marking a Keychain item with kSecAttrAccessibleAfterFirstUnlock will afford it encryption using a key derived from the user's passcode and the device's UID, the data will still remain accessible under certain circumstances. As such, usages of kSecAttrAccessibleAfterFirstUnlock should be carefully reviewed to determine if further protection is warranted.

Example 1: In the following example, the given Keychain item is only protected until the user powers on the device and provides their passcode for the first time (until the next reboot):

...
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

    // Configure KeyChain Item
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:(__bridge id)kSecAttrAccessibleAfterFirstUnlock forKey:(__bridge id) kSecAttrAccessible];

    OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...

The Keychain accessibility constants are designed to let applications declare when items in the Keychain should be accessible. By specifying one of the accessibility constants for a given Keychain item, a developer can instruct the underlying file system to encrypt it either using a key derived from both the device's UID and the user's passcode or using a key solely based on the device's UID (as well as when to automatically decrypt it).

The Keychain accessibility constants are meant to be assigned as the value for the kSecAttrAccessible key in the Keychain attribute dictionary. The definitions for the various Keychain accessibility constants are as follows:

-kSecAttrAccessibleAfterFirstUnlock:
The data in the Keychain item cannot be accessed after a restart until the device has been unlocked once by the user.
After the first unlock, the data remains accessible until the next restart. This is recommended for items that need to be accessed by background applications. Items with this attribute migrate to a new device when using encrypted backups.
Available in iOS 4.0 and later.

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
The data in the Keychain item cannot be accessed after a restart until the device has been unlocked once by the user.
After the first unlock, the data remains accessible until the next restart. This is recommended for items that need to be accessed by background applications. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

-kSecAttrAccessibleAlways:
The data in the Keychain item can always be accessed regardless of whether the device is locked.
This is not recommended for application use. Items with this attribute migrate to a new device when using encrypted backups.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
The data in the Keychain can only be accessed when the device is unlocked. Only available if a passcode is set on the device.
This is recommended for items that only need to be accessible while the application is in the foreground. Items with this attribute never migrate to a new device. After a backup is restored to a new device, these items are missing. No items can be stored in this class on devices without a passcode. Disabling the device passcode causes all items in this class to be deleted.
Available in iOS 8.0 and later.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
The data in the Keychain item can always be accessed regardless of whether the device is locked.
This is not recommended for application use. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenUnlocked:
The data in the Keychain item can be accessed only while the device is unlocked by the user.
This is recommended for items that need to be accessible only while the application is in the foreground. Items with this attribute migrate to a new device when using encrypted backups.
This is the default value for Keychain items added without explicitly setting an accessibility constant.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
The data in the Keychain item can be accessed only while the device is unlocked by the user.
This is recommended for items that need to be accessible only while the application is in the foreground. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

Even though all files on an iOS device, including those without an explicitly assigned Keychain accessibility constant, are stored in an encrypted form, specifying kSecAttrAccessibleAlways results in encryption using a key derived solely based on the device's UID. This leaves such files accessible any time the device is powered on, including when locked with a passcode or when booting. As such, usages of kSecAttrAccessibleAlways should be carefully reviewed to determine if further protection with a stricter Keychain accessibility level is warranted.

Example 1: In the following example, the given file is not protected (accessible anytime the device is powered on):

...
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

    // Configure KeyChain Item
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:(__bridge id)kSecAttrAccessibleAlways forKey:(__bridge id) kSecAttrAccessible];

    OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...

Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a cloud-hosted web application through an untrusted source. In the case of Inter-Component Communication Cloud XSS, the untrusted source is data received from other components of the cloud application through communication channels provided by the cloud host.


2. The data is included in dynamic content that is sent to a web user without validation.

The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

Example 1: The following ASP.NET Web Form queries the Azure Table Service for an employee and prints the name.

<script runat="server">
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;
</script>

Where EmployeeName is a form control defined as follows:

<form runat="server">
   ...
   <asp:Label id="EmployeeName" runat="server">
   ...
</form>

Example 2: The following ASP.NET code segment is functionally equivalent to Example 1, but implements all of the form elements programmatically.

protected System.Web.UI.WebControls.Label EmployeeName;
...
var retrieveOperation = TableOperation.Retrieve<EmployeeInfo>(partitionKey, rowKey);
var retrievedResult = employeeTable.Execute(retrieveOperation);
var employeeInfo = retrievedResult.Result as EmployeeInfo;
string name = employeeInfo.Name
...
EmployeeName.Text = name;

These code examples function correctly when the values of Name are well-behaved, but they do nothing to prevent exploits if they are not. This code can appear less dangerous because the value of Name is read from a cloud-provided storage service, whose contents are apparently managed by the distributed application. However, if the value of Name originates from user-supplied data, then the cloud-provided storage service can be a conduit for malicious content. Without proper input validation on all data stored in the database, an attacker may execute malicious commands in the user's web browser. This type of exploit, known as Inter-Component Communication Cloud XSS, is particularly insidious because the indirection caused by the data store makes it difficult to identify the threat and increases the possibility that the attack might affect multiple users. XSS got its start in this form with web sites that offered a "guestbook" to visitors. Attackers would include JavaScript in their guestbook entries, and all subsequent visitors to the guestbook page would execute the malicious code.

Example 3: The following ASP.NET Web Form reads an employee ID number from an HTTP request and displays it to the user.

<script runat="server">
...
EmployeeID.Text = Login.Text;
...
</script>

Where Login and EmployeeID are form controls defined as follows:

<form runat="server">
   <asp:TextBox runat="server" id="Login"/>
   ...
   <asp:Label runat="server" id="EmployeeID"/>
</form>

Example 4: The following ASP.NET code segment shows the programmatic way to implement Example 3.

protected System.Web.UI.WebControls.TextBox Login;
protected System.Web.UI.WebControls.Label EmployeeID;
...
EmployeeID.Text = Login.Text;

As in Example 1 and Example 2, these examples operate correctly if Login contains only standard alphanumeric text. If Login has a value that includes metacharacters or source code, then the code will be executed by the web browser as it displays the HTTP response.

Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks in order to lure victims into clicking a link. When the victims click the link, they unwittingly reflect the malicious content through the vulnerable web application and back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.

As the examples demonstrate, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:

- As in Example 1 and Example 2, the application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Inter-Component Communication Cloud XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.

- As in Example 3 and Example 4, data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.

- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.

A number of modern web frameworks provide mechanisms to perform user input validation (including ASP.NET Request Validation and WCF). To highlight the unvalidated sources of input, Fortify Secure Coding Rulepacks dynamically re-prioritize the issues Fortify Static Code Analyzer reports by lowering their probability of exploit and providing pointers to the supporting evidence whenever the framework validation mechanism is in use. With ASP.NET Request Validation, we also provide evidence for when validation is explicitly disabled. We refer to this feature as Context-Sensitive Ranking. To further assist the Fortify user with the auditing process, the Fortify Software Security Research group makes available the Data Validation project template that groups the issues into folders based on the validation mechanism applied to their source of input.

Leaks of private health information occur when:

1. User's health information enters the program.

2. The data is written to an external location, such as the console, file system, or network.
Example 1: The following code retrieves the user blood type from the HealthKit store and sends it to a server, while logging it to the device. Although many developers trust the log files as a safe storage location for any and all data, it should not be trusted implicitly, particularly when privacy is a concern.

    ...
    HKHealthStore healthStore = new HKHealthStore();
    HKBloodTypeObject blood = healthStore.GetBloodType(null);

    NSLog("%@", blood.BloodType);

	var urlWithParams = String.format(TOKEN_URL, block.BloodType);
	var responseString = await client.GetStringAsync(urlWithParams);
    ...

Note: The Apple Logging API, which is at a lower level than the NSLog function, allows a developer to create an app which may read all logs on the device (even when they don't own the other apps).

Other areas of concern for maintaining the privacy of user data arise when a device has been lost or stolen. Once in possession of an iOS device, an attacker may access a great deal of data by connecting the device by USB. Files such as iOS Property Lists (plists) and SQLite databases are easily accessed and can disclose personal information. As a general rule, private health details should not be stored unprotected on the file system.

Example 2: The following code adds the user's blood type to the list of user defaults, and stores them immediately to a plist file.

    ...
    HKHealthStore healthStore = new HKHealthStore();
    HKBloodTypeObject blood = healthStore.GetBloodType(null);

    // Add blood type to user defaults
	NSUserDefaults.StandardUserDefaults.SetString(blood.BloodType, "bloodType");
    ...

In response to private data being mishandled, the collection and management of private data is becoming increasingly regulated. In regards to health information, an organization may be required to comply with one or more of the following federal and state regulations:

- Safe Harbor Privacy Framework [2]

- Gramm-Leach Bliley Act (GLBA) [3]

- Health Insurance Portability and Accountability Act (HIPAA) [4]

- California SB-1386 [5]

Despite these regulations, privacy violations continue to occur with alarming frequency.

Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web application through an untrusted source. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.


2. The data is included in dynamic content that is sent to a web user without validation.

The malicious content sent to the web browser often takes the form of a JavaScript segment, but may also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

For the browser to render the response as HTML, or other document that may execute scripts, it has to specify a text/html MIME type. Therefore, XSS is only possible if the response uses this MIME type or any other that also forces the browser to render the response as HTML or other document that may execute scripts such as SVG images (image/svg+xml), XML documents (application/xml), etc.

Most modern browsers do not render HTML or execute scripts when provided a response with MIME types such as application/octet-stream. However, some browsers such as Internet Explorer perform what is known as Content Sniffing. Content Sniffing involves ignoring the provided MIME type and attempting to infer the correct MIME type by the contents of the response.
It is worth noting however, a MIME type of text/html is only one such MIME type that may lead to XSS vulnerabilities. Other documents that may execute scripts such as SVG images (image/svg+xml), XML documents (application/xml), as well as others may lead to XSS vulnerabilities regardless of whether the browser performs Content Sniffing.

Therefore, a response such as <html><body><script>alert(1)</script></body></html>, could be rendered as HTML even if its content-type header is set to application/octet-stream, multipart-mixed, and so on.

Example 1: The following JAX-RS method reflects user data in an application/octet-stream response.

@RestController
public class SomeResource {
    @RequestMapping(value = "/test", produces = {MediaType.APPLICATION_OCTET_STREAM_VALUE})
    public String response5(@RequestParam(value="name") String name){
        return name;
    }
}

If an attacker sends a request with the name parameter set to <html><body><script>alert(1)</script></body></html>, the server will produce the following response:

HTTP/1.1 200 OK
Content-Length: 51
Content-Type: application/octet-stream
Connection: Closed

<html><body><script>alert(1)</script></body></html>

Even though, the response clearly states that it should be treated as a JSON document, an old browser may still try to render it as an HTML document, making it vulnerable to a Cross-Site Scripting attack.

Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web application through an untrusted source. In the case of DOM-based XSS, data is read from a URL parameter or other value within the browser and written back into the page with client-side code. In the case of reflected XSS, the untrusted source is typically a web request, while in the case of persisted (also known as stored) XSS it is typically a database or other back-end data store.


2. The data is included in dynamic content that is sent to a web user without validation. In the case of DOM-based XSS, malicious content is executed as part of DOM (Document Object Model) creation, whenever the victim's browser parses the HTML page.

The malicious content sent to the web browser often takes the form of a JavaScript segment, but can also include HTML, Flash or any other type of code that the browser executes. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site.

Example 1: The following JavaScript code segment reads an employee ID, eid, from an HTTP request and displays it to the user.

String queryString = Window.Location.getQueryString();
int pos = queryString.indexOf("eid=")+4;
HTML output = new HTML();
output.setHTML(queryString.substring(pos, queryString.length()));

The code in this example operates correctly if eid contains only standard alphanumeric text. If eid has a value that includes metacharacters or source code, then the code is executed by the web browser as it displays the HTTP response.

Initially this might not appear to be much of a vulnerability. After all, why would someone enter a URL that causes malicious code to run on their own computer? The real danger is that an attacker will create the malicious URL, then use email or social engineering tricks to lure victims into visiting a link to the URL. When victims click the link, they unwittingly reflect the malicious content through the vulnerable web application back to their own computers. This mechanism of exploiting vulnerable web applications is known as Reflected XSS.


As the example demonstrates, XSS vulnerabilities are caused by code that includes unvalidated data in an HTTP response. There are three vectors by which an XSS attack can reach a victim:

- Data is read directly from the HTTP request and reflected back in the HTTP response. Reflected XSS exploits occur when an attacker causes a user to supply dangerous content to a vulnerable web application, which is then reflected back to the user and executed by the web browser. The most common mechanism for delivering malicious content is to include it as a parameter in a URL that is posted publicly or emailed directly to victims. URLs constructed in this manner constitute the core of many phishing schemes, whereby an attacker convinces victims to visit a URL that refers to a vulnerable site. After the site reflects the attacker's content back to the user, the content is executed and proceeds to transfer private information, such as cookies that might include session information, from the user's machine to the attacker or perform other nefarious activities.

- The application stores dangerous data in a database or other trusted data store. The dangerous data is subsequently read back into the application and included in dynamic content. Persistent XSS exploits occur when an attacker injects dangerous content into a data store that is later read and included in dynamic content. From an attacker's perspective, the optimal place to inject malicious content is in an area that is displayed to either many users or particularly interesting users. Interesting users typically have elevated privileges in the application or interact with sensitive data that is valuable to the attacker. If one of these users executes malicious content, the attacker may be able to perform privileged operations on behalf of the user or gain access to sensitive data belonging to the user.

- A source outside the application stores dangerous data in a database or other data store, and the dangerous data is subsequently read back into the application as trusted data and included in dynamic content.

Prototype pollution is an attack that allows a malicious user to overwrite the prototype of an object.
To understand prototype pollution, you must first understand prototypal inheritance. Prototypes and the prototype chain is used as a lookup for properties and functions in JavaScript, providing inheritance. When attempting to access a property on a given object, the current object definition is checked. If the current object does not define the property, the prototype class is checked. The prototypes are recursively checked until either the property is found, or there are no more prototypes set.

Because most objects in JavaScript by default have a prototype pointing to Object.prototype, if an attacker can overwrite the prototype of an object, they can typically overwrite the definition of Object.prototype, affecting all objects within the application.

If the application (or any of its dependencies) relies on the fact that properties can be undefined rather than always being explicitly set, then if the prototype has been polluted, the application might inadvertently read from the prototype instead of the intended object.

Prototype pollution occur can when:

1. Data enters a program from an untrusted source.



2. The data is passed to an API that allows overwriting the prototype.

Example 1: The following code uses a vulnerable version of lodash to pollute the prototype of the object:

import * as lodash from 'lodash'
...
let clonedObject = lodash.merge({}, JSON.parse(untrustedInput));
...

At this point, if the untrusted input is {"__proto__": { "isAdmin": true}}, then Object.prototype will have defined isAdmin = true.

Consider the following code that exists later in the application.

...
let config = {}
if (isAuthorizedAsAdmin()){
    config.isAdmin = true;
}
...
if (config.isAdmin) {
    // do something as the admin
}
...

Even though isAdmin should only be set to true if isAuthorizedAdmin() returns true, because the application fails to set config.isAdmin = false in the else condition, it relies upon the fact that config.isAdmin === undefined === false.
Unfortunately, as the prototype has been polluted, the prototype of config has now set isAdmin === true, which allows the administrator authorization to be bypassed.

The Keychain accessibility levels define when the Keychain items are decrypted and made available for apps. The possible accessibility levels include:

-kSecAttrAccessibleAfterFirstUnlockThisDeviceOnly:
The data in the Keychain item cannot be accessed after a restart until the device has been unlocked once by the user.
After the first unlock, the data remains accessible until the next restart. This is recommended for items that need to be accessed by background applications. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

-kSecAttrAccessibleAlways:
The data in the Keychain item can always be accessed regardless of whether the device is locked.
This is not recommended for application use. Items with this attribute migrate to a new device when using encrypted backups.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly:
The data in the Keychain can only be accessed when the device is unlocked. Only available if a passcode is set on the device.
This is recommended for items that only need to be accessible while the application is in the foreground. Items with this attribute never migrate to a new device. After a backup is restored to a new device, these items are missing. No items can be stored in this class on devices without a passcode. Disabling the device passcode causes all items in this class to be deleted.
Available in iOS 8.0 and later.

-kSecAttrAccessibleAlwaysThisDeviceOnly:
The data in the Keychain item can always be accessed regardless of whether the device is locked.
This is not recommended for application use. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenUnlocked:
The data in the Keychain item can be accessed only while the device is unlocked by the user.
This is recommended for items that need to be accessible only while the application is in the foreground. Items with this attribute migrate to a new device when using encrypted backups.
This is the default value for Keychain items added without explicitly setting an accessibility constant.
Available in iOS 4.0 and later.

-kSecAttrAccessibleWhenUnlockedThisDeviceOnly:
The data in the Keychain item can be accessed only while the device is unlocked by the user.
This is recommended for items that need to be accessible only while the application is in the foreground. Items with this attribute do not migrate to a new device. Thus, after restoring from a backup of a different device, these items will not be present.
Available in iOS 4.0 and later.

If the Keychain items are stored with a reasonably secure policy such as kSecAttrAccessibleWhenUnlocked, then if your device gets stolen and a passcode is set, the theft will need to unlock the device in order for the Keychain items to be decrypted. Failing to enter the right passcode will block the theft from decrypting the Keychain items. However, if the passcode is not set, the attacker just needs to slide his finger to unlock the device and get the Keychain to decrypt its items. Therefore, failing to enforce a passcode in the device may weaken the Keychain encryption mechanism.

Example 1: In the following example the Keychain item is protected at all times, except when the device is powered on and unlocked, but also available if a passcode is not set on the device:

...
    NSMutableDictionary *dict = [NSMutableDictionary dictionary];
    NSData *token = [@"secret" dataUsingEncoding:NSUTF8StringEncoding];

    // Configure KeyChain Item
    [dict setObject:(__bridge id)kSecClassGenericPassword forKey:(__bridge id) kSecClass];
    [dict setObject:token forKey:(__bridge id)kSecValueData];
    ...
    [dict setObject:(__bridge id)kSecAttrAccessibleWhenUnlockedThisDeviceOnly forKey:(__bridge id) kSecAttrAccessible];

    OSStatus error = SecItemAdd((__bridge CFDictionaryRef)dict, NULL);
...

All web forms in the application must be protected against automated submissions. An attacker can automatically submit fill and submit registration forms to create fake accounts or overwhelm the database. Contact and messaging forms that do not prevent automated form submissions can be used to spam the application administrators or users. Automated password cracking programs can target login forms with ineffective anti-automation mechanisms. Programmers must always assume that all user interfaces will be abused by attackers in order to find weaknesses.

Many talented individuals have spent a great deal of time pondering ways to make double-checked locking work in order to improve performance. None have succeeded.

Example 1: At first blush it may seem that the following bit of code achieves thread safety while avoiding unnecessary synchronization.

if (fitz == null) {
  synchronized (this) {
    if (fitz == null) {
      fitz = new Fitzer();
    }
  }
}
return fitz;

The programmer wants to guarantee that only one Fitzer() object is ever allocated, but does not want to pay the cost of synchronization every time this code is called. This idiom is known as double-checked locking.

Unfortunately, it does not work, and multiple Fitzer() objects can be allocated. See The "Double-Checked Locking is Broken" Declaration for more details [1].