It is never a good idea to use a null salt (NULL). Not only does a null salt contradicts its intended objective but all of the project's developers can view the salt. It makes fixing the problem extremely difficult because after the code is in production, the salt cannot be easily changed. If attackers know the value of the salt, they can compute "rainbow tables" for the application and easily determine the hashed values.

Example 1: The following code uses a null salt:

...
define('SECURE_AUTH_SALT', NULL);
...

This code runs successfully, but anyone who has access to it can see the salt. After the program ships, there is likely no way to change the null salt. An employee with access to this information can use it to break into the system.

Applications require temporary files so frequently that many different mechanisms exist for creating them in the C Library and Windows(R) API. Most of these functions are vulnerable to various forms of attacks.
Example 1: The following code uses a temporary file for storing intermediate data gathered from the network before it is processed.

...
if (tmpnam_r(filename)){
	FILE* tmp = fopen(filename,"wb+");
	while((recv(sock,recvbuf,DATA_SIZE, 0) > 0)&&(amt!=0))
		amt = fwrite(recvbuf,1,DATA_SIZE,tmp);
}
...

This otherwise unremarkable code is vulnerable to a number of different attacks because it relies on an insecure method for creating temporary files. The vulnerabilities introduced by this function and others are described in the following sections. The most egregious security problems related to temporary file creation have occurred on Unix-based operating systems, but Windows applications have parallel risks. This section includes a discussion of temporary file creation on both Unix and Windows systems.

Methods and behaviors can vary between systems, but the fundamental risks introduced by each are reasonably constant. See the Recommendations section for information about safe core language functions and advice regarding a secure approach to creating temporary files.

The functions designed to aid in the creation of temporary files can be broken into two groups based on whether they simply provide a filename or actually open a new file.

Group 1 - "Unique" Filenames:

The first group of C Library and WinAPI functions designed to help with the process of creating temporary files do so by generating a unique file name for a new temporary file, which the program is then supposed to open. This group includes C Library functions like tmpnam(), tempnam(), mktemp() and their C++ equivalents prefaced with an _ (underscore) as well as the GetTempFileName() function from the Windows API. This group of functions suffers from an underlying race condition on the filename chosen. Although the functions guarantee that the filename is unique at the time it is selected, there is no mechanism to prevent another process or an attacker from creating a file with the same name after it is selected but before the application attempts to open the file. Beyond the risk of a legitimate collision caused by another call to the same function, there is a high probability that an attacker will be able to create a malicious collision because the filenames generated by these functions are not sufficiently randomized to make them difficult to guess.

If a file with the selected name is created, then depending on how the file is opened the existing contents or access permissions of the file may remain intact. If the existing contents of the file are malicious in nature, an attacker may be able to inject dangerous data into the application when it reads data back from the temporary file. If an attacker pre-creates the file with relaxed access permissions, then data stored in the temporary file by the application may be accessed, modified or corrupted by an attacker. On Unix based systems an even more insidious attack is possible if the attacker pre-creates the file as a link to another important file. Then, if the application truncates or writes data to the file, it may unwittingly perform damaging operations for the attacker. This is an especially serious threat if the program operates with elevated permissions.

Finally, in the best case the file will be opened with a call to open() using the O_CREAT and O_EXCL flags or to CreateFile() using the CREATE_NEW attribute, which will fail if the file already exists and therefore prevent the types of attacks described previously. However, if an attacker is able to accurately predict a sequence of temporary file names, then the application may be prevented from opening necessary temporary storage causing a denial of service (DoS) attack. This type of attack would not be difficult to mount given the small amount of randomness used in the selection of the filenames generated by these functions.

Group 2 - "Unique" Files:

The second group of C Library functions attempts to resolve some of the security problems related to temporary files by not only generating a unique file name, but also opening the file. This group includes C Library functions like tmpfile() and its C++ equivalents prefaced with an _ (underscore), as well as the slightly better-behaved C Library function mkstemp().

The tmpfile() style functions construct a unique filename and open it in the same way that fopen() would if passed the flags "wb+", that is, as a binary file in read/write mode. If the file already exists, tmpfile() will truncate it to size zero, possibly in an attempt to assuage the security concerns mentioned earlier regarding the race condition that exists between the selection of a supposedly unique filename and the subsequent opening of the selected file. However, this behavior clearly does not solve the function's security problems. First, an attacker may pre-create the file with relaxed access-permissions that will likely be retained by the file opened by tmpfile(). Furthermore, on Unix based systems if the attacker pre-creates the file as a link to another important file, the application may use its possibly elevated permissions to truncate that file, thereby doing damage on behalf of the attacker. Finally, if tmpfile() does create a new file, the access permissions applied to that file will vary from one operating system to another, which can leave application data vulnerable even if an attacker is unable to predict the filename to be used in advance.

Finally, mkstemp() is a reasonably safe way to create temporary files. It will attempt to create and open a unique file based on a filename template provided by the user combined with a series of randomly generated characters. If it is unable to create such a file, it will fail and return -1. On modern systems the file is opened using mode 0600, which means the file will be secure from tampering unless the user explicitly changes its access permissions. However, mkstemp() still suffers from the use of predictable file names and can leave an application vulnerable to denial of service attacks if an attacker causes mkstemp() to fail by predicting and pre-creating the filenames to be used.

Attackers can target unauthenticated MongoDB servers to compromise the data stored in it and depending on the MongoDB version, to get a foothold on your internal network by compromising the server.

Different attacks can be used against a MongoDB server to get arbitrary code execution on its underlying operating system. For example, vulnerabilities existed in the past that allowed attackers to turn a server-side JavaScript injection into remote code execution. When used to store objects, an attacker can also store deserialization payloads for different languages such as Java, Python, Ruby, PHP, etc. in order to get remote code execution on the deserializing endpoint.

Please note that even if the MongoDB server is not exposed externally, an external attacker may still reach it or the REST API via a Server-Side Request Forgery vulnerability in any application on the same network. For example, MongoDB Servers can be attacked using HTTP or Gopher protocols.

Failure to protect the MongoDB port externally can have a large security impact. For example, an external attacker can use a single remove command to delete the whole data set. Recently, there have been reports of malicious attacks on unsecured instances of MongoDB running openly on the internet. The attacker erased the database and demanded a ransom be paid before restoring it.

All major browsers support the HttpOnly cookie property to prevent client-side scripts from accessing the cookie. Cross-site scripting attacks often access cookies in an attempt to steal session identifiers or authentication tokens. Without the HttpOnly flag enabled, attackers have easier access to user cookies.

Example 1: The following code creates a session cookie without setting the HttpOnly flag to true.

server.servlet.session.cookie.http-only=false

Cross-frame scripting vulnerabilities occur when an application:

1. Allows itself to be included inside an iframe.
2. Fails to specify framing policy via the X-Frame-Options header.
3. Uses poor protection, such as JavaScript-based frame busting logic.

Cross-frame scripting vulnerabilities often form the basis of clickjacking exploits that attackers may use to conduct cross-site request forgery or phishing attacks.

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.

GraphiQL is an in-browser tool that leverages the GraphQL schema introspection mechanism to provide a graphical interface for GraphQL API development and testing. GraphiQL assists users in exploring GraphQL schemas as well as composing and executing GraphQL queries.

Allowing access to GraphiQL in production is not recommended because enabling introspection of your GraphQL schemas through GraphiQL can pose a risk to your overall security posture. An attacker can use GraphiQL and introspection to obtain implementation details from a GraphQL schema that enables them to perform a more targeted attack. GraphQL schemas can leak information such as internally used fields, descriptions, and deprecation notes that might not be intended for public consumption.

Example 1: The following code initializes a GraphQL.js endpoint with GraphiQL enabled by default:

app.use('/graphql', graphqlHTTP({
    schema
}));

Content Security Policy (CSP) is a declarative security header that enables developers to specify allowed security-related behavior within the browser, including an allow list of locations from which content can be retrieved. It provides an additional layer of security from critical vulnerabilities such as cross-site scripting, clickjacking, cross-origin access and the like, on top of input validation and checking an allow list in code. An improperly configured header, however, fails to provide this additional layer of security. The policy is defined with the help of 15 directives including 8 that control resource access: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src. These 8 directives take a source list as a value that specifies domains the site is allowed to access for a feature covered by that directive. Developers can use a wildcard * to indicate all or part of the source. Additional source list keywords such as 'unsafe-inline' and 'unsafe-eval' provide more granular control over script execution but are potentially harmful. None of the directives are mandatory. Browsers either allow all sources for an unlisted directive or derive its value from the optional default-src directive. Furthermore, the specification for this header has evolved over time. It was implemented as X-Content-Security-Policy in Firefox until version 23 and in IE until version 10, and was implemented as X-Webkit-CSP in Chrome until version 25. Both of these names are deprecated in favor of the now standard name Content Security Policy. Given the number of directives, two deprecated alternate names, and the way multiple occurrences of the same header and repeated directives in a single header are treated, there is a high probability that a developer can misconfigure this header.

Example 1: The following code sets an overly permissive and insecure default-src directive:

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy policy-directives="default-src '*'" />
        </headers>
    </http>

Content Security Policy (CSP) is a declarative security header that enables developers to dictate which domains the site is allowed to load content from or initiate connections to when rendered in the web browser. It provides an additional layer of security from critical vulnerabilities such as cross-site scripting, clickjacking, cross-origin access and the like, on top of input validation and checking an allow list in code.

The Content-Security-Policy-Report-Only header provides the capability for web application authors and administrators to monitor security policies, rather than enforce them. This header is typically used when experimenting and/or developing security policies for a site. When a policy is deemed effective, you can be enforce it by using the Content-Security-Policy header field instead.

Example 1: The following code sets a Content Security Policy in Report-Only mode:

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-security-policy report-only="true" policy-directives="default-src https://content.cdn.example.com" />
        </headers>
    </http>

The lack of a proper source of entropy for use by the random or pseudorandom number generator may lead to denial of service or generation of predictable sequences of numbers. If the random or pseudorandom number generator uses the source of entropy that runs out, the program may pause or even crash, leading to denial of service. Alternatively, the random or pseudorandom number generator may produce predictable numbers. A weak source of random or pseudorandom numbers may lead to vulnerabilities such as easy-to-guess temporary passwords, predictable cryptographic keys, session hijacking, and DNS spoofing.

Example 1: The following code uses the system clock as the entropy source:

    ...
    srand (time(NULL));
    r = (rand() % 6) + 1;
    ...

Since system clock generates predictable values, it is not a good source of entropy. Same goes for other non-hardware-based sources of randomness, including system/input/output buffers, user/system/hardware/network serial numbers or addresses, as well as user input.

Using Google Remote Procedure Call (gRPC) server security settings that are specified as not be encrypted, or do not have the capacity of connection identity leaves the server open to many forms of attack. Data sent to and from this insecure server cannot be trusted.

Example 1: The following code shows a gRPC server setup with insecure server credentials

...
Server server = Grpc.newServerBuilderForPort(port, InsecureServerCredentials.create())
...

An HTTPS stripping attack is a type of man-in-the-middle attack where the attacker watches all the HTTP traffic for location headers and links that reference HTTPS and replaces them with HTTP ones. The attacker keeps a list of all HTTP substitutions made so that they can make the HTTPS request back to the server. All stripped HTTP connections are proxied out to the server over HTTPS. All traffic between the victim and the attacker is sent over HTTP, revealing usernames, passwords, and other private information, but the server is still receiving the expected HTTPS traffic from the attacker so nothing seems wrong.

HTTP Strict Transport Security (HSTS) is a security header that instructs the browser to always connect to the site that returning the HSTS headers over SSL/TLS during a period specified within the header. Any connection to the server over HTTP is automatically replaced with an HTTPS connection, even if the user types a URL with http:// in the browser's URL bar.

Example 1: The following code configures a Spring Security protected application to disable HSTS for subdomains:

	<http auto-config="true">
        ...
        <headers>
            ...
            <hsts include-sub-domains="false" />
        </headers>
	</http>

An HTTPS stripping attack is a type of man-in-the-middle attack where the attacker watches all the HTTP traffic for location headers and links that reference HTTPS and replaces them with HTTP versions. The attacker keeps a list of all HTTP substitutions made so that they can make the HTTPS request back to the server. All stripped HTTP connections are proxied out to the server over HTTPS. All traffic between the victim and the attacker is sent over HTTP, revealing usernames, passwords, and other private information, but the server is still receiving the expected HTTPS traffic from the attacker so nothing seems wrong.

HTTP Strict Transport Security (HSTS) is a security header that instructs the browser to always connect to the site that returning the HSTS headers over SSL/TLS during a period specified within the header. Any connection to the server over HTTP is automatically replaced with an HTTPS connection, even if the user types a URL with http:// in the browser's URL bar.

Example 1: The following code configures a Spring Security protected application to use a short expiration time:

    @Bean
    public SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        ...
        http.headers(headers ->
                headers.httpStrictTransportSecurity(hstsConfig ->
                    hstsConfig.maxAgeInSeconds(300)
                )
            );
        ...
    }

SMTP command injection vulnerabilities occur when an attacker may influence the commands sent to an SMTP mail server.

1. Data enters the application from an untrusted source.

2. The data is used as or as part of a string representing a command that is executed by the application.

3. By executing the SMTP command, the attacker is able to instruct the server to carry out malicious actions such as sending spam.

Example 1: The following code uses an HTTP request parameter to craft a VRFY command that is sent to the SMTP server. An attacker may use this parameter to modify the command sent to the server and inject new commands using CRLF characters.

  ...
  String user = request.getParameter("user");
  SMTPSSLTransport transport = new SMTPSSLTransport(session,new URLName(Utilities.getProperty("smtp.server")));
  transport.connect(Utilities.getProperty("smtp.server"), username, password);
  transport.simpleCommand("VRFY " + user);
  ...
  

A cryptographic hash function is a one-way function that is considered practically impossible to invert; that is, to recreate the input data from its digest value alone. These hash functions were considered safe to store passwords in the past because even if an attacker could access the digest value for the original password, they wouldn't be able to recover the original password from the digest value. This was proved wrong, as attackers used a dictionary attack with "rainbow tables" so that they could pre-compute the digest value for millions of words/phrases and after they got a password digest, they only had to compare its value with the values stored within the "rainbow tables" to get back the original password. As the computational power of personal computers increased over time, this technique became obsolete and was rapidly replaced with a brute-force attack enabled by "GPU" units. Attackers no longer need to pre-compute the password hashes (which was almost impossible with the use of salts); now they have enough computational power to brute-force possible passwords byte by byte.

Example 1: The following shows an application configured to use Java Simplified Encryption (Jasypt) Password encoder that just uses an MD5 digest under the covers:

...
    <param name="foo" class="org.jasypt.util.password.BasicPasswordEncoder">
        ...
    </param>  
...

It is never a good idea to use an empty salt. Not only does an empty salt defeat its own purpose but all of the project's developers can view the salt. It makes fixing the problem extremely difficult because after the code is in production, the salt cannot be easily changed. If attackers know the value of the salt, they can compute "rainbow tables" for the application and easily determine the hashed values.

Example 1: The following code defines an empty salt for password hashing:

...
define('SECURE_AUTH_SALT', "");
...

This code runs successfully, but anyone who has access to it can see the salt. After the program ships, there is likely no way to change the empty salt. An employee with access to this information can use it to break into the system.

It is never a good idea to use a null (nil) salt. Not only does using a null salt make it significantly easier to determine the hashed values, it also makes fixing the problem extremely difficult. After the code is in production, the salt cannot be easily changed. If attackers figure out that values are hashed with a null salt, they can compute "rainbow tables" for the application and more easily determine the hashed values.

Example 1: The following code uses a null (nil) salt:

...
CCKeyDerivationPBKDF(kCCPBKDF2,
                     password,
                     passwordLen,
                     nil,
                     0,
                     kCCPRFHmacAlgSHA256,
                     100000,
                     derivedKey,
                     derivedKeyLen);
...

This code will run successfully, but anyone who has access to it will have access to the null salt. After the program ships, there is likely no way to change the null salt. An employee with access to this information can use it to break into the system.

In AI applications, system prompts provide pre-processing instructions or context that guide the AI responses. Attackers can craft inputs that, when embedded as system prompts, alter the behavior of the AI model to execute unauthorized operations or disclose sensitive information.

Example 1: The following code illustrates a system prompt injection to an AI chat client that uses Spring AI:

  @GetMapping("/prompt_injection")
  String generation(String userInput1, ...) {
      return this.clientBuilder.build().prompt()
          .system(userInput1)
          .user(...)
          .call()
          .content();
  }

In this example, the attacker manipulates unvalidated input to a system prompt, which can lead to a security breach.

In AI applications, system prompts provide pre-processing instructions or context that guide the AI responses. Attackers can craft inputs that, when embedded as system prompts, alter the behavior of the AI model to execute unauthorized operations or disclose sensitive information. In the case of persistent prompt injection this untrusted input typically comes from database or a back-end data store as opposed to a web request.

Example 1: The following code illustrates a system prompt injection to an AI chat client that uses Spring AI:

  @GetMapping("/prompt_injection_persistent")
  String generation(String userInput1, ...) {
      Statement stmt = conn.createStatement();
      ResultSet rs = stmt.executeQuery("SELECT * FROM users WHERE ...");
      String userName = "";

      if (rs != null) {
        rs.next();
        userName = rs.getString("userName");
      }

      return this.clientBuilder.build().prompt()
          .system("Assist the user " + userName)
          .user(userInput1)
          .call()
          .content();
  }

In this example, the attacker manipulates unvalidated input to a system prompt, which can lead to a security breach.

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.