This class has been annotated with the annotation Immutable, from the JCIP annotations package. A non-final field violates the immutability of the class by allowing the value to be changed.

Example 1: The following code for an immutable class mistakenly declares a field public and not final.

@Immutable
public class ImmutableInteger {
public int value;

}

This class has been annotated with the annotation Immutable, from the JCIP annotations package. A public field of a mutable type allows code external to the class to modify the contents and violate the immutability of the class.

Example 1: The following code for an immutable final class mistakenly declares a Set public and final.

@Immutable
public final class ThreeStooges {
public final Set stooges = new HashSet();
...
}

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

JWT is a standard for creating a URL-safe means of transferring data between two parties. JWT provides protection against data tampering because the information it contains is digitally signed with either the HMAC or the RSA algorithm. The server typically generates JWTs after successful client authentication. This JWT accompanies future client requests to the server for stateless authentication.

A JSON Web Token contains three parts in the following format:
{header}.{payload}.{signature}
- A kid claim might be vulnerable to an injection attack. Some libraries use system calls (such as file-system lookups), or database queries to extract the key specified in the "kid" header value. By injecting malicious data into this claim, an attacker can force the application to perform arbitrary SQL queries, execute system commands, or maybe even redirect the target of the 'key file' to a known file on the system to force a new secret that can be used to sign and decrypt HMAC tokens.
.
- A jwk claim might be vulnerable to a key injection attack. This attack attempts a less-commonly used verification technique in some JWT libraries - the inclusion of an in-line Public Key. The attacker can sign the token using a new Private Key, include the Public Key in the token, and then let the service use that key to verify the token.

- A jku, x5u, and x5c claim might be vulnerable to JWKS spoofing. By replacing the "jku" or "x5u" URL with an attacker-controlled URL containing a public key, or by replacing the "x5c" certificate chain with an attacker-controlled chain with a public key, an attacker can use the paired private key to sign the token and let the service retrieve the malicious public key and verify the token.

Session tokens play a key role in maintaining state in modern web applications. Conceptually, a session management system contains a collection of state variables that are stored either client- or server-side, and session tokens (also collectively called session identifiers or session IDs) are used as the "key" to access these state variables. Session tokens can be placed in cookies, query/post parameters, or other HTTP headers and can be comprised of a single token or referenced in aggregate as a collection of multiple tokens.
Session tokens enable a web application to track an authenticated user's activities, correlate requests sent by that user, and provide appropriate services to the user accordingly. When a user successfully authenticates to a web application, the web application usually associates the user's identity with session tokens and accesses user data by referencing these tokens. Thus, weaknesses in deploying session tokens in a web application can be exploited by malicious attackers to hijack user sessions and compromise data confidentiality, integrity, and availability.

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.

Keyboard extensions are allowed to read every single keystroke that a user enters. Third-party keyboards are normally used to ease the text input or to add additional emojis and they may log what the user enters or even send it to a remote server for processing. Malicious keyboards can also be distributed to act as a keylogger and read every key entered by the user in order to steal sensitive data such as credentials or credit card numbers.

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.