X-XSS-Protection is an HTTP header introduced by Microsoft, since adopted by other browsers. This is intended to help stop Cross-Site Scripting attacks from being successful, but inadvertently led to a weakness making safe websites vulnerable[1]. Due to this, this shouldn't be used in older versions of Internet Explorer and should be disabled by setting the header to 0.

Example 1: The following misconfigures the Helmet middleware in an Express application to enable this for all versions of Internet Explorer:

var express = require('express');
var app = express();
var helmet = require('helmet');

...
app.use(helmet.xssFilter({ setOnOldIE: true}));
...

MIME sniffing is the practice of inspecting the content of a byte stream to deduce the file format of the data within it.

If MIME sniffing is not explicitly disabled, attackers can manipulate some browsers into interpreting data in a way that is not intended, allowing for cross-site scripting attacks. For each page that could contain user-controllable content, you should use the HTTP header X-Content-Type-Options: nosniff.

Example 1: The following code configures a Spring Security protected application to disable MIME sniffing protection:

	<http auto-config="true">
        ...
        <headers>
            ...
            <content-type-options disabled="true"/>
        </headers>
	</http>

Third-party applications that include content management systems with known vulnerabilities expand the attack surface available to the attacker. Deploying an unpatched or vulnerable version of a CMS can enable attackers to compromise the target by exploiting known vulnerabilities against the detected CMS.
Reconnaissance is a necessary precursor to any successful attack against an application. Attackers can use fingerprinting probes to identify the CMS used by the target application. This information can be used to:
- Devise attacks focused on exploiting known vulnerabilities reported against the detected CMS
- Test for default configuration properties that could lead to security weaknesses

APIs usually outgrow their initial scope. New features, breaking changes, security patches, and bug fixes are required regularly. Versioning helps to provide newer features and keep the existing features for backward compatibility or for users that are not ready to upgrade. Without a proper deprecation policy and thorough documentation, older API endpoints might still be accessible. If all versions of supported APIs are not included in relevant specification files (e.g., Swagger), or managed lists (e.g., API gateway), then they are likely not covered in relevant quality and security evaluation procedures; resulting in reduced attack surface testing.

Applications can send and receive data in raw format from WebSockets. However, most applications follow custom protocols. Security weaknesses in implementation of sub-protocols can lead to exploits.

Compiler optimization errors occur when:

1. Secret data is stored in memory.

2. The secret data is scrubbed from memory by overwriting its contents.



3. The source code is compiled using an optimizing compiler, which identifies and removes the function that overwrites the contents as a dead store because the memory is not used subsequently.
Example 1: The following code reads a password from the user, uses the password to connect to a back-end mainframe and then attempts to scrub the password from memory using memset().

  void GetData(char *MFAddr) {
  char pwd[64];
  if (GetPasswordFromUser(pwd, sizeof(pwd))) {
   if (ConnectToMainframe(MFAddr, pwd)) {
		 // Interaction with mainframe
	 }
  }
  memset(pwd, 0, sizeof(pwd));
}

The code in the example will behave correctly if it is executed verbatim, but if the code is compiled using an optimizing compiler, such as Microsoft Visual C++(R) .NET or GCC 3.x, then the call to memset() will be removed as a dead store because the buffer pwd is not used after its value is overwritten [2]. Because the buffer pwd contains a sensitive value, the application may be vulnerable to attack if the data is left memory resident. If attackers are able to access the correct region of memory, they may use the recovered password to gain control of the system.

It is common practice to overwrite sensitive data manipulated in memory, such as passwords or cryptographic keys, in order to prevent attackers from learning system secrets. However, with the advent of optimizing compilers, programs do not always behave as their source code alone would suggest. In the example, the compiler interprets the call to memset() as dead code because the memory being written to is not subsequently used, despite the fact that there is clearly a security motivation for the operation to occur. The problem here is that many compilers, and in fact many programming languages, do not take this and other security concerns into consideration in their efforts to improve efficiency.

Attackers typically exploit this type of vulnerability by using a core dump or runtime mechanism to access the memory used by a particular application and recover the secret information. After an attacker has access to the secret information, it is relatively straightforward to further exploit the system and possibly compromise other resources with which the application interacts.

If an array bounds check involves computing an illegal pointer and then determining that the pointer is out of bounds, some compilers will optimize the check away, assuming that the programmer would never intentionally create an illegal pointer.

Example 1:

  char *buf;
  int len;
  ...
  len = 1<<30;

  if (buf+len < buf)  //wrap check
    [handle overflow]

The operation buf + len is larger than 2^32, so the resulting value is smaller than buf. But since an arithmetic overflow on a pointer is undefined behavior, some compilers will assume buf + len >= buf and optimize away the wrap check. As a result of this optimization, code following this block could be vulnerable to buffer overflow.

Applications can be exposed to several threats if default unsafe configurations exist:
- Applications deployed with default configurations can allow attackers easily to fingerprint them and identify their weaknesses.
- Default configuration can reveal file system paths to known sensitive directories including locations of installation and configuration directories.
- More critically, many installations setup a default set of credentials for initial access to administrative functions. Failure to change these credentials can lead to a full compromise of the system.
- Sample programs included with installations can further expose unrestricted access to administrative features.
- Third-party vulnerabilities often target default application setups.

HTTP Request Smuggling vulnerabilities arise due to the discrepancy in parsing of non-compliant HTTP headers by the front-end and back-end servers. By supplying a request that is interpreted as being of different lengths by different servers, an attacker can poison the back-end TCP/TLS socket and prepend arbitrary data to the next request or smuggle additional requests to the back-end server without the front-end server being aware of it.
There are numerous ways in which a malicious user can accomplish an HTTP Request Smuggling attack. For example, an incoming HTTP request that contains both Content-Length and Transfer-Encoding headers is interpreted differently by the front-end server and the back-end server. One honors the Content-Length header and the other the Transfer-Encoding header to determine the length of the request. This can render the application vulnerable to smuggling attacks.

Versions of IIS web server software use a vulnerable version of the kernel-mode HTTP protocol driver HTTP.sys. By sending an HTTP request with a malformed Range header to a vulnerable server, an attacker can execute arbitrary code within the context of the System (administrator) user. The attacker might also use malformed requests to crash the server (rendering its services unavailable) or to expose the contents of the server's memory.

Programmers often entrust the applet code with sensitive information without realizing that applets can be easily decompiled and can expose any sensitive data hardcoded in the code. An attacker could decompile the applet and gain access to confidential information, including any hard-coded passwords and keys, within the applet. Java applets pose various risks including:

- Intellectual property theft
- Understanding of the security controls implemented by the application
- Extraction of confidential information, such as hard-coded passwords and keys
- Malicious alterations to the code with the purpose of compromising unsuspecting application users

Reconnaissance is a necessary precursor to any successful attack against an application. Attackers can successfully identify applications installed by:
1. Matching against client-side code patterns e.g. JavaScript function definitions or variable declarations
2. Probing for resources and interfaces specific to the application being fingerprinted
3. Matching against textual content on web pages that might identify the application underlying the target
4. Locating references to logo image files with identifiable names
This information can aid the attacker in constructing exploits to target known vulnerabilities against the application.

CAPTCHAs are commonly used by web applications to prevent automated form submissions that can have an adverse effect on their operation. Poorly written CAPTCHA implementations can provide a false sense of security. Attackers can fingerprint for implementations with known vulnerabilities and use this information to bypass an application's anti-automation protections. CAPTCHA implementations can be identified by:
1. Matching against known client-side code patterns. For instance, HTML tags and attributes with specific values.
2. Matching against textual content identifying the CAPTCHA implementation

Example 1: Powered by Animated Gif Captcha
3. Matching against references to known resources and image files

Attackers can fingerprint frameworks used for constructing an application based on features such as file extensions and URI patterns. This information can help an attacker to:
1. Probe for known framework vulnerabilities
2. Target weaknesses known to commonly plague applications built on top of the detected framework
3. Exploit insecure use of features specific to the detected framework

Using fingerprinting probes, attackers can often identify the web server used to host the target application. This information can be used to:
1. Devise attacks focused on exploiting known vulnerabilities reported against the detected server
2. Test for default configuration properties that could lead to security weaknesses

Example 1: Directory listing enabled
3. Exploit known services exposed by the server

Example 2: WebDAV enabled on IIS
4. Customize attacks for the detected server
5. Enumerate known sensitive resources such as installation, setup, and configuration files

Fingerprinting the technology underlying the target application allows attackers to:
1. Target security weaknesses resulting from insecure development practices commonly observed in applications based on detected technology

Example 1: Hardcoded credentials and encryption keys in Java applets
2. Exploit known security issues reported against the detected technology

Attackers frequently install backdoors in the form of a PHP Shell, which attackers use to execute commands to the underlying operating system with at least the permissions of the web server. This means that attackers can modify or read any file that the web server is capable of reading. In worst cases, the attacker can install malware and take over the server machine. Presence of such a program could either indicate a successful compromise of the application or an insider threat.

The Django application exposes the serve view of the static files application which is not designed to be deployed in a production environment. According to Django documentation:

"The static files tools are mostly designed to help with getting static files successfully deployed into production. This usually means a separate, dedicated static file server, which is a lot of overhead to mess with when developing locally. Thus, the staticfiles app ships with a quick and dirty helper view that you can use to serve files locally in development.

This view will only work if DEBUG is True.

That's because this view is grossly inefficient and probably insecure. This is only intended for local development, and should never be used in production."

OpenSSL is a popular third-party library used to encrypt network traffic. Depending on the version used, it might contain high profile vulnerabilities such as Heartbleed, ChangeCipherSpec injection, and incorrectly implemented Anonymous Elliptic Curve Diffie-Hellman (AECDH) ciphersuite. An application environment deployed with a vulnerable version of OpenSSL might be subjected to critical security threats including, but not limited to, denial of service, sensitive information disclosure, and unauthorized access to past encrypted information.

Path Normalization Conflict can occur in systems with multi-layered architecture where the components have different approaches to Path Normalization process. An attacker can bypass allow list and deny list ACL rules on intermediate components and as a result sensitive resources are unexpectedly exposed.
Example 1:
Using the proxy_pass directive, NGINX can forward all requests for /publicfolder to the Tomcat server. The developer expects that only this folder is accessible to users. However, an attacker can send the next request http://targetserver/publicfolder/..;/manager/html
NGINX considers ..; to be a folder name so the path matches the rule and this request is forwarded to the Tomcat server.
The Tomcat server considers ..; to indicate parent directory and will map the request to /publicfolder/../manager/html, giving the attacker access to the manager app of Tomcat server.