Setting manipulation vulnerabilities occur when an attacker can control values that govern the behavior of the system, manage specific resources, or in some way affect the functionality of the application.
Allowing a user to control the character encoding used to parse the HTTP response of a given request can allow an attacker to evade certain validation mechanisms used for Cross-site Scripting.
The response character encoding is used by a web browser to decide how to interpret the characters in the body of the HTTP response. The most common encoding used by web applications today is UTF-8. The character set (charset) declaration is usually done through a header in the HTTP response or using the HTML <meta> tag. Only the application should control these declarations. If this declaration is controlled through user input, then an attacker can use this feature to modify the charset that the browser uses and modify the interpretation of the contents of the response. This can enable Cross-site Scripting attacks that would otherwise not have succeeded while using UTF-8 encoding.


Example:

+ADw-script+AD4-alert(document.location)+ADw-/script+AD4

The previous string means nothing in most encoding types, and therefore is "safe", but when a victim views this under utf-7 encoding, it is interpreted as valid HTML tag and, the script is executed.

Transmitting account information over an unencrypted channel, hardcoding credential information inside the application code, unencrypted storage of account details in insufficiently protected backup files are some of the potential causes that might enable an attacker to gain access to victim's private information. The attacker can use this information to gain access to sensitive resources or privileged functionality.

The account information can either be supplied directly by the user during the registration or login process, accessed from a database or similar data store by the application or indirectly provided by a partner or other third party. Privacy violation occurs when this data is insecurely written to a console, file system, or a network location.

Unsafe logging of account information is also risky. Security and privacy concerns often seem to compete with each other. From a security perspective, you must record all important operations so that any anomalous activity can be later identified. However, when private data is involved, this practice can in fact create risk.

In addition to the risk of this information being prone to unauthorized access, developers must also take into account potential for misconduct by individuals who do have access to the data.

Directory listing vulnerabilities leak a complete index of all of the resources located in that directory. These vulnerabilities can result in exposure of files that should remain hidden, such as data files, backed-up source code, or applications in development. Unrestricted access to files containing sensitive information can aid further attacks against the application.
Directory listing vulnerabilities can be caused by:
1. Poor default configuration

In the absence of a default directory file, server configuration enables directory listing by default. In addition, the following configuration and setup examples might reveal directory contents to attackers:
Example 1: In many default configurations, certain modules installed on the server (e.g. mod_autoindex module for Apache HTTP Server) can enable directory listing to be obtained from the server even if index files exist and server directory listings configuration is disabled.
Example 2: Enabling services like WEBDAV on IIS server might also lead to exposure of directory contents. With the PROPFIND method, it might be possible to browse and list the contents of directories, even if a default directory file (such as "default.htm") exists.
Example 3: In its default configuration, Netscape Enterprise Server has a feature called "Directory Indexing" turned on. When directory listing is enabled, the server returns directory listings to web users.
2. Input Validation
Failure to validate user supplied data can cause directory listing vulnerabilities in servers and applications. Attackers can manipulate filenames and paths in the request URI to gain access to directory contents.
Example 4: JRun: A remote attacker can send a URL request appended with '%3f.jsp' to the server and gain access to the web root directory.
Example 5: BadBlue Webserver: Sending a request with % appended to the path causes the server to disclose the directory contents.
Example 6: Tomcat: Allows attackers to obtain complete directory listings by making a request containing a null byte.
Example 7: WebSTAR: The default installation contains a sample script that attackers can use to gain a directory listing of any directory on the server. Passing an asterisk (*) in the query string and appending it to the target directory path causes the script to disclose directory contents.
3. Encoding
Failure to properly handle requests containing encoded special characters can result in directory listing vulnerabilities
Example 8: Attackers can view the contents of web directories by requesting certain encoded characters. By appending certain characters to a request for a directory, an attacker can "break" the mechanism a server uses to determine whether a request is for a directory or not and thus give a full directory listing.
Example 9: Appending an encoded null-byte to the directory name can reveal directory contents.
4. Traversal vulnerabilities
Failure to validate paths to requested directories can allow attackers to gain access to arbitrary directory contents through traversal attacks.
Example: /../examples//WEB-INF/../../../../
5. Access Control error
Exposure of sample or test scripts or administrative interfaces can allow attackers to browse contents of arbitrary directories.

It is not uncommon for Java programmers to misunderstand read() and related methods that are part of many java.io classes. Most errors and unusual events in Java result in an exception being thrown. (This is one of the advantages that Java has over languages like C: Exceptions make it easier for programmers to think about what can go wrong.) But the stream and reader classes do not consider it unusual or exceptional if only a small amount of data becomes available. These classes simply add the small amount of data to the return buffer, and set the return value to the number of bytes or characters read. There is no guarantee that the amount of data returned is equal to the amount of data requested.

This behavior makes it important for programmers to examine the return value from read() and other IO methods to ensure that they receive the amount of data they expect.

Example: The following code loops through a set of users, reading a private data file for each user. The programmer assumes that the files are always exactly 1 kilobyte in size and therefore ignores the return value from read(). If an attacker can create a smaller file, the program will recycle the remainder of the data from the previous user and handle it as though it belongs to the attacker.

FileInputStream fis;
byte[] byteArray = new byte[1024];
for (Iterator i=users.iterator(); i.hasNext();) {
    String userName = (String) i.next();
    String pFileName = PFILE_ROOT + "/" + userName;
    FileInputStream fis = new FileInputStream(pFileName);
    fis.read(byteArray); // the file is always 1k bytes
    fis.close();
    processPFile(userName, byteArray);
}

Weak Cryptographic Hash: User-Controlled Algorithm issues occur when:

1. Data enters a program through an untrusted source

2. The user-controlled data is used to specify the cryptographic hash algorithm.

As with many software security vulnerabilities, Weak Cryptographic Hash: User-Controlled Algorithm is a means to an end, not an end in and of itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to an application, and the data is then used to specify the cryptographic hash algorithm. An attacker could specify a hash algorithm such as MD5, which has known weaknesses, to undermine the data integrity and security of the application.

Example 1: The following code uses a user-controlled algorithm:

    ...
    Properties prop = new Properties();
    prop.load(new FileInputStream("config.properties"));
    String algorithm = prop.getProperty("hash");
    ...
    MessageDigest messageDigest = MessageDigest.getInstance(algorithm);
    messageDigest.update(hashInput.getBytes("UTF-8"));
    ...

The code in Example 1 will run successfully, but anyone who can get to this functionality will be able to manipulate the hash algorithm by modifying the property hash. After the program ships, it can be nontrivial to undo an issue regarding user-controlled algorithms, as it is extremely difficult to know if a malicious user determined the algorithm parameter of a specific cryptographic hash.

Unencrypted communication channels are prone to eavesdropping and tampering.

By default, ElastiCache replication group transport encryption is disabled. This exposes the data to unauthorized access, potential theft, and tampering.

Example 1: The following example template defines an ElastiCache replication group without transport encryption enabled.

{
    "Resources": {
        "ReplicationGroup": {
            "Properties": {
            "Engine": "redis",
            "EngineVersion": "EngineVersion",
            "ReplicasPerNodeGroup": "NumReplicas",
            "PreferredMaintenanceWindow": "sat:07:00-sat:08:00",
            "AtRestEncryptionEnabled": true,
            "CacheParameterGroupName": "CacheParameterGroup",
            "SecurityGroupIds": [
                "SecurityGroup"
            ],
            "SnapshotRetentionLimit": "SnapshotRetentionLimit",
            "CacheNodeType": "CacheNodeType",
            "CacheSubnetGroupName": "CacheSubnetGroupName",
            "NumNodeGroups": "NumShards",
            "SnapshotWindow": "00:00-03:00",
            "ReplicationGroupDescription": "AWS::StackName"
            },
            "UpdatePolicy": {
            "UseOnlineResharding": true
            },
            "DeletionPolicy": "Snapshot",
            "UpdateReplacePolicy": "Snapshot",
            "Type": "AWS::ElastiCache::ReplicationGroup"
        }
    }
}

By default, Amazon Redshift clusters do not require transport encryption. This exposes the data to unauthorized access, tampering, and potential theft.

Example 1: The following example template defines an Amazon Redshift cluster that does not enforce transport security.

{
    "Resources": {
        "RedShiftParms": {
            "Type": "AWS::Redshift::clusterParameterGroup",
            "Properties": {
                "Description": "parameter group",
                "ParameterGroupFamily": "redshift-1.0",
                "Parameters": [
                    {
                        "ParameterName": "require_ssl",
                        "ParameterValue": "false"
                    }
                ]
            }
        }
    }
}

The Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols provide a protection mechanism to ensure the authenticity, confidentiality, and integrity of data transmitted between a client and web server. Both TLS and SSL have undergone revisions that result in periodic version updates. Each new revision addresses security weaknesses discovered in the previous version. Use of an insecure version of TLS/SSL weakens the strength of the data protection and might allow an attacker to compromise, steal, or modify sensitive information.

Insecure versions of TLS/SSL might exhibit one or more of the following properties:

- No protection against man-in-the-middle attacks
- Same key used for authentication and encryption
- Weak message authentication control
- No protection against TCP connection closing

The presence of these properties might enable an attacker to intercept, modify, or tamper with sensitive data.

Format string vulnerabilities occur when:

1. Data enters the application from an untrusted source.



2. The data is passed as the format string argument to a function like sprintf(), FormatMessageW(), or syslog().
Example 1: The following code copies a command line argument into a buffer using snprintf().

int main(int argc, char **argv){
	char buf[128];
	...
	snprintf(buf,128,argv[1]);
}

This code allows an attacker to view the contents of the stack and write to the stack using a command line argument containing a sequence of formatting directives. The attacker may read from the stack by providing more formatting directives, such as %x, than the function takes as arguments to be formatted. (In this example, the function takes no arguments to be formatted.) By using the %n formatting directive, the attacker may write to the stack, causing snprintf() to write the number of bytes output thus far to the specified argument (rather than reading a value from the argument, which is the intended behavior). A sophisticated version of this attack will use four staggered writes to completely control the value of a pointer on the stack.

Example 2: Certain implementations make more advanced attacks even easier by providing format directives that control the location in memory to read from or write to. An example of these directives is shown in the following code, written for glibc:

	printf("%d %d %1$d %1$d\n", 5, 9);

This code produces the following output:

5 9 5 5

It is also possible to use half-writes (%hn) to accurately control arbitrary DWORDS in memory, which greatly reduces the complexity needed to execute an attack that would otherwise require four staggered writes, such as the one mentioned in Example 1.

Example 3: Simple format string vulnerabilities often result from seemingly innocuous shortcuts. The use of some such shortcuts is so ingrained that programmers might not even realize that the function they are using expects a format string argument.

For example, the syslog() function is sometimes used as follows:

	...
	syslog(LOG_ERR, cmdBuf);
	...

Because the second parameter to syslog() is a format string, any formatting directives included in cmdBuf are interpreted as described in Example 1.

The following code shows a correct usage of syslog():

	...
	syslog(LOG_ERR, "%s", cmdBuf);
	...

By default, Amazon Redshift clusters are not encrypted. This exposes the data to unauthorized access and potential theft.

Example 1: The following template defines a Redshift cluster with no encryption enabled.

"Resources": {
    "RedshiftClusterTest": {
        "Type": "AWS::Redshift::Cluster",
        "Properties": {
            "DBName": "mydb",
            "MasterUsername": "master",
            "MasterUserPassword": "masterPass",
            "NodeType": "ds2.xlarge",
            "ClusterType": "single-node",
        }
    }

Unencrypted communication channels are prone to eavesdropping and tampering.

Serving web applications over HTTP allows attackers to perform man-in-the-middle attacks, giving them access to read or modify the data in transit over the channel.

Example 1: The following example shows an Ansible task that defines an Azure App Service that does not enforce HTTPS communication.

- name: app service
  azure_rm_webapp:
    resource_group: testGroup
    name: testApp
    https_only: false
    ...

By default, Ansible tasks do not enable Azure MySQL Database transport encryption (as per Azure.Azcollection v1.11.0 and earlier).

Unencrypted communication channels are prone to eavesdropping and tampering.

Disabling transport security exposes the data to unauthorized access, potential theft, and tampering.

Example 1: The following example Ansible task defines an Azure MySQL Database with transport encryption disabled.

- name: Create MySQL Server
azure.azcollection.azure_rm_mysqlserver:
    resource_group: testGroup
    name: testMySQL
    sku:
    name: B_Gen5_1
    tier: Basic
    location: westeurope
    storage_mb: 8096
    version: 5.6
    enforce_ssl: false
    admin_username: test
    admin_password: complicatedPass

By default, Ansible tasks do not enable Azure Database for PostgreSQL transport encryption (as per Azure.Azcollection v1.11.0 and earlier).

Unencrypted communication channels are prone to eavesdropping and tampering.

Disabling transport security exposes the data to unauthorized access, potential theft, and tampering.

Example 1: The following example Ansible task defines an Azure Database for PostgreSQL with transport encryption disabled.

- name: Create Postgres Server
  azure.azcollection.azure_rm_postgresqlserver:
    resource_group: testGroup
    name: testPostgres
    sku:
      name: B_Gen5_1
      tier: Basic
    location: westeurope
    storage_mb: 8096
    version: 5.6
    enforce_ssl: false
    admin_username: test
    admin_password: complicatedPass

Unencrypted communication channels are prone to eavesdropping and tampering.

By default, the https_only setting is set to yes enforcing secure transfer for an Azure storage account. However, this setting can be explicitly disabled.

Disabling secure transfer exposes the stored data to unauthorized access, potential theft, and tampering.

Example 1: The following Ansible task shows a storage account that does not enforce secure transfer.

- name: create a storage account
  azure_rm_storageaccount:
    resource_group: testResGroup
    name: sa0001
    type: Standard_GRS
    https_only: no

Buffer overflow is probably the best known form of software security vulnerability. Most software developers know what a buffer overflow vulnerability is, but buffer overflow attacks against both legacy and newly-developed applications are still quite common. Part of the problem is due to the wide variety of ways buffer overflows can occur, and part is due to the error-prone techniques often used to prevent them.

In a classic buffer overflow exploit, the attacker sends data to a program, which it stores in an undersized stack buffer. The result is that information on the call stack is overwritten, including the function's return pointer. The data sets the value of the return pointer so that when the function returns, it transfers control to malicious code contained in the attacker's data.

Although this type of stack buffer overflow is still common on some platforms and in some development communities, there are a variety of other types of buffer overflow, including heap buffer overflows and off-by-one errors among others. There are a number of excellent books that provide detailed information on how buffer overflow attacks work, including Building Secure Software [1], Writing Secure Code [2], and The Shellcoder's Handbook [3].

At the code level, buffer overflow vulnerabilities usually involve the violation of a programmer's assumptions. Many memory manipulation functions in C and C++ do not perform bounds checking and can easily exceed the allocated bounds of the buffers they operate upon. Even bounded functions, such as strncpy(), can cause vulnerabilities when used incorrectly. The combination of memory manipulation and mistaken assumptions about the size or makeup of a piece of data is the root cause of most buffer overflows.

Example: The following code attempts to prevent an off-by-one buffer overflow by checking that the untrusted value read from getInputLength() is less than the size of the destination buffer output. However, because the comparison between len and MAX is signed, if len is negative, it will be become a very large positive number when it is converted to an unsigned argument to memcpy().

void TypeConvert() {
   char input[MAX];
   char output[MAX];

   fillBuffer(input);
   int len = getInputLength();

   if (len <= MAX) {
      memcpy(output, input, len);
   }
   ...
}

Unauthorized include vulnerabilities occur when:

1. Data enters a web application through an untrusted source, most frequently a web request.

2. The data is part of the string specifying the template attribute of a <cfinclude> tag.
Example: The following code uses input from a web form to construct the path to a special file used to format the user's homepage. The programmer has not considered the possibility that an attacker may provide a malicious filename, such as "../../users/wileyh/malicious", which will cause the application to include and execute the contents of a file in the attacker's home directory.

<cfinclude template =  
              "C:\\custom\\templates\\#Form.username#.cfm">

If an attacker is allowed to specify the file included by the <cfinclude> tag, they may be able to cause the application to include the contents of nearly any file in the server's file system in the current page. This ability can be leveraged in at least two significant ways. If an attacker can write to a location on the server's file system, such as the user's home directory or a common upload directory, then they may be able to cause the application to include a maliciously crafted file in the page, which will be executed by the server. Even without write access to the server's file system, an attacker may often gain access to sensitive or private information by specifying the path of a file on the server.

Buffer overflow is probably the best known form of software security vulnerability. Most software developers know what a buffer overflow vulnerability is, but buffer overflow attacks against both legacy and newly-developed applications are still quite common. Part of the problem is due to the wide variety of ways buffer overflows can occur, and part is due to the error-prone techniques often used to prevent them.

In a classic buffer overflow exploit, the attacker sends data to a program, which it stores in an undersized stack buffer. The result is that information on the call stack is overwritten, including the function's return pointer. The data sets the value of the return pointer so that when the function returns, it transfers control to malicious code contained in the attacker's data.

Although this type of stack buffer overflow is still common on some platforms and in some development communities, there are a variety of other types of buffer overflow, including heap buffer overflows and off-by-one errors among others. There are a number of excellent books that provide detailed information on how buffer overflow attacks work, including Building Secure Software [1], Writing Secure Code [2], and The Shellcoder's Handbook [3].

At the code level, buffer overflow vulnerabilities usually involve the violation of a programmer's assumptions. Many memory manipulation functions in C and C++ do not perform bounds checking and can easily exceed the allocated bounds of the buffers they operate upon. Even bounded functions, such as strncpy(), can cause vulnerabilities when used incorrectly. The combination of memory manipulation and mistaken assumptions about the size or makeup of a piece of data is the root cause of most buffer overflows.

In this case, an improperly constructed format string causes the program to access values outside the bounds of allocated memory.

Example: The following reads arbitrary values from the stack because the number of format specifiers does not align with the number of arguments passed to the function.

void wrongNumberArgs(char *s, float f, int d) {
   char buf[1024];
   sprintf(buf, "Wrong number of %.512s");
}

Buffer overflow is probably the best known form of software security vulnerability. Most software developers know what a buffer overflow vulnerability is, but buffer overflow attacks against both legacy and newly-developed applications are still quite common. Part of the problem is due to the wide variety of ways buffer overflows can occur, and part is due to the error-prone techniques often used to prevent them.

In a classic buffer overflow exploit, the attacker sends data to a program, which it stores in an undersized stack buffer. The result is that information on the call stack is overwritten, including the function's return pointer. The data sets the value of the return pointer so that when the function returns, it transfers control to malicious code contained in the attacker's data.

Although this type of stack buffer overflow is still common on some platforms and in some development communities, there are a variety of other types of buffer overflow, including heap buffer overflows and off-by-one errors among others. There are a number of excellent books that provide detailed information on how buffer overflow attacks work, including Building Secure Software [1], Writing Secure Code [2], and The Shellcoder's Handbook [3].

At the code level, buffer overflow vulnerabilities usually involve the violation of a programmer's assumptions. Many memory manipulation functions in C and C++ do not perform bounds checking and can easily exceed the allocated bounds of the buffers they operate upon. Even bounded functions, such as strncpy(), can cause vulnerabilities when used incorrectly. The combination of memory manipulation and mistaken assumptions about the size or makeup of a piece of data is the root cause of most buffer overflows.

In this case, an improperly constructed format string causes the program to improperly convert data values or to access values outside the bounds of allocated memory.

Example: The following code incorrectly converts f from a float using a %d format specifier.

void ArgTypeMismatch(float f, int d, char *s, wchar *ws) {
   char buf[1024];
   sprintf(buf, "Wrong type of %d", f);
   ...
}

Struts 2 introduced a feature called "Dynamic Method Invocation" which allows an Action to expose methods other than execute(). The ! (bang) character or the method: prefix can be used in the Action URL to invoke any public method in the Action if "Dynamic Method Invocation" is enabled. In Struts 2 version 2.3.20 the mechanism to invoke the alternative method that was previously based on reflection, was substituted to use OGNL instead which allowed attackers to provide malicious OGNL expressions instead of an alternative method name.

Struts 2 has a setting called devMode (development mode). When this setting is enabled, Struts 2 will provide additional logging and debug information, which can significantly speed up development at the cost of a high impact in performance and security. devMode will raise the level of debug or normally ignorable problems to exceptions that would not normally be thrown in normal mode.

devMode also enable some debugging capabilities that allow developers to check variables stored in the Value Stack. These features can be triggered using the debug request parameter:
- debug=console will pop up an OGNL evaluation console allowing developers to evaluate any arbitrary OGNL expression on the server.
- debug=command will allow the developers to submit arbitrary OGNL expressions to be evaluated using the request parameter expression.
- debug=xml will dump the parameters, context, session, and value stack as an XML document.
- debug=browser will dump the parameters, context, session, and value stack in a browseable HTML document.