Several tools exist within the Java development world to aid in dependency management: both Apache Ant and Apache Maven build systems include functionality specifically designed to help manage dependencies and Apache Ivy is developed explicitly as a dependency manager. Although there are differences in their behavior, these tools share the common functionality that they automatically download external dependencies specified in the build process at build time. This makes it much easier for developer B to build software in the same manner as developer A. Developers just store dependency information in the build file, which means that each developer and build engineer has a consistent way to obtain dependencies, compile the code, and deploy without the dependency management hassles involved in manual dependency management. The following examples illustrate how Ivy, Ant, and Maven can be used to manage external dependencies as part of a build process.

Developers specify external dependencies in an Ant target using a <get> task, which retrieves the dependency specified by the corresponding URL. This approach is functionally equivalent to scenario where a developer documents each external dependency as an artifact included with the software project, but is more desirable because it automates the retrieval and incorporation of the dependencies when a build is performed.

Example 1: The following excerpt from an Ant build.xml configuration file shows a typical reference to an external dependency:

<get src="http://people.apache.org/repo/m2-snapshot-repository/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
dest="${maven.repo.local}/org/apache/openejb/openejb-jee/3.0.0-SNAPSHOT/openejb-jee-3.0.0-SNAPSHOT.jar"
usetimestamp="true" ignoreerrors="true"/>

Two distinct types of attack scenarios affect these systems: An attacker could either compromise the server hosting the dependency or compromise the DNS server the build machine uses to redirect requests for hostname of the server hosting the dependency to a machine controlled by the attacker. Both scenarios result in the attacker gaining the ability to inject a malicious version of a dependency into a build running on an otherwise uncompromised machine.

Regardless of the attack vector used to deliver the Trojan dependency, these scenarios share the common element that the build system blindly accepts the malicious binary and includes it in the build. Because the build system has no recourse for rejecting the malicious binary and existing security mechanisms, such as code review, typically focus on internally-developed code rather than external dependencies, this type of attack has a strong potential to go unnoticed as it spreads through the development environment and potentially into production.

Although there is some risk of a compromised dependency being introduced into a manual build process, by the tendency of automated build systems to retrieve the dependency from an external source each time the build system is run in a new environment greatly increases the window of opportunity for an attacker. An attacker need only compromise the dependency server or the DNS server during one of the many times the dependency is retrieved in order to compromise the machine on which the build is occurring.

Several tools exist within the Java development world to aid in dependency management: both Apache Ant and Apache Maven build systems include functionality specifically designed to help manage dependencies and Apache Ivy is developed explicitly as a dependency manager. Although there are differences in their behavior, these tools share the common functionality that they automatically download external dependencies specified in the build process at build time. This makes it much easier for developer B to build software in the same manner as developer A. Developers just store dependency information in the build file, which means that each developer and build engineer has a consistent way to obtain dependencies, compile the code, and deploy without the dependency management hassles involved in manual dependency management. The following examples illustrate how Ivy, Ant, and Maven can be used to manage external dependencies as part of a build process.

Under Ivy, instead of listing explicit URLs from which to retrieve the dependencies, developers specify the dependency names and versions and Ivy relies on its underlying configuration to identify the server(s) from which to retrieve the dependencies. For commonly used components this saves the developer from having to researching dependency locations.

Example 1: The following excerpt from an Ivy ivy.xml file shows how a developer can specify multiple external dependencies using their name and version:

<dependencies>
  <dependency org="javax.servlet"
             name="servletapi"
              rev="2.3" conf="build->*"/>
  <dependency org="javax.jms"
             name="jms"
              rev="1.1" conf="build->*"/>  ...
</dependencies>

Two distinct types of attack scenarios affect these systems: An attacker could either compromise the server hosting the dependency or compromise the DNS server the build machine uses to redirect requests for hostname of the server hosting the dependency to a machine controlled by the attacker. Both scenarios result in the attacker gaining the ability to inject a malicious version of a dependency into a build running on an otherwise uncompromised machine.

Regardless of the attack vector used to deliver the Trojan dependency, these scenarios share the common element that the build system blindly accepts the malicious binary and includes it in the build. Because the build system has no recourse for rejecting the malicious binary and existing security mechanisms, such as code review, typically focus on internally-developed code rather than external dependencies, this type of attack has a strong potential to go unnoticed as it spreads through the development environment and potentially into production.

Although there is some risk of introducing a compromised dependency into a manual build process because the tendency of automated build systems to retrieve the dependency from an external source each time the build system runs in a new environment increases the window of opportunity for an attacker. An attacker need only compromise the dependency server or the DNS server during one of the many times the dependency is retrieved in order to compromise the machine on which the build is occurring.

Several tools exist within the Java development world to aid in dependency management: both Apache Ant and Apache Maven build systems include functionality specifically designed to help manage dependencies and Apache Ivy is developed explicitly as a dependency manager. Although there are differences in their behavior, these tools share the common functionality that they automatically download external dependencies specified in the build process at build time. This makes it much easier for developer B to build software in the same manner as developer A. Developers just store dependency information in the build file, which means that each developer and build engineer has a consistent way to obtain dependencies, compile the code, and deploy without the dependency management hassles involved in manual dependency management. The following examples illustrate how Ivy, Ant, and Maven can be used to manage external dependencies as part of a build process.

Under Maven, instead of listing explicit URLs from which to retrieve the dependencies, developers specify the dependency names and versions and Maven relies on its underlying configuration to identify the server(s) from which to retrieve the dependencies. For commonly used components this saves the developer from having to researching dependency locations.

Example 1: The following excerpt from a Maven pom.xml file shows how a developer can specify multiple external dependencies using their name and version:

<dependencies>
  <dependency>
    <groupId>commons-logging</groupId>
    <artifactId>commons-logging</artifactId>
    <version>1.1</version>
  </dependency>
  <dependency>
    <groupId>javax.jms</groupId>
    <artifactId>jms</artifactId>
    <version>1.1</version>
  </dependency>
  ...
</dependencies>

Two distinct types of attack scenarios affect these systems: An attacker could either compromise the server hosting the dependency or compromise the DNS server the build machine uses to redirect requests for hostname of the server hosting the dependency to a machine controlled by the attacker. Both scenarios result in the attacker gaining the ability to inject a malicious version of a dependency into a build running on an otherwise uncompromised machine.

Regardless of the attack vector used to deliver the Trojan dependency, these scenarios share the common element that the build system blindly accepts the malicious binary and includes it in the build. Because the build system has no recourse for rejecting the malicious binary and existing security mechanisms, such as code review, typically focus on internally-developed code rather than external dependencies, this type of attack has a strong potential to go unnoticed as it spreads through the development environment and potentially into production.

Although there is some risk of a compromised dependency being introduced into a manual build process, by the tendency of automated build systems to retrieve the dependency from an external source each time the build system is run in a new environment greatly increases the window of opportunity for an attacker. An attacker need only compromise the dependency server or the DNS server during one of the many times the dependency is retrieved in order to compromise the machine on which the build is occurring.

An HTTP response containing a Vary header indicates that server-driven negotiation was done to determine which content should be delivered. This might indicate that different content is available based on the headers in the HTTP request. An attacker could gain access to content not intended for public consumption by submitting different values through the request headers.

HTML5 provides the ability for browsers to request and cache part of the web application, allowing it to be accessed while the user is offline. Developers use the application cache manifest file served with the appcache extension to list resources that are part of the offline functionality. Offline cache contents are only updated when the application manifest is updated. Therefore, it is essential that browsers or intermediary proxy servers do not cache the application cache manifest file.

While content transmitted over an SSL/TLS channel is expected to guarantee confidentiality, administrators must nonetheless ensure that caching of sensitive content is disabled unless absolutely needed. The misconception that secure content caching is disabled by default by user-agents could cause the application to fail the organization's cache policy by leaving the secure content cacheable by browsers. Unsafe specification such as Cache-Control: public would instruct the browser to persistently cache the content on the hard drive. Caching can be prevented by specifying one of the following three directives in the response headers
- Cache-control: private
- Cache-Control: no-cache
- Cache-Control: no-store
SSL provides a secure encrypted channel to transfer information from source to user. The information served over SSL is considered sensitive and trusted to be only available to requestor. However, caching this content on disk in temporary internet files or in intermediate proxy server can compromise that trust by exposing it to everyone who has access to these temporary storage or proxy cache. Content served over SSL must have cache disabled.

An HTTP response containing a Vary header indicates that server-driven negotiation was done to determine which content should be delivered. It can be used to set "accept-language" as the criteria for negotiation. This might indicate that different content is available based on the Accept-Language header in the HTTP request. An attacker could access information not intended for public consumption by submitting different values in the Accept-Language header.

Active user sessions can be compromised by:
- Disclosure of session cookies enabling session hijacking attacks
- Insecure caching policies that could instruct proxy servers to store web page responses containing authenticated session information
- Cache-control header is defined as public, all intermediate proxy servers and gateways between the client and server are permitted to cache web pages served by the application.
- Attackers can use unexpired session identifiers disclosed in the cached cookies to masquerade as legitimate users and steal personal data belonging to the victim of the session hijacking attack

An HTTP response containing a Vary header indicates that server-driven negotiation was done to determine which content should be delivered. A "*" can be used as the field value, which means that it cannot be determined from the HTTP headers what criteria was used to select content. An attacker can use this behavior to gain valuable insight into the application's business logic and use it to orchestrate targeted attacks.

An HTTP response containing a Vary header indicates that server-driven negotiation was done to determine which content should be delivered. It can be used to set "user-agent" as the criteria for negotiation. This might indicate that different content is available based on the User-Agent header in the HTTP request. An attacker could discover hidden application functionality or resources by submitting different values in the user-agent header.

In Web Cache Poisoning (WCP) the attacker exploits the behavior of caches. This is done by exploiting multiple mechanisms. Some of which include identifying unkeyed inputs such as headers. Unkeyed inputs are used to construct the response but are not the part of cache key.
Web cache ignores the unkeyed input when sending responses. Therefore, it sends the malicious responses that the attacker had cached with the help of these unkeyed inputs.
The unkeyed inputs can be reflected in the response or can be used to dynamically generate responses.
Another mechanism uses fat GET requests. Fat GET requests are GET requests with a request body. An attacker can duplicate a query parameter in the request body with attacker-controlled value and trick an application into responding differently. An intermediate cache might ignore such a request body when caching the response and respond with a cached fat GET response when a normal request arrives.

WCP is possible through a variety of methods including unkeyed headers, fat GET requests, unkeyed ports, unkeyed query parameters, and more.

CakePHP can be configured to expose debugging information that includes errors, warnings, SQL statements, and stack traces. Debug information should not be used in production environments.

Example 1:

    Configure::write('debug', 3);

The second parameter to the Configure::write() method indicates the debug level. The higher the number, the more verbose the log messages.

The longer a session stays open, the larger the window of opportunity an attacker has to compromise user accounts. While a session remains active, an attacker may be able to brute-force a user's password, crack a user's wireless encryption key, or commandeer a session from an open browser. Longer session timeouts can also prevent memory from being released and eventually result in a denial of service if a sufficiently large number of sessions are created.

Example 1: The following example shows CakePHP configured with low session security.

    Configure::write('Security.level', 'low');

In conjunction with the Session.timeout setting, the Security.level settings define how long a session is valid. The actual session timeout time is a equal to the Session.timeout times one of the following multiples:

'high' = x 10
'medium' = x 100
'low' = x 300

Storing a plain text certificate in a configuration or manifest file allows anyone who can read the file access to the certificate-protected resource. Developers sometimes believe that they cannot defend the application from someone who has access to the configuration, but this attitude makes an attacker's job easier. Good certificate management guidelines require that a certificate never be stored in plain text.

ClassLoader manipulation allows an attacker to access and modify the underlying application server settings. On certain applications servers like Tomcat 8, an attacker may tweak these settings to upload a web shell and execute arbitrary commands.

The installation and setup for some applications establish a set of default credentials that can expose restricted interfaces of the application to unauthorized users. Often these default credentials are well known to the attackers. Such installations also face a high risk of compromise from login brute force attacks.

DNS Spoofing, also known as DNS Cache Poisoning, is a type of attack in which an attacker corrupts the DNS resolver's cache, leading it to return incorrect IP addresses. Using DNS spoofing, an attacker can redirect users to malicious websites without their knowledge. In the context of server-side JavaScript using Node.js, improper handling of DNS server settings can lead to security vulnerabilities.

Example 1: Consider a scenario where a Node.js application enables users to specify custom DNS servers. If this input is not properly validated and sanitized, an attacker can supply malicious DNS servers and implement DNS spoofing attacks.

const dns = require('dns');

// User-controlled input for DNS servers
const customDnsServers = from_user_controlled_input;

// Set custom DNS servers
dns.setServers(customDnsServers);

In this example, the customDnsServers variable is assigned a value derived from user-controlled input. This input is then used to set the DNS servers using dns.setServers(customDnsServers). If an attacker provides malicious DNS server addresses, they can direct the application to resolve domain names using their servers, which can return false IP addresses.

When a Dockerfile does not specify a USER, Docker containers run with super user privileges by default. These super user privileges are propagated to the code running inside the container, which is usually more permission than necessary. Running the Docker container with super user privileges broadens the attack surface which might enable attackers to perform more serious forms of exploitation.

Dockerfiles can specify an unbound range of versions for dependencies and base images. If an attacker is able to add malicious versions of dependencies to a repository or trick the build system into downloading dependencies from a repository under the attacker's control, if docker is configured without specific versions of dependencies, then docker will silently download and run the compromised dependency.

This type of weakness would be exploitable as a result of a supply chain attack where attackers can leverage misconfiguration by developers, typosquatting and can add malicious packages to open source repositories. An attack of this type exploits the trust in the published packages to gain access and exfiltrate data.

In docker, the latest tag automatically indicates the version level of an image that doesn't use a digest or unique tag to provide a version for it. Docker automatically assigns the latest tag as mechanism to point to the most recent image manifest file. Because tags are mutable, an attacker can replace an image or layer using a latest (or weak tags such as imagename-lst, imagename-last, myimage).

Example 1: The following configuration instructs Docker to pick the base image using the latest version of ubuntu.

    FROM ubuntu:Latest
    ...

Docker does not validate whether the repository configured to support the package manager is trustworthy.

Example 2: The following configuration instructs the package manager zypper to retrive the latest version of the given package.

...
zypper install package
...

In Example 2, if the repository is compromised, an attacker could simply upload a version that meets the dynamic criteria and cause zypper to download a malicious version of the dependency.

Dockerfile with USER instruction that is set to root, has an overly permissive privilege to make changes inside the container. It violates the principle of running images with least privileges. In usual cases, root permissions might be required to install packages and create folders. After the installation is done, it is good practice to add a user with restricted privileges.