By default, Azure Blob Storage containers prevent anonymous access to their Blobs.

Insufficient access configurations expose systems and broaden an organization's attack surface. Resources open to public access might unintentionally leak sensitive data.

Example 1: The following example template defines an Azure Blob Storage container with the publicAccess property set to Container. This allows anonymous access to all of the Container's blobs and data.

{
    "type": "Microsoft.Storage/storageAccounts/blobServices/containers",
    "apiVersion": "2021-04-01",
    "name": "[format('{0}/default/{1}', parameters('storageAccountName'), parameters('containerName'))]",
    "properties":{
        "publicAccess": "Container"
    }
    ,
    "dependsOn": [
        "[resourceId('Microsoft.Storage/storageAccounts', parameters('storageAccountName'))]"
    ]
}

XML External Entities attacks benefit from an XML feature to build documents dynamically at the time of processing. An XML entity allows to include data dynamically from a given resource. External entities allow an XML document to include data from an external URI. Unless configured to do otherwise, external entities force the XML parser to access the resource specified by the URI, e.g., a file on the local machine or on a remote systems. This behavior exposes the application to XML External Entity (XXE) attacks, which can be used to perform denial of service of the local system, gain unauthorized access to files on the local machine, scan remote machines, and perform denial of service of remote systems.

The following XML document shows an example of an XXE attack.

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///c:/winnt/win.ini" >]><foo>&xxe;</foo>

This example could disclose the contents of the C:\winnt\win.ini system file, if the XML parser attempts to substitute the entity with the contents of the file.

XML External Entity (XXE) injection occurs when:

1. Data enters a program from an untrusted source.

2. The data is written to an <ENTITY> element of the DTD (Document Type Definition) in an XML document.

Applications typically use XML to store data or send messages. When used to store data, XML documents are often treated like databases and can potentially contain sensitive information. XML messages are often used in web services and can also be used to transmit sensitive information. XML messages can even be used to send authentication credentials.

The semantics of XML documents and messages can be altered if an attacker has the ability to write raw XML. In the most benign case, an attacker may be able to insert nested entity references and cause an XML parser consume ever increasing amounts of CPU resources. In more nefarious cases of XML external entity injection, an attacker may be able to add XML elements that expose the contents of local file system resources or reveal the existence of internal network resources.

Example 1:Here is some Objective-C code that is vulnerable to XXE attacks:

- (void) parseSomeXML: (NSString *) rawXml {

    BOOL success;
    NSData *rawXmlConvToData = [rawXml dataUsingEncoding:NSUTF8StringEncoding];
    NSXMLParser *myParser = [[NSXMLParser alloc] initWithData:rawXmlConvToData];
    [myParser setShouldResolveExternalEntities:YES];
    [myParser setDelegate:self];
}

Assume an attacker is able to control rawXml such that the XML looks like the following:

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

When the XML is evaluated by the server, the <foo> element will contain the contents of the boot.ini file.

XML External Entity attacks benefit from an XML feature to dynamically build documents at runtime. An XML entity allows inclusion of data dynamically from a given resource. External entities allow an XML document to include data from an external URI. Unless configured to do otherwise, external entities force the XML parser to access the resource specified by the URI, such as a file on the local machine or on a remote system. This behavior exposes the application to XML External Entity (XXE) attacks, which enables attackers to perform denial of service of the local system, gain unauthorized access to files on the local machine, scan remote machines, and perform denial of service of remote systems.


Example 1: The following XML document shows an example of an XXE attack.

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>

This example could crash the server (on a UNIX system) if the XML parser attempts to substitute the entity with the contents of the /dev/random file.

XML External Entity (XXE) injection occurs when:

1. Data enters a program from an untrusted source.

2. The data is written to an <ENTITY> element of the DTD (Document Type Definition) in an XML document.

Applications typically use XML to store data or send messages. When used to store data, XML documents are often treated like databases and can potentially contain sensitive information. XML messages are often used in web services and can also be used to transmit sensitive information. XML messages can even be used to send authentication credentials.

The semantics of XML documents and messages can be altered if an attacker has the ability to write raw XML. In the most benign case, an attacker may be able to insert nested entity references and cause an XML parser consume ever increasing amounts of CPU resources. In more nefarious cases of XML external entity injection, an attacker may be able to add XML elements that expose the contents of local file system resources or reveal the existence of internal network resources.

Example 1:Here is some code that is vulnerable to XXE attacks:

- (void) parseSomeXML: (NSString *) rawXml {

    BOOL success;
    NSData *rawXmlConvToData = [rawXml dataUsingEncoding:NSUTF8StringEncoding];
    NSXMLParser *myParser = [[NSXMLParser alloc] initWithData:rawXmlConvToData];
    [myParser setShouldResolveExternalEntities:YES];
    [myParser setDelegate:self];
}

Assume an attacker is able to control rawXml such that the XML looks like the following:

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

When the XML is evaluated by the server, the <foo> element will contain the contents of the boot.ini file.

XML External Entity (XXE) injection occurs when:

1. Data enters a program from an untrusted source.

2. The data is written to an XML document.

Applications typically use XML to store data or send messages. When used to store data, XML documents are often treated like databases and can potentially contain sensitive information. XML messages are often used in web services and can also be used to transmit sensitive information. XML messages can even be used to send authentication credentials.

The semantics of XML documents and messages can be altered if an attacker has the ability to write raw XML. In the most benign case, an attacker may be able to insert nested entity references and cause an XML parser to consume ever increasing amounts of CPU resources. In more nefarious cases of XML external entity injection, an attacker may be able to add XML elements that expose the contents of local file system resources, reveal the existence of internal network resources or expose backend content itself.

Example 1: Here is some code that is vulnerable to XXE attacks:

Assume an attacker is able to control the input XML to the following code:

...
<?php
$goodXML = $_GET["key"];
$doc = simplexml_load_string($goodXml);
echo $doc->testing;
?>
...

Now suppose that the following XML is passed by the attacker to the code in Example 2:

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

When the XML is processed, the content of the <foo> element is populated with the contents of the system's boot.ini file. The attacker may utilize XML elements which are returned to the client to exfiltrate data or obtain information as to the existence of network resources.

XML External Entities attacks benefit from an XML feature to dynamically build documents at runtime. An XML entity allows inclusion of data dynamically from a given resource. External entities allow an XML document to include data from an external URI. Unless configured to do otherwise, external entities force the XML parser to access the resource specified by the URI, such as a file on the local machine or on a remote system. This behavior exposes the application to XML External Entity (XXE) attacks, which attackers can use to perform denial of service of the local system, gain unauthorized access to files on the local machine, scan remote machines, and perform denial of service of remote systems.


Example 1: The following XML document shows an example of an XXE attack.

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///dev/random" >]><foo>&xxe;</foo>

This example could crash the server (on a UNIX system), if the XML parser attempts to substitute the entity with the contents of the /dev/random file.

XML External Entities attacks benefit from an XML feature to build documents dynamically at the time of processing. An XML entity allows inclusion of data dynamically from a given resource. External entities allow an XML document to include data from an external URI. Unless configured to do otherwise, external entities force the XML parser to access the resource specified by the URI, e.g., a file on the local machine or on a remote system. This behavior exposes the application to XML External Entity (XXE) attacks, which can be used to perform denial of service of the local system, gain unauthorized access to files on the local machine, scan remote machines, and perform denial of service of remote systems.

The following XML document shows an example of an XXE attack.

<?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
  <!ELEMENT foo ANY >
  <!ENTITY xxe SYSTEM "file:///etc/passwd" >]><foo>&xxe;</foo>

The example XML document will read the contents of /etc/passwd and include them into the document.

Example 1: The following code uses an insecure XML parser to process untrusted input from an HTTP request.

def readFile() = Action { request =>
    val xml = request.cookies.get("doc")
    val doc = XMLLoader.loadString(xml)
    ...
}

XML External Entity (XXE) injection occurs when:

1. Data enters a program from an untrusted source.

2. The data is written to an <ENTITY> element of the DTD (Document Type Definition) in an XML document.

Applications typically use XML to store data or send messages. When used to store data, XML documents are often treated like databases and can potentially contain sensitive information. XML messages are often used in web services and can also be used to transmit sensitive information. XML messages can even be used to send authentication credentials.

The semantics of XML documents and messages can be altered if an attacker has the ability to write raw XML. In the most benign case, an attacker may be able to insert nested entity references and cause an XML parser consume ever increasing amounts of CPU resources. In more nefarious cases of XML external entity injection, an attacker may be able to add XML elements that expose the contents of local file system resources or reveal the existence of internal network resources.

Example 1:Here is some code that is vulnerable to XXE attacks:

func parseXML(xml: String) {
    parser = NSXMLParser(data: rawXml.dataUsingEncoding(NSUTF8StringEncoding)!)
    parser.delegate = self
    parser.shouldResolveExternalEntities = true
    parser.parse()
}

Assume an attacker is able to control rawXml contents such that the XML looks like the following:

 <?xml version="1.0" encoding="ISO-8859-1"?>
 <!DOCTYPE foo [
   <!ELEMENT foo ANY >
   <!ENTITY xxe SYSTEM "file:///c:/boot.ini" >]><foo>&xxe;</foo>

When the XML is evaluated by the server, the <foo> element will contain the contents of the boot.ini file.

A publicly accessible Kubernetes API server can expose the organization to attack.

Example 1: The following example shows a template that defines a Kubernetes service cluster that does not restrict the range of IP addresses that are allowed to connect to the API server.

{
    "name": "TestCluster",
    "type": "Microsoft.ContainerService/managedClusters",
    "apiVersion": "2020-02-01",
    "location": "[resourceGroup().location]",
    "properties": {
    ...
    "servicePrincipalProfile": {
        "clientId": "422313d8-123a-41ea-8f8e-90821ff61c05",
        "secret": "xxxxxxxxxxxxxxxxx"
    },
    }
}

Debugging interfaces provide attackers with information that they can leverage for a more targeted attack.

Example 1: The following example template defines an Azure App Service with remote debugging enabled.

{
    ...
    "type": "Microsoft.Web/sites/config",
    "properties":
    {
        ...
        "remoteDebuggingEnabled": true,
    }
}

Relaxed access configurations expose systems and broaden an organization's attack surface. Services open to interaction with the internet are subjected to almost continuous scanning and probing by malicious entities.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published (e.g Heartbleed). Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Example 1: The following example template defines an Azure Cosmos DB with unrestricted network access. The publicNetworkAccess property is set to Enabled and the IP address range includes all IPs.

{
    "type": "Microsoft.DocumentDB/databaseAccounts",
    "apiVersion": "2021-04-15",
    ...
    "properties": {
        ...
        "publicNetworkAccess": "Enabled",
        "ipRules":[{
                "ipAddressOrRange":  "0.0.0.0"
            }]
    ...
}

Overly broad configurations expose systems and broaden an organization's attack surface. Services open to interaction with the public are subjected to almost continuous scanning and probing by attackers.

This is especially problematic when a zero-day exploit for an exposed service is discovered and published (e.g. Heartbleed). Attackers can actively pursue and search for unpatched and exposed systems to exploit.

Example 1: The following example template allows unrestricted inbound traffic to a range of ports, including the RDP service port (3389).

{
    ...
    "name": "sample/securitygroup",
    "type": "Microsoft.Network/networkSecurityGroups/securityRules",
    "apiVersion": "2020-11-01",
    "properties": {
        "description": "Services Inbound Range",
        "protocol": "Tcp",
        "sourcePortRange": "*",
        "destinationPortRanges": [
            "3333-3389"
        ],
        "sourceAddressPrefix": "*",
        "destinationAddressPrefix": "*",
        "access": "Allow",
        "priority": 100,
        "direction": "Inbound"
    ...
}

By default, Azure Kubernetes Service (AKS) clusters do not send log events to Azure Monitor. This can allow malicious behavior to go undetected and prevent forensic analysis in the event of a breach.

Example 1: The following example template shows an AKS cluster that does not send log events to Azure Monitor.

{
    "name": "[split(parameters('aksResourceId'),'/')[8]]",
    "type": "Microsoft.ContainerService/managedClusters",
    "apiVersion": "2018-03-31",
    "properties": {
        "mode": "Incremental",
        "id": "[parameters('aksResourceId')]",
    }
}

A lack of audit records limits the ability to detect and respond to security related incidents and prevents forensic investigation.

Example 1: The following example template defines an Azure Monitor log profile that does not collect all Activity Log administrative events.

{
    "name": "string",
    "type": "microsoft.insights/logprofiles",
    "apiVersion": "2016-03-01",
    ...
    "properties": {
        ...
        "categories": [
            "Write"
        ],
        ...
    }
}

Unmonitored systems provide attackers with a way to probe and potentially penetrate defenses without detection.

If security personnel are not alerted in a timely fashion to security-related events, they cannot respond to incidents in time to reduce the impact of an attack or breach.

Example 1: The following example template successfully defines a security contact but explicitly disables the delivery of security alert email notifications to that contact.

{
    "name": "Security Officer",
    "type": "Microsoft.Security/securityContacts",
    "apiVersion": "2020-01-01-preview",
    "properties": {
        "emails": "secofficer@example.com",
        "phone": "1212131314",
        "alertNotifications": {
        "state": "Off",
        "minimalSeverity": "High"
        },
        ...
}

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    var storedPassword:String = null;
    var temp:String;

    if ((temp = readPassword()) != null) {
        storedPassword = temp;
    }

    if(Utils.verifyPassword(userPassword, storedPassword))
        // Access protected resources
        ...
    }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for userPassword.

Assigning null to password variables is never a good idea as it might enable attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    string storedPassword = null;
    string temp;

    if ((temp = ReadPassword(storedPassword)) != null) {
        storedPassword = temp;
    }

    if (Utils.VerifyPassword(storedPassword, userPassword)) {
        // Access protected resources
        ...
    }
    ...

If ReadPassword() fails to retrieve the stored password due to a database error or other problem, then an attacker can easily bypass the password check by providing a null value for userPassword.

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    string storedPassword = null;
    string temp;

    if ((temp = ReadPassword(storedPassword)) != null) {
        storedPassword = temp;
    }

    if(Utils.VerifyPassword(storedPassword, userPassword))
        // Access protected resources
        ...
    }
    ...

If ReadPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for userPassword.

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    char *stored_password = NULL;

    readPassword(stored_password);

    if(safe_strcmp(stored_password, user_password))
        // Access protected resources
        ...
    }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for user_password.

Assigning null to password variables is never a good idea as it might enable attackers to bypass password verification or it might indicate that resources are protected by an empty password.

It is not a good idea to have a null password.

Example: The following code sets the password initially to null:

    ...
    var password=null;
    ...
    {
        password=getPassword(user_data);
        ...
    }
    ...
    if(password==null){
        // Assumption that the get didn't work
        ...
        }
    ...

Never assign null to password variables because it might enable attackers to bypass password verification or indicate that resources are not protected by a password.

Example: The following JSON initializes a null password.

{
  ...
  "password" : null
  ...
}

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    NSString *stored_password = NULL;

    readPassword(stored_password);

    if(safe_strcmp(stored_password, user_password)) {
        // Access protected resources
        ...
    }
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for user_password.

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

<?php
    ...
    $storedPassword = NULL;

    if (($temp = getPassword()) != NULL) {
      $storedPassword = $temp;
    }

    if(strcmp($storedPassword,$userPassword) == 0) {
        // Access protected resources
        ...
    }
    ...
?>

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for userPassword.

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example: The following code initializes a password variable to null.

DECLARE
    password VARCHAR(20);
BEGIN
    password := null;
END;

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

...
storedPassword = NULL;

temp = getPassword()
if (temp is not None) {
  storedPassword = temp;
}

if(storedPassword == userPassword) {
    // Access protected resources
    ...
}
...

If getPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for userPassword.

Assigning nil to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to nil, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    @storedPassword = nil
    temp = readPassword()
    storedPassword = temp unless temp.nil?
    unless Utils.passwordVerified?(@userPassword, @storedPassword)
      ...
    end
    ...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for @userPassword.

Due to the dynamic nature of Ruby, many functions also take an optional number of arguments, so the password may be set to nil as a default value when none is specified. In this case you also need to make sure that the correct number of arguments are specified in order to make sure a password is passed to the function.

Assigning null to password variables is a bad idea because it can allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

    ...
    ws.url(url).withAuth("john", null, WSAuthScheme.BASIC)
    ...

Assigning nil to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to null, attempts to read a stored value for the password, and compares it against a user-supplied value.

...
var stored_password = nil

readPassword(stored_password)

if(stored_password == user_password) {
// Access protected resources
...
}
...

If readPassword() fails to retrieve the stored password due to a database error or another problem, then an attacker could trivially bypass the password check by providing a null value for user_password.

Assigning null to password variables is never a good idea as it may allow attackers to bypass password verification or might indicate that resources are protected by an empty password.

Example 1: The following code initializes a password variable to null and uses it to connect to a database.

    ...
    Dim storedPassword As String
    Set storedPassword = vbNullString

    Dim con As New ADODB.Connection
    Dim cmd As New ADODB.Command
    Dim rst As New ADODB.Recordset

    con.ConnectionString = "Driver={Microsoft ODBC for Oracle};Server=OracleServer.world;Uid=scott;Passwd=" & storedPassword &";"
    ...

If the code in Example 1 succeeds, it indicates that the database user account "scott" is configured with an empty password, which an attacker can easily guess. After the program ships, updating the account to use a non-empty password will require a code change.

Header Manipulation vulnerabilities occur when:

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

2. The data is included in an HTTP response header sent to a web user without being validated.

As with many software security vulnerabilities, Header Manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header.

One of the most common Header Manipulation attacks is HTTP Response Splitting. To mount a successful HTTP Response Splitting exploit, the application must allow input that contains CR (carriage return, also given by %0d or \r) and LF (line feed, also given by %0a or \n)characters into the header. These characters not only give attackers control of the remaining headers and body of the response the application intends to send, but also allows them to create additional responses entirely under their control.

Many of today's modern application servers will prevent the injection of malicious characters into HTTP headers. If your application server prevents setting headers with new line characters, then your application is not vulnerable to HTTP Response Splitting. However, solely filtering for new line characters can leave an application vulnerable to Cookie Manipulation or Open Redirects, so care must still be taken when setting HTTP headers with user input.

Example: The following code segment reads the name of the author of a weblog entry, author, from an HTTP request and sets it in a cookie header of an HTTP response.

...
author = request->get_form_field( 'author' ).
response->set_cookie( name = 'author' value = author ).
...

Assuming a string consisting of standard alphanumeric characters, such as "Jane Smith", is submitted in the request the HTTP response including this cookie might take the following form:

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

However, because the value of the cookie is formed of unvalidated user input the response will only maintain this form if the value submitted for AUTHOR_PARAM does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", then the HTTP response would be split into two responses of the following form:

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

Clearly, the second response is completely controlled by the attacker and can be constructed with any header and body content desired. The ability of attacker to construct arbitrary HTTP responses permits a variety of resulting attacks, including: cross-user defacement, web and browser cache poisoning, cross-site scripting, and page hijacking.

Cross-User Defacement: An attacker will be able to make a single request to a vulnerable server that will cause the server to create two responses, the second of which may be misinterpreted as a response to a different request, possibly one made by another user sharing the same TCP connection with the server. This can be accomplished by convincing the user to submit the malicious request themselves, or remotely in situations where the attacker and the user share a common TCP connection to the server, such as a shared proxy server. In the best case, an attacker may leverage this ability to convince users that the application has been hacked, causing users to lose confidence in the security of the application. In the worst case, an attacker may provide specially crafted content designed to mimic the behavior of the application but redirect private information, such as account numbers and passwords, back to the attacker.

Cache Poisoning: The impact of a maliciously constructed response can be magnified if it is cached either by a web cache used by multiple users or even the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, then that user will continue to receive the malicious content until the cache entry is purged, although only the user of the local browser instance will be affected.

Cross-Site Scripting: Once attackers have control of the responses sent by an application, they have a choice of a variety of malicious content to provide users. Cross-site scripting is common form of attack where malicious JavaScript or other code included in a response is executed in the user's browser. 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. The most common and dangerous attack vector against users of a vulnerable application uses JavaScript to transmit session and authentication information back to the attacker who can then take complete control of the victim's account.

Page Hijacking: In addition to using a vulnerable application to send malicious content to a user, the same root vulnerability can also be leveraged to redirect sensitive content generated by the server and intended for the user to the attacker instead. By submitting a request that results in two responses, the intended response from the server and the response generated by the attacker, an attacker may cause an intermediate node, such as a shared proxy server, to misdirect a response generated by the server for the user to the attacker. Because the request made by the attacker generates two responses, the first is interpreted as a response to the attacker's request, while the second remains in limbo. When the user makes a legitimate request through the same TCP connection, the attacker's request is already waiting and is interpreted as a response to the victim's request. The attacker then sends a second request to the server, to which the proxy server responds with the server generated request intended for the victim, thereby compromising any sensitive information in the headers or body of the response intended for the victim.

Cookie Manipulation: When combined with attacks like Cross-Site Request Forgery, attackers may change, add to, or even overwrite a legitimate user's cookies.

Open Redirect: Allowing unvalidated input to control the URL used in a redirect can aid phishing attacks.

Header Manipulation vulnerabilities occur when:

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


2. The data is included in an HTTP response header sent to a web user without being validated.

As with many software security vulnerabilities, Header Manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header.

One of the most common Header Manipulation attacks is HTTP Response Splitting. To mount a successful HTTP Response Splitting exploit, the application must allow input that contains CR (carriage return, also given by %0d or \r) and LF (line feed, also given by %0a or \n) characters into the header. These characters not only give attackers control of the remaining headers and body of the response the application intends to send, but also allows them to create additional responses entirely under their control.

Many of today's modern application servers prevent the injection of malicious characters into HTTP headers. For example, recent versions of Apache Tomcat throw an IllegalArgumentException if you attempt to set a header with prohibited characters. If your application server prevents setting headers with new line characters, then your application is not vulnerable to HTTP Response Splitting. However, solely filtering for new line characters can leave an application vulnerable to Cookie Manipulation or Open Redirects, so care must still be taken when setting HTTP headers with user input.

Example 1: The following code sets an HTTP header whose name and value could be controlled by an attacker:

@HttpGet
global static void doGet() {
    ...
    Map<String, String> params = ApexPages.currentPage().getParameters();
    
    RestResponse res = RestContext.response;
    res.addHeader(params.get('name'), params.get('value'));
    ...
}

Assuming a name/value pair consisting of author and Jane Smith, the HTTP response including this header might take the following form:

HTTP/1.1 200 OK
...
author:Jane Smith
...

However, because the value of the header is formed from unvalidated user input, an attacker might submit a malicious name/value pair, such as HTTP/1.1 200 OK\r\n...foo and bar, then the HTTP response would be split into two responses of the following form:

HTTP/1.1 200 OK
...

HTTP/1.1 200 OK
...
foo:bar

Clearly, the second response is completely controlled by the attacker and can be constructed with any header and body content desired. The ability of attacker to construct arbitrary HTTP responses permits a variety of resulting attacks, including: cross-user defacement, web and browser cache poisoning, cross-site scripting, and page hijacking.

Cross-User Defacement: An attacker can make a single request to a vulnerable server that causes the server to create two responses, the second of which might be misinterpreted as a response to a different request, possibly one made by another user sharing the same TCP connection with the server. This can be accomplished by convincing the user to submit the malicious request themselves, or remotely in situations where the attacker and the user share a common TCP connection to the server, such as a shared proxy server. In the best case, an attacker might leverage this ability to convince users that the application has been hacked, causing users to lose confidence in the security of the application. In the worst case, an attacker might provide specially crafted content designed to mimic the behavior of the application but redirect private information, such as account numbers and passwords, back to the attacker.

Cache Poisoning: The impact of a maliciously constructed response can be magnified if it is cached either by a web cache used by multiple users or even the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, then that user will continue to receive the malicious content until the cache entry is purged, although only the user of the local browser instance will be affected.

Cross-Site Scripting: After attackers have control of the responses sent by an application, they have a choice of a variety of malicious content to provide users. Cross-site scripting is common form of attack where malicious JavaScript or other code included in a response is executed in the user's browser. 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. The most common and dangerous attack vector against users of a vulnerable application uses JavaScript to transmit session and authentication information back to the attacker who can then take complete control of the victim's account.

Page Hijacking: In addition to using a vulnerable application to send malicious content to a user, the same root vulnerability can also be leveraged to redirect sensitive content generated by the server and intended for the user to the attacker instead. By submitting a request that results in two responses, the intended response from the server and the response generated by the attacker, an attacker might cause an intermediate node, such as a shared proxy server, to misdirect a response generated by the server for the user to the attacker. Because the request made by the attacker generates two responses, the first is interpreted as a response to the attacker's request, while the second remains in limbo. When the user makes a legitimate request through the same TCP connection, the attacker's request is already waiting and is interpreted as a response to the victim's request. The attacker then sends a second request to the server, to which the proxy server responds with the server generated request intended for the victim, thereby compromising any sensitive information in the headers or body of the response intended for the victim.

Cookie Manipulation: When combined with attacks such as Cross-Site Request Forgery, attackers might change, add to, or even overwrite a legitimate user's cookies.

Open Redirect: Allowing unvalidated input to control the URL used in a redirect can aid phishing attacks.

Header Manipulation vulnerabilities occur when:

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

2. The data is included in an HTTP response header sent to a web user without being validated.

As with many software security vulnerabilities, Header Manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header.

One of the most common Header Manipulation attacks is HTTP Response Splitting. To mount a successful HTTP Response Splitting exploit, the application must allow input that contains CR (carriage return, also given by %0d or \r) and LF (line feed, also given by %0a or \n)characters into the header. These characters not only give attackers control of the remaining headers and body of the response the application intends to send, but also allows them to create additional responses entirely under their control.

Many of today's modern application servers and frameworks will prevent the injection of malicious characters into HTTP headers. For example, recent versions of Microsoft's .NET framework will convert CR, LF, and NULL characters to %0d, %0a and %00 when they are sent to the HttpResponse.AddHeader() method. If you are using the latest .NET framework that prevents setting headers with new line characters, then your application might not be vulnerable to HTTP Response Splitting. However, solely filtering for new line characters can leave an application vulnerable to Cookie Manipulation or Open Redirects, so care must still be taken when setting HTTP headers with user input.

Example: The following code segment reads the name of the author of a weblog entry, author, from an HTTP request and sets it in a cookie header of an HTTP response.

protected System.Web.UI.WebControls.TextBox Author;
...
string author = Author.Text;
Cookie cookie = new Cookie("author", author);
...

Assuming a string consisting of standard alphanumeric characters, such as "Jane Smith", is submitted in the request the HTTP response including this cookie might take the following form:

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

However, because the value of the cookie is formed of unvalidated user input the response will only maintain this form if the value submitted for Author.Text does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", then the HTTP response would be split into two responses of the following form:

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

Clearly, the second response is completely controlled by the attacker and can be constructed with any header and body content desired. The ability of attacker to construct arbitrary HTTP responses permits a variety of resulting attacks, including: cross-user defacement, web and browser cache poisoning, cross-site scripting, and page hijacking.

Cross-User Defacement: An attacker will be able to make a single request to a vulnerable server that will cause the server to create two responses, the second of which may be misinterpreted as a response to a different request, possibly one made by another user sharing the same TCP connection with the server. This can be accomplished by convincing the user to submit the malicious request themselves, or remotely in situations where the attacker and the user share a common TCP connection to the server, such as a shared proxy server. In the best case, an attacker may leverage this ability to convince users that the application has been hacked, causing users to lose confidence in the security of the application. In the worst case, an attacker may provide specially crafted content designed to mimic the behavior of the application but redirect private information, such as account numbers and passwords, back to the attacker.

Cache Poisoning: The impact of a maliciously constructed response can be magnified if it is cached either by a web cache used by multiple users or even the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, then that user will continue to receive the malicious content until the cache entry is purged, although only the user of the local browser instance will be affected.

Cross-Site Scripting: Once attackers have control of the responses sent by an application, they have a choice of a variety of malicious content to provide users. Cross-site scripting is common form of attack where malicious JavaScript or other code included in a response is executed in the user's browser. 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. The most common and dangerous attack vector against users of a vulnerable application uses JavaScript to transmit session and authentication information back to the attacker who can then take complete control of the victim's account.

Page Hijacking: In addition to using a vulnerable application to send malicious content to a user, the same root vulnerability can also be leveraged to redirect sensitive content generated by the server and intended for the user to the attacker instead. By submitting a request that results in two responses, the intended response from the server and the response generated by the attacker, an attacker may cause an intermediate node, such as a shared proxy server, to misdirect a response generated by the server for the user to the attacker. Because the request made by the attacker generates two responses, the first is interpreted as a response to the attacker's request, while the second remains in limbo. When the user makes a legitimate request through the same TCP connection, the attacker's request is already waiting and is interpreted as a response to the victim's request. The attacker then sends a second request to the server, to which the proxy server responds with the server generated request intended for the victim, thereby compromising any sensitive information in the headers or body of the response intended for the victim.

Cookie Manipulation: When combined with attacks like Cross-Site Request Forgery, attackers may change, add to, or even overwrite a legitimate user's cookies.

Open Redirect: Allowing unvalidated input to control the URL used in a redirect can aid phishing attacks.