The Access-Control-Allow-Methods header, as reflected in the preflight response for the requested resource, indicates that it allows unsafe HTTP methods. An attacker can use HTTP methods such as PUT or DELETE to make unexpected modifications to shared resource and pose a security threat to the overall site security. A user agent rejects any request for this resource with an HTTP method other than the ones that are listed in the Access-Control-Allow-Methods response header.
Cross-Origin Resource Sharing, commonly referred to as CORS, is a technology that allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain using cross domain XML HTTP Requests (XHR). Historically, the browser restricts cross domain XHR requests to abide by the same origin policy. At its basic form, the same origin policy sets the script execution scope to the resources available on the current domain and prohibits any communication to domains outside this scope. Therefore, execution and incorporation of remote methods and functions hosted on domains outside of the current domain are effectively prohibited. While CORS is supported on all major browsers, it also requires that the domain correctly defines the CORS policy in order to have its resources shared with another domain. These restrictions are managed by access policies typically included in specialized response headers, such as:

- Access-Control-Allow-Origin
- Access-Control-Allow-Headers
- Access-Control-Allow-Methods

Cross-Origin Resource Sharing, commonly referred to as CORS, is a technology that allows a domain to define a policy for its resources to be accessed by a web page hosted on a different domain using cross domain XML HTTP Requests (XHR). Historically, the browser restricts cross domain XHR requests to abide by the same origin policy. At its basic form, the same origin policy sets the script execution scope to the resources available on the current domain and prohibits any communication to domains outside this scope. Therefore, execution and incorporation of remote methods and functions hosted on domains outside of the current domain are effectively prohibited. While CORS is supported on all major browsers, it also requires that the domain correctly defines the CORS policy in order to have its resources shared with another domain. These restrictions are managed by access policies typically included in specialized response headers, such as:

- Access-Control-Allow-Origin
- Access-Control-Allow-Headers
- Access-Control-Allow-Methods
- Access-Control-Max-Age

The browser generates a preflight OPTIONS request whenever the cross domain request made by the web page is anything other than a simple HTTP request. A GET or POST HTTP request with no special headers or credentials is considered a simple request. A response for a preflight request exposes the server's CORS policy via specialized headers mentioned above. After examining the required permissions, the browser makes the actual request that the web page initially performed. This extra preflight request adds overhead and hence the server can configure its preflight response to be cached.
Prolonged caching of a preflight response can pose a security threat as the policy can be updated on the server while a browser will still allow unauthorized access to resources based on the original cached policy. The time a response is allowed to be cached is conveyed using an Access-Control-Max-Age response header and a value more than 30 minutes is considered to be prolonged.

A missing security-role for a role-name defined in an auth-constraint could indicate an out-of-date configuration.

Example 1: The following example specifies a role-name, but does not define it in a security-role.

<security-constraint>
    <web-resource-collection>
         <web-resource-name>AdminPage</web-resource-name>
         <description>Admin only pages</description>
         <url-pattern>/auth/noaccess/*</url-pattern>
    </web-resource-collection>

    <auth-constraint>
        <description>Administrators only</description>
        <role-name>admin</role-name>
    </auth-constraint>

    <user-data-constraint>
        <transport-guarantee>INTEGRAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

By default, a new Google Cloud project starts with a project-wide network. The default network is pre-populated with firewall rules that permit unrestricted communication among Compute Engine instances in the same project and expose security sensitive ports of all instances to the public. The affected ports include TCP 22 (SSH) and TCP 3389 (RDP). Any insufficiently protected instance is susceptible to unauthorized access.

Example 1: The following example Terraform configuration enables the auto-creation of a project-wide network by setting auto_create_network to true.

resource "google_project" "project-demo" {
...
  auto_create_network = true
...
}

Programmers sometimes allow the end users to specify the location of the application resources whose contents they are interested in. Such a feature can be exploited for malicious purposes if the application fails to validate the user-supplied input and apply appropriate filters to purge use of special characters in the input. A directory traversal vulnerability occurs when the attacker can influence the path to files whose contents are returned by the application.

An attacker can modify the value of such parameters to view files using the web server's access permissions. By sending a specially crafted request containing directory traversal characters, the attacker can gain access to sensitive file contents that would otherwise be inaccessible. To exploit the vulnerability the attacker can use parent directory references, such as "/../../"-style notation. This could lead to exposure of web application source code, usernames, passwords and other sensitive configuration information. Additionally, the attacker could also execute arbitrary system commands.

Example: A payload using special character to gain unauthorized system access and execute shell commands.

http://[target]/.../.../.../winnt/system32/cmd.exe?/c+dir

Spring enables developers to load Bean definitions from multiple resources including local files and remote URLs. If an attacker is able to control the contents of the Bean definition resource, they will be able to inject malicious Bean definitions which may execute arbitrary code upon their initialization.

Example: The following example loads a bean definition resource from a user-controlled location:

String beans = getBeanDefinitionFromUser();
GenericApplicationContext ctx = new GenericApplicationContext();
XmlBeanDefinitionReader xmlReader = new XmlBeanDefinitionReader(ctx);
xmlReader.loadBeanDefinitions(new UrlResource(beans));
ctx.refresh();

An application's authentication and authorization mechanisms can be bypassed with HTTP verb tampering when:
1) It uses a security control that lists HTTP verbs.
2) The security control fails to block verbs that are not listed.
3) The application updates its state based on GET requests or other arbitrary HTTP verbs.



Most Java EE implementations allow HTTP methods that are not explicitly listed in the configuration. For example the following security constraint is applied to the HTTP GET method but not to other HTTP verbs:

    <security-constraint>
        <display-name>Admin Constraint</display-name>
        <web-resource-collection>
            <web-resource-name>Admin Area</web-resource-name>
            <url-pattern>/pages/index.jsp</url-pattern>
            <url-pattern>/admin/*.do</url-pattern>
            <http-method>GET</http-method>
            <http-method>POST</http-method>
        </web-resource-collection>
        <auth-constraint>
            <description>only admin</description>
            <role-name>admin</role-name>
        </auth-constraint>
    </security-constraint>

Since verbs like HEAD are not explicitly defined in an <http-method> tag in this configuration, it might be possible to exercise administrative functionality by substituting GET or POST requests with HEAD requests. For HEAD requests to exercise administrative functionality, condition 3 must hold - the application must carry out commands based on verbs other than POST. Some web/application servers will accept arbitrary non-standard HTTP verbs and respond as if they were given a GET request. If that is the case, an attacker would be able to view administrative pages by using an arbitrary verb in a request.

For example, a typically client GET requests looks like:

GET /admin/viewUsers.do HTTP/1.1
Host: www.example.com

In an HTTP Verb Tampering attack, an attacker would substitute GET with something like FOO

FOO /admin/viewUsers.do HTTP/1.1
Host: www.example.com

At its core, this vulnerability is the result of an attempt to create a deny list--a policy that specifies what users are not allowed to do. Deny lists rarely achieve their intended effect.