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 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.

A lack of audit records limits the ability to detect and respond to security-related incidents and prevents forensic investigation.

Configuration settings that undermine logging capabilities include but are not limited to:
- deliberately disabling audit logging
- exempting actions of specific users, groups, or processes from being logged
- inadequately protecting log integrity
- not enabling optional audit logging
- reducing the log sampling rate

The Apache Ivy automated dependency management system allows users to specify a version status, known as a dynamic revision, for a dependency instead of listing the specific. If an attacker is able to compromise the dependency repository or trick the build system into downloading dependencies from a repository under the attacker's control, then a dynamic revision specifier may be all that's needed for the build system to silently download and run the compromised dependency. Beyond the security risks, dynamic revisions also introduce an element of risk on the code quality front: Dynamic revisions place the security and stability of your software under the control of the third-parties who develop and release the dependencies your software uses.

At build time, Ivy connects to the repository and attempts to retrieve a dependency that matches the status listed.

Ivy accepts the following dynamic revision specifiers:

- latest.integration: Selects the latest revision of the dependency module.
- latest.[any status]: Selects the latest revision of the dependency module with at minimum the specified status. For example, latest.milestone will select the latest version that is either a milestone or a release, and latest.release will only select the latest release.
- Any revision that ends in +: Selects the latest sub-revision of the dependency module. For example, if the dependency exists in revisions 1.0.3, 1.0.7 and 1.1.2, a revision specified as 1.0.+ will select revision 1.0.7.
- Version ranges: Mathematical notation for ranges, such as < and >, can be used to match a range of versions.

Example 1: The following configuration entry instructs Ivy to retrieve the latest release version of the clover component:

<dependencies>
        <dependency org="clover" name="clover"
                    rev="latest.release" conf="build->*"/>
	...

If the repository is compromised, an attacker could simply upload a version that meets the dynamic criteria to cause Ivy to download a malicious version of the dependency.

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.

ASP.NET applications can store user name and password pairs in <credentials> elements in the web.config file for an ASP.NET application, which supports plain text, MD5 and SHA1 password formats.

Passwords stored in plain text or using a weak encryption algorithm are accessible to anyone with the access to the application's configuration files. This may include the machine where the application is hosted or the source code repository where the application lives.

Example 1: The following web.config entry incorrectly stores its passwords in plain text.

<configuration>
  <system.web>
    <authentication>
      <forms protection="All">
	   <credentials passwordFormat="Clear">
   		<user name="user1" password="my_password"/>
		<user name="user2" password="my_password1"/>
        </credentials>
    	 </forms>
    </authentication>
  </system.web>
</configuration>

ASP.NET supports credential passwords stored in three formats, specified by the passwordFormat attribute of the configuration/system.web/authentication/forms/credentials element. The possible values for this attribute are:

Clear - indicates that the password is stored in plain text (least secure)
MD5 - indicates that the password's MD5 hash is stored
SHA1 - indicates that the password's SHA1 hash is stored (most secure)

While an MD5 hash is more secure than plain text, researchers have found brute-force attacks against the MD5 hashing algorithm. At this time, a SHA1 hash still provides reasonable protection against such attacks.

ASP.NET applications can store user name and password pairs in <credentials> elements in the web.config file for an ASP.NET application, which supports plain text, MD5 and SHA1 password formats.

Passwords stored in plain text or using a weak encryption algorithm are accessible to anyone with the access to the application's configuration files. This may include the machine where the application is hosted or the source code repository where the application lives.

Example 1: The following web.config entry incorrectly stores its passwords in plain text.

<configuration>
  <system.web>
    <authentication>
      <forms protection="All">
	   <credentials passwordFormat="Clear">
   		<user name="user1" password="my_password"/>
		<user name="user2" password="my_password1"/>
        </credentials>
    	 </forms>
    </authentication>
  </system.web>
</configuration>

ASP.NET supports credential passwords stored in three formats, specified by the passwordFormat attribute of the configuration/system.web/authentication/forms/credentials element. The possible values for this attribute are:

Clear - indicates that the password is stored in plain text (least secure)
MD5 - indicates that the password's MD5 hash is stored
SHA1 - indicates that the password's SHA1 hash is stored (most secure)

While an MD5 hash is more secure than plain text, researchers have found brute-force attacks against the MD5 hashing algorithm. At this time, a SHA1 hash still provides reasonable protection against such attacks.

If the cacheRolesInCookie attribute of the configuration/system.web/authentication/forms element in web.config is set to true, the role information for each user is cached in a cookie. By default, ASP.NET applications encrypt the cookie and validate the cookie content when sending it to the server. However, cookie protection can be weakened by setting the CookieProtection attribute to Validation or Encryption, which disables either the encryption step or or the validation step. If the encryption step is disabled, anyone with access to machines used to interact with the application have access to the role information stored in the cookie. If the validation step is disabled, attackers can potentially modify the data stored in cookies and falsify information provided to the application and potentially alter its behavior to their advantage.

If the cacheRolesInCookie attribute of the configuration/system.web/authentication/forms element in web.config is set to true, the role information for each user is cached in a cookie. By default, ASP.NET applications encrypt the cookie and validate the cookie content when sending it to the server. However, cookie protection can be disabled by setting the CookieProtection attribute to None. In this case, anyone with access to the machines used to interact with the application have access to the role information stored in the cookie. Worse yet, if attackers are allowed to arbitrarily modify the data stored in cookies, they can falsify information provided to the application and potentially alter its behavior to their advantage.

web.xml security constraints are typically used for role based access control, but the optional user-data-constraint element specifies a transport guarantee that prevents content from being transmitted insecurely.

Within the <user-data-constraint> tag, the <transport-guarantee> tag defines how communication should be handled. There are three levels of transport guarantee:

1) NONE means that the application does not require any transport guarantees.
2) INTEGRAL means that the application requires that data sent between the client and server be sent in such a way that it cannot be changed in transit.
3) CONFIDENTIAL means that the application requires that data be transmitted in a fashion that prevents other entities from observing the contents of the transmission.



In most circumstances, the use of INTEGRAL or CONFIDENTIAL means that SSL/TLS is required. If the <user-data-constraint> and <transport-guarantee> tags are omitted, the transport guarantee defaults to NONE.

Example 1: The following security constraint does not specify a transport guarantee.

<security-constraint>
    <web-resource-collection>
        <web-resource-name>Storefront</web-resource-name>
        <description>Allow Customers and Employees access to online store front</description>
        <url-pattern>/store/shop/*</url-pattern>
    </web-resource-collection>
    <auth-constraint>
        <description>Anyone</description>
        <role-name>anyone</role-name>
    </auth-constraint>
</security-constraint>

Many applications use cookies to communicate a user's session identifier. When the application is accessed over HTTPS, cookies are protected (attackers are unable to sniff them). But if developers allow HTTP access to non-sensitive parts of the application, the session identifier can be stolen. When a user browses to an unprotected part of the site, the cookie, containing the session ID, is sent in the clear. If attackers sniff the traffic, they can see the session ID and use it to take control of the user's session.


The following example shows a configuration that mixes insecure and secure channels:

  <property name="filterInvocationDefinitionSource">
    <value>
      CONVERT_URL_TO_LOWERCASE_BEFORE_COMPARISON
      \A/secure/.*\Z=REQUIRES_SECURE_CHANNEL
      \A/acegilogin.jsp.*\Z=REQUIRES_SECURE_CHANNEL
      \A/j_acegi_security_check.*\Z=REQUIRES_SECURE_CHANNEL
      \A.*\Z=REQUIRES_INSECURE_CHANNEL
    </value>
  </property>

ASP.NET W3Clogger.loggingFields can be configured to allow logging sensitive data such as private and system information.
This data can contain sensitive information related to HTTP requests and HTTP responses such as clients/server IP, server ports, header cookies and authenticated usernames that accessed the server.

In case of data breach, adversary can use this information to:

- Steal sensitive information or impersonate a user with higher privileges.
- Discover internal servers, gain unauthorized access to restricted resources.
- Devise attacks focused on exploiting known vulnerabilities reported against the detected server


Example 1: The following code shows an action method in a controller where validation has been disabled:

  builder.Services.AddW3CLogging(logging =>
    logging.LoggingFields = W3CLoggingFields.All;

    ... )

Example 1 shows how W3Clogging can be configure, using Flag All, to log all possible fields in Http request, including sensitive data such as ClientIpAddress, ServerName, ServerIpAddress, ServerPort, UserName, and Cookie.

This ASP.NET Core application does not configure controllers or controller methods of sensitive nature to only be accessible over a secure connection.

A service that does not authenticate its clients allows access to all comers.

A service that does not authenticate its clients allows access to all comers.

Kubelets can authenticate clients but the Certificate Authority (CA) bundle used to verify the client certificate is not defined in the Kubelet Configuration. Because Kubelets are the Kubernetes principal agents used to manage a worker machine workload, attackers can use anonymous requests to gain access to insufficiently protected and security-sensitive service APIs.

Example 1: The following Kubelet configuration does not contain the clientCAFile field that specifies the CA bundle used to verify client certificates.

apiVersion: kubelet.config.k8s.io/v1beta1
kind: KubeletConfiguration

The Mule Database Connector should force encrypted transport and verify database server certificates. If relevant database connection properties are left unspecified or misconfigured, the resulting connections expose the data to unauthorized access, tampering, and potential theft.

If authentication is not used to connect to an MSMQ queue used to deliver a message to another program, an attacker could submit an anonymous message that is malicious.

Example 1: The <netMsmqBinding/> element of the following WCF configuration file instructs WCF to disable authentication when connecting to an MSMQ queue for message delivery.

    <bindings>
      <netMsmqBinding>
        <binding>
          <security>
            <transport msmqAuthenticationMode="None" />
          </security>
        </binding>
      </netMsmqBinding>
    </bindings>

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

When present, the open_basedir configuration option attempts to prevent PHP programs from operating on files outside of the directory trees specified in php.ini. If no directories are specified using the open_basedir option, then programs running under PHP are given full access to arbitrary files on the local file system, which can allow attackers to read, write or create files that they should not be able to access.

Failing to specify a restrictive set of directories with open_basedir can make it easier for attackers to exploit other vulnerabilities.

Although the open_basedir option is an overall boon to security, the implementation suffers from a race condition that can permit attackers to bypass its restrictions in some circumstances [2]. A time-of-check, time-of-use (TOCTOU) race condition exists between the time PHP performs the access permission check and when the file is opened. As with file system race conditions in other languages, this race condition can allow attackers to replace a symlink to a file that passes an access control check with another for which the test would otherwise fail, thereby gaining access to the protected file.

The window of vulnerability for such an attack is the period of time between when the access check is performed and when the file is opened. Even though the calls are performed in close succession, modern operating systems offer no guarantee about the amount of code that will be executed before the process yields the CPU. Attackers have a variety of techniques for expanding the length of the window of opportunity in order to make exploits easier, but even with a small window, an exploit attempt can simply be repeated over and over until it is successful.