An application should only have the minimum permissions required for its proper execution. Extra permissions might deter users from installing the application. This permission might be unnecessary for this program.

All modern web development frameworks provide built-in session management support. Prior knowledge of session identifiers is essential for hijacking user sessions using attacks such as Cross-Site Request Forgery and Clickjacking. This knowledge can also help attackers fingerprint the web frameworks and technologies used to build the target application. Attackers can use this information to discover hidden resources, customize their exploits, and target known exploits disclosed against the detected frameworks or technologies.

Spring Boot applications can be configured to deploy Actuators, which are REST endpoints that allow users to monitor different aspects of the application. There are different built-in Actuators which may expose sensitive data and are labeled as "sensitive". By default all sensitive HTTP endpoints are secured such that only users that have an ACTUATOR role may access them.

This application is either disabling the authentication requirement for sensitive endpoints:

Example 1:

management.security.enabled=false

Or marking sensitive endpoints as non-sensitive:

Example 2:

endpoints.health.sensitive=false

Or a custom Actuator is set as non-sensitive:

@Component
public class CustomEndpoint implements Endpoint<List<String>> {

    public String getId() {
        return "customEndpoint";
    }

    public boolean isEnabled() {
        return true;
    }

    public boolean isSensitive() {
        return false;
    }

    public List<String> invoke() {
        // Custom logic to build the output
        ...
    }
}

Spring Boot allows developers to enable admin-related features for the application by specifying the spring.application.admin.enabled property. This exposes the SpringApplicationAdminMXBean on the platform MBeanServer. Developers could use this feature to administer the Spring Boot application remotely, however this feature exposes an additional attack surface in the form of a remote JMX endpoint. Depending on the configuration of the MBeanServer the MBean can be exposed locally or remotely, and may or may not require authentication. In the worst case, attackers will be able to manage the application remotely, including shutting it down without any authentication. In the best case, the service will be as strong as the credentials used to protect the server.

Note: If using a JRE version vulnerable to CVE-2016-3427 (fixed in Java 8 Update 91, April 2016), an attacker will be able to pass any serialized Java object as the credentials, which may lead to arbitrary code execution when the remote JVM deserializes it.

The Spring Boot application has DevTools enabled. DevTools include an additional set of tools which can make the application development experience a little more pleasant, but DevTools are not recommended to use on applications in a production environment. As stated in the official Spring Boot documentation: "Enabling spring-boot-devtools on a remote application is a security risk. You should never enable support on a production deployment."

The Shutdown Actuator allows authenticated users to shut down the application. Even though it is configured by default as a sensitive endpoint and therefore authentication is required to use this endpoint, it is not a good practice to enable it without a strong reason since credentials may be weak or the application configuration can be modified to flag the actuator as non-sensitive.

Example 1: A Spring Boot application is configured to deploy the shutdown Actuator:

endpoints.shutdown.enabled=true

Spring Security is configured with an overly permissive catch-all policy whereby a request that does not match any security expression is allowed access.

Example 1: The following code defines a Spring Security configuration that defaults to permit any unmatched requests:

	<http auto-config="true">
        ...
        <intercept-url pattern="/app/admin" access="ROLE_ADMIN" />
        <intercept-url pattern="/**" access="permitAll" />
	</http>

Even if this is currently a secure configuration, new private endpoints might be added to the application in the future. If developers forget to update the security policy, the default catch-all rule will allow public access to the new private endpoint.

Spring Security sets default security headers to help protect the application. The default security headers injected by Spring Security are:

Cache-Control: no-cache, no-store, max-age=0, must-revalidate
Pragma: no-cache
Expires: 0
X-Content-Type-Options: nosniff
Strict-Transport-Security: max-age=31536000 ; includeSubDomains
X-Frame-Options: DENY
X-XSS-Protection: 1; mode=block

These are reasonable headers that help protect the application. Do not disable these headers unless they are replaced by more restrictive values.

Example: The following code disables Spring Security default headers:

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

Spring Security borrowed Ant path expressions to specify how to protect endpoints.

Example 1: In the following example, any endpoint that matches the "/admin" Ant path expression requires administrator privileges for access:

	<http auto-config="true">
        ...
        <intercept-url pattern="/app/admin" access="ROLE_ADMIN" />
        ...
        <intercept-url pattern="/**" access="permitAll" />
	</http>

However, if the protected endpoint is a Spring MVC endpoint, an attacker can bypass this control by abusing Spring MVC content-negotiation features. With Spring MVC users can specify how they want the resource served by either using the Accept header or by specifying the desired content-type using an extension. For example, you can request the /admin resource as a JSON document by sending the request to /admin.json.
Ant path expressions do not account for content-negotiation extensions, and therefore, the request does not match the /admin expression and the endpoint is not protected.

Spring Security uses an expression-based access control that lets developers define a set of checks that must be applied to every request. To determine if the access control must be applied to the request, Spring Security attempts to match the request with the request matcher defined for every security check. If the request matches, the access control is applied to the request. A special request matcher exists to always match against any requests: anyRequest(). Failing to define a fallback check that uses the anyRequest() matcher, might leave endpoints unprotected.

Example 1: The following code defines a Spring Security configuration that fails to define a fallback check:

	<http auto-config="true">
        <intercept-url pattern="/app/admin" access="ROLE_ADMIN" />
        <intercept-url pattern="/" access="permitAll" />
	</http>

In Example 1 above, current or future endpoints such as /admin/panel might be left unprotected.

Spring Security includes an HTTP firewall that helps protect the application by sanitizing requests that contain potentially malicious characters. Spring achieves this by including the HttpFirewall into its FilterChainProxy, which processes the requests before they are sent through the filter chain. Sprint Security uses the StrictHttpFirewall implementation by default.


Example: The following code relaxes the firewall policy to allow %2F and ; characters:

    <beans:bean id="httpFirewall" class="org.springframework.security.web.firewall.StrictHttpFirewall" p:allowSemicolon="true" p:allowUrlEncodedSlash="true"/>

Allowing potentially malicious characters can lead to vulnerabilities if these characters are incorrectly on inconsistently processed. For example, allowing semicolons enable path parameters (as defined in RFC 2396) which are not consistently processed by frontend web servers such as nginx and application servers such as Apache Tomcat. These inconsistencies may be used for path traversal attacks or access control bypasses.

Single sign-on enables a service provider to use a single identity system across multiple applications without requiring that each application manage credential information separately. An identity provider verifies the user credentials and provides a token to the service provider to prove the user's validity. These tokens are the primary artifact the service provider uses to authenticate and authorize users into the service. These tokens are susceptible to replay attacks and can enable an attacker to impersonate a valid user and gain unauthorized access to the service. A network intruder with man-in-the-middle access or browser cache on a public kiosk could reveal this type of authentication token to malicious vectors. After attackers have access to a valid token, user credentials are not required, which could be secured with an additional two factor provision. Security Assertion Markup Language (SAML) tokens are a popular example of SSO tokens. A service provider can take several measures to prevent replay attacks for SAML tokens. These include setting a short token validity period and assigning a unique ID to each token request and response.

Programs deployed outside an enterprise's network infrastructure lose the internal guarantees of data transmission security. An attacker residing on a shared network may be able to snoop unencrypted traffic.

Attackers can target unauthenticated MongoDB servers to compromise the data stored in it and depending on the MongoDB version, to get a foothold on your internal network by compromising the server.

Different attacks can be used against a MongoDB server to get arbitrary code execution on its underlying operating system. For example, vulnerabilities existed in the past that allowed attackers to turn a server-side JavaScript injection into remote code execution. When used to store objects, an attacker can also store deserialization payloads for different languages such as Java, Python, Ruby, PHP, etc. in order to get remote code execution on the deserializing endpoint.

Please note that even if the MongoDB server is not exposed externally, an external attacker may still reach it or the REST API via a Server-Side Request Forgery vulnerability in any application on the same network. For example, MongoDB Servers can be attacked using HTTP or Gopher protocols.

Failure to protect the MongoDB port externally can have a large security impact. For example, an external attacker can use a single remove command to delete the whole data set. Recently, there have been reports of malicious attacks on unsecured instances of MongoDB running openly on the internet. The attacker erased the database and demanded a ransom be paid before restoring it.

Unauthenticated Redis servers may be targeted by attackers to get a foothold on your internal network by compromising the server.

Different attacks may be used against a Redis server to get arbitrary code execution on its underlying operating system. For example, an attacker may use Redis commands to write a web shell into the web root. When used to store objects, an attacker may also store deserialization payloads for different languages such as Java, Python, Ruby, PHP, etc. in order to get remote code execution on the deserializating endpoint.

Please note that even if the Redis server is not exposed externally, an external attacker may still reach it via a Server-Side Request Forgery vulnerability in any application on the same network. Redis Servers can be attacker using HTTP or Gopher protocols for example.

Failing to protect the Redis port from the outside can have a big security impact because of the nature of Redis. For instance, a single FLUSHALL command can be used by an external attacker to delete the whole data set. Recently, there have been reports of malicious attacks on unsecured instances of Redis running openly on the internet. The attacker erased the database and demanded a ransom be paid before restoring it.

If an application handles sensitive information and does not use message-level encryption, then it should only be allowed to communicate over an encrypted transport channel.

The program references a user-defined class that is not uniquely identified. When .NET loads this weakly identified class, the CLR type loader searches for the class in the following locations in the specified order:

- If the assembly of the type is known, the loader searches the configuration file's redirect locations, GAC, the current assembly using configuration information, and the application base directory.

- If the assembly is unknown, the loader searches the current assembly, mscorlib, and the location returned by the TypeResolve event handler.

This CLR search order can be modified with hooks such as the Type Forwarding mechanism and the AppDomain.TypeResolve event.

If an attacker exploits the CLR search order by creating an alternative class with the same name and placing it in an alternative location that the CLR will load first, the CLR will unintentionally execute the attacker-supplied code.

Example 1: The <behaviorExtensions/> element of the following WCF configuration file instructs WCF to add a custom behavior class to a particular WCF extension.

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name="myBehavior" type="MyBehavior" />
       </behaviorExtensions>
    </extensions>
</system.serviceModel>

MD2, MD4, MD5, RIPEMD-160, and SHA-1 are popular cryptographic hash algorithms often used to verify the integrity of messages and other data. However, as recent cryptanalysis research has revealed fundamental weaknesses in these algorithms, they should no longer be used within security-critical contexts.

Effective techniques for breaking MD and RIPEMD hashes are widely available, so those algorithms should not be relied upon for security. In the case of SHA-1, current techniques still require a significant amount of computational power and are more difficult to implement. However, attackers have found the Achilles' heel for the algorithm, and techniques for breaking it will likely lead to the discovery of even faster attacks.

It is never a good idea to use an empty salt. Not only does using an empty salt make it significantly easier to determine the hashed values, it also makes fixing the problem extremely difficult. After the code is in production, the salt cannot be easily changed. If attackers figure out that values are hashed with an empty salt, they can compute "rainbow tables" for the application and more easily determine the hashed values.
Example 1: The following code uses an empty salt:

...
private static final String salt = "";
...
PBEKeySpec pbeSpec=new PBEKeySpec(password);
SecretKeyFactory keyFact=SecretKeyFactory.getInstance(CIPHER_ALG);
PBEParameterSpec defParams=new PBEParameterSpec(salt,100000);
Cipher cipher=Cipher.getInstance(CIPHER_ALG);
cipher.init(cipherMode,keyFact.generateSecret(pbeSpec),defParams);
...

This code will run successfully, but anyone who has access to it will have access to the (empty) salt. After the program ships, there is likely no way to change the empty salt. An employee with access to this information can use it to break into the system.

It is never a good idea to use an empty salt. Not only does an empty salt defeat its own purpose but all of the project's developers can view the salt. It makes fixing the problem extremely difficult because after the code is in production, the salt cannot be easily changed. If attackers know the value of the salt, they can compute "rainbow tables" for the application and easily determine the hashed values.

Example 1: The following code defines an empty salt for password hashing:

...
define('SECURE_AUTH_SALT', "");
...

This code runs successfully, but anyone who has access to it can see the salt. After the program ships, there is likely no way to change the empty salt. An employee with access to this information can use it to break into the system.