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

Even if castor creates a lock on an object it does not prevent other threads from reading or writing to it. Read-only queries are also about 7 times faster compared with default shared mode.

Example 1: The following example specifies the query mode as SHARED which allows both read and write access.

results = query.execute(Database.SHARED);

By default Castor executes queries in shared mode. Since shared mode allows both read and write access, it is unclear what kind of operation the query is intended for. If the object is going to be used in a read-only context, shared access adds unnecessary performance overhead.

Example 1: The following example does not specify a query mode.

results = query.execute();    //missing query mode

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.

The target application uses Apache Struts [1] version 1.x (pre-1.3.10) or 2.x (pre-2.3.16), which contains a remote command injection vulnerability identified as CVE-2014-0112 and CVE-2014-0114. [2, 3, 4, 5] The vulnerability results from insufficient validation performed by the ParametersInterceptor, allowing access to the getClass() method through the class parameter. This can enable an attacker to manipulate the ClassLoader and execute arbitrary Java code using crafted action parameters.

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.

Template engines are used to render content using dynamic data. This context data is normally controlled by the user and formatted by the template to generate web pages, emails, and so on. Template engines allow powerful language expressions to be used in templates to render dynamic content, by processing the context data with code constructs such as conditionals, loops, etc. If an attacker can control the template to be rendered, they can inject expressions that expose context data and run malicious code in the browser.

Example 1: The following example shows how a template is retrieved from the URL and used to render information with AngularJS.

function MyController(function($stateParams, $interpolate){
    var ctx = { foo : 'bar' };
    var interpolated = $interpolate($stateParams.expression);
    this.rendered = interpolated(ctx);
    ...
}

In this case, $stateParams.expression will be taking potentially user-controlled data, and evaluating this as a template to be used with a specified context. This in turn may enable a malicious user to run any code they wish within the browser, retrieving information about the context it's run against, finding additional information about how the application is created, or turning this into a full blown XSS attack.

Arithmetic operations will not act in the same way on boolean values as they would on integral values, which may lead to unexpected behavior.

When data from a byte array is converted into a String, it is unspecified what will happen to any data that is outside of the applicable character set. This can lead to data being lost, or a decrease in the level of security when binary data is needed to ensure proper security measures are followed.

Example 1: The following code converts data into a String in order to create a hash.

  ...
  FileInputStream fis = new FileInputStream(myFile);
  byte[] byteArr = byte[BUFSIZE];
  ...
  int count = fis.read(byteArr);
  ...
  String fileString = new String(byteArr);
  String fileSHA256Hex = DigestUtils.sha256Hex(fileString);
  // use fileSHA256Hex to validate file
  ...

Assuming the size of the file is less than BUFSIZE, this works fine as long as the information in myFile is encoded the same as the default character set, however if it's using a different encoding, or is a binary file, it will lose information. This in turn will cause the resulting SHA hash to be less reliable, and could mean it's far easier to cause collisions, especially if any data outside of the default character set is represented by the same value, such as a question mark.

At some point in every .NET developer's career, a problem surfaces that appears to be so mysterious, impenetrable, and impervious to debugging that there seems to be no alternative but to blame the garbage collector. Especially when the bug is related to time and state, there may be a hint of empirical evidence to support this theory: inserting a call to GC.Collect() sometimes seems to make the problem go away.

In almost every case we have seen, calling GC.Collect() is the wrong thing to do. In fact, calling GC.Collect() can cause performance problems if it is invoked too often.