An attacker can bypass URL based authentication schemes when
1. A system uses the canonical representation of URL to serve a resource but
2. The authorization mechanism used by the system performs authorization checks on the non-canonical form of the URL
Example:
If http://www.example.com/ProtectedDirectory/ProtectedFile.html is a protected resource and an attacker requests http://www.example.com/ProtectedDirectory/./ProtectedFile.html, he may be able to gain access to the resource if the authorization module explicitly matches against the URL http://www.example.com/ProtectedDirectory/ProtectedFile.html.

Sample applications are often included with default installation of servers, application frameworks and integrated development environments. These sample applications are created only for demonstration purposes and are not meant to be deployed on production servers alongside critical applications.

Vulnerabilities in sample applications could lead to the bypass of all the security controls implemented by the programmers in the custom application code. The lack of their conformance with access control restrictions could also expose sensitive system resources.

Sample applications can potentially suffer from several risks:
- Lack of proper file restrictions allowing attackers to read arbitrary files
- Exposing direct connections to backend database servers
- Disclosing valid session identifiers allowing attackers to
- Remote deletion of arbitrary files
- Arbitrary file uploads
- Disclosure of access control lists and user accounts
- Manipulation of Java processes
- Disclosure of absolute paths to installation directories, web roots
- Disclosure of system environment variables

Sample applications are also more susceptible to vulnerabilities like Cross-Site Scripting.

In order to protect access to various resources, web servers may be configured to prevent the usage of specific HTTP verbs. However, some web frameworks provide a way to override the HTTP verb by using HTTP request headers. This feature is typically used when a web or proxy server restricts certain verbs, but the application needs to use them, especially in RESTful services. However, it is possible for a malicious user to take advantage of this feature. Doing so may allow the attacker to perform unintended actions on protected resources in the web application.

The attack works by using a trusted HTTP verb such as GET or POST, but adds request headers such as X-HTTP-Method, X-HTTP-Method-Override, or X-Method-Override to provide a restricted verb such as PUT or DELETE. Doing so will force the request to be interpreted by the target application using the verb in the request header instead of the actual HTTP verb. In certain cases, the restricted verb may also be used in query or post parameters instead of a request header.

Path Manipulation may occur when the paths of resources included in an application are modified by changing the way they are imported. This can happen due to the following conditions:

- Usage of relative paths to import resources
- Ability to overwrite the relative path by manipulating the URL

In some cases, browsers using quirks mode may be required to exploit the underlying vulnerability (this may be triggered by using the HTML meta tag or an older doctype).

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

Sensitive Azure ARM template parameters, such as passwords, typically use the securestring or secureobject types.

For parameters that use a secure type, the parameter values are not logged or stored in the deployment history.

However, if a hardcoded default value is configured for a secure type, that default value is readable to anyone who can access the template or the deployment history.

Hard-coded secrets can compromise security in a way that is not easy to remedy. After the software is in production, an update is required to change the compromised secret.

In the case of a secret that is used to encrypt data, key-rotation steps must be administered to decrypt and re-encrypt all the data protected by the compromised key.

Example 1: The following template shows a parameter with a secret type that has a hardcoded default value.

{
    ...
    "parameters": {
        "rootPassword": {
            "defaultValue": "HardcodedPassword",
            "type": "secureString"
        },
        "adminLogin": {
            "type": "string"
        },
        "sqlServerName": {
            "type": "string"
        }
    },
    ...
}

Buffer overflow is probably the best known form of software security vulnerability. Most software developers know what a buffer overflow vulnerability is, but buffer overflow attacks against both legacy and newly-developed applications are still quite common. Part of the problem is due to the wide variety of ways buffer overflows can occur, and part is due to the error-prone techniques often used to prevent them.

In a classic buffer overflow exploit, the attacker sends data to a program, which it stores in an undersized stack buffer. The result is that information on the call stack is overwritten, including the function's return pointer. The data sets the value of the return pointer so that when the function returns, it transfers control to malicious code contained in the attacker's data.

Although this type of off-by-one error is still common on some platforms and in some development communities, there are a variety of other types of buffer overflow, including stack and heap buffer overflows among others. There are a number of excellent books that provide detailed information on how buffer overflow attacks work, including Building Secure Software [1], Writing Secure Code [2], and The Shellcoder's Handbook [3].

At the code level, buffer overflow vulnerabilities usually involve the violation of a programmer's assumptions. Many memory manipulation functions in C and C++ do not perform bounds checking and can easily exceed the allocated bounds of the buffers they operate upon. Even bounded functions, such as strncpy(), can cause vulnerabilities when used incorrectly. The combination of memory manipulation and mistaken assumptions about the size or makeup of a piece of data is the root cause of most buffer overflows.

Example: The following code contains an off-by-one buffer overflow, which occurs when recv returns the maximum allowed sizeof(buf) bytes read. In this case, the subsequent dereference of buf[nbytes] will write the null byte outside the bounds of allocated memory.

void receive(int socket) {
   char buf[MAX];
   int nbytes = recv(socket, buf, sizeof(buf), 0);
   buf[nbytes] = '\0';
   ...
}