Granting allUsers or allAuthenticatedUsers a Cloud KMS CryptoKey role gives anyone access to sensitive data.

By default, Azure Kubernetes Service (AKS) clusters created by Ansible do not send log events to Azure Monitor. This can allow malicious behavior to go undetected and prevent forensic analysis in the event of a breach.

Example 1: The following example Ansible task shows an AKS cluster that does not send log events to Azure Monitor.

- name: AKS Instance
  azure_rm_aks:
    name:
    resource_group: testResourceGroup
    location: eastus
    ...
    addon:
      monitoring:
        log_analytics_workspace_resource_id: logws001
        enabled: no

By default, Azure Kubernetes Service (AKS) clusters do not send log events to Azure Monitor. This can allow malicious behavior to go undetected and prevent forensic analysis in the event of a breach.

Example 1: The following example template shows an AKS cluster that does not send log events to Azure Monitor.

resource example 'Microsoft.ContainerService/managedClusters@2018-03-31' = {
    ...
    properties: {
        ...
        addonProfiles: {}
    }
}

Cross-site scripting (XSS) vulnerabilities occur when:

1. Data enters a web application through an untrusted source. In the case of self-XSS, data is read from a text box or other value that can be controlled from the DOM and written back into the page using client-side code.


2. The data is included in dynamic content that is sent to a web user without validation. In the case of self-XSS, malicious content is executed as part of DOM (Document Object Model) modification.

The malicious content in the case of self-XSS takes the form of a JavaScript segment, or any other type of code that the browser executes. As self-XSS is primarily an attack on oneself, it is often considered unimportant, but should be treated the same as a standard XSS weakness if one of the following can occur:

- A Cross-Site Request Forgery vulnerability is identified on your website.
- A social engineering attack can convince a user to attack their own account, compromising their session.
Example 1: Consider the HTML form:

  <div id="myDiv">
    Employee ID: <input type="text" id="eid"><br>
    ...
    <button>Show results</button>
  </div>
  <div id="resultsDiv">
    ...
  </div>
  

The following jQuery code segment reads an employee ID from the text box, and displays it to the user.

  $(document).ready(function(){
    $("#myDiv").on("click", "button", function(){
      var eid = $("#eid").val();
      $("resultsDiv").append(eid);
      ...
    });
  });
  

These code examples operate correctly if the employee ID from the text input with ID eid contains only standard alphanumeric text. If eid has a value that includes metacharacters or source code, then after the user clicks the button, the code is added to the DOM for the browser to execute. If an attacker can convince a user to input malicious input into the text input, then this is simply a DOM-based XSS.

It is never a good idea to use an empty HMAC key. The cryptographic strength of HMAC depends on the size of the secret key, which is used for the calculation and verification of the message authentication values. Using an empty key undermines the cryptographic strength of the HMAC function.
Example 1: The following code uses an empty key to compute the HMAC:

...
private static String hmacKey = "";
byte[] keyBytes = hmacKey.getBytes();
...
SecretKeySpec key = new SecretKeySpec(keyBytes, "SHA1");
Mac hmac = Mac.getInstance("HmacSHA1");
hmac.init(key);
...

The code in Example 1 may run successfully, but anyone who has access to it will be able to figure out that it uses an empty HMAC key. After the program ships, there is likely no way to change the empty HMAC key unless the program is patched. A devious employee with access to this information could use it to compromise the HMAC function. Also, the code in Example 1 is vulnerable to forgery and key recovery attacks.

By default, a Kubernetes API server does not authenticate itself to Kubelets when submitting requests. Kubelets, that provide access to a wide variety of resources, cannot verify the authenticity of these requests.

Example 1: The following command starts a Kubernetes API server without specifying a client certificate and the corresponding private key with the --kubelet-client-certificate flag and the --kubelet-client-key flag respectively to enable certificate-based authentication to Kubelets.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --audit-log-maxage=50
    - --audit-log-maxbackup=20
    - --audit-log-maxsize=200
    image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
    ...

Content Security Policy (CSP) is a declarative security header that allows developers to dictate which domains the site is allowed to load content from or initiate connections to when rendered in the web browser. It provides an additional layer of security from critical vulnerabilities such as cross-site scripting, clickjacking, cross-origin access and the like, on top of input validation and checking an allow list in code. An improperly configured header, however, fails to provide this additional layer of security. The policy is defined with the help of fifteen directives including eight that control resource access, namely: script-src, img-src, object-src, style_src, font-src, media-src, frame-src, connect-src.

Each of these takes a source list as a value specifying domains the site is allowed to access for a feature covered by that directive. Developers may use wildcard * to indicate all or part of the source. None of the directives are mandatory. Browsers will either allow all sources for an unlisted directive or will derive its value from the optional default-src directive. Furthermore, the specification for this header has evolved over time. It was implemented as X-Content-Security-Policy in Firefox until version 23 and in IE until version 10, and was implemented as X-Webkit-CSP in Chrome until version 25. Both of the names are deprecated in favor of the now standard name Content Security Policy. Given the number of directives, two deprecated alternate names, and the way multiple occurrences of the same header and repeated directives in a single header are treated, there is a high probability that a developer might misconfigure this header.

Consider the following misconfiguration scenarios:

- Directives with unsafe-inline or unsafe-eval defeats the purpose of CSP.
- script-src directive is set but no script nonce is configured.
- frame-src is set but no sandbox is configured.
- Multiple instances of this header are allowed in same response. A development team and security team might both set a header but one may use one of the deprecated names. While deprecated headers are honored if a header with the latest name (that is, Content Security Policy) is not present, they are ignored if a policy with content-security-header name is present. Older versions only understand deprecated names, hence, in order to achieve desired support it is essential that the response include an identical policy with all three names.
- If a directive is repeated within the same instance of the header, all subsequent occurrences are ignored.

Example 1: The following django-csp configuration uses unsafe-inline and unsafe-eval insecure directives to allow inline scripts and code evaluation:

...
MIDDLEWARE = (
    ...
    'csp.middleware.CSPMiddleware',
    ...
)
...
CSP_DEFAULT_SRC = ("'self'", "'unsafe-inline'", "'unsafe-eval'", 'cdn.example.net')
...

In Java, finally blocks are always executed after their corresponding try-catch blocks and are often used to free allocated resources, such as file handles or database cursors. Throwing an exception in a finally block can bypass critical cleanup code since normal program execution will be disrupted.

Example 1: In the following code, the call to stmt.close() is bypassed when the FileNotFoundException is thrown.

public void processTransaction(Connection conn) throws FileNotFoundException
{
    FileInputStream fis = null;
    Statement stmt = null;
    try
    {
        stmt = conn.createStatement();
        fis = new FileInputStream("badFile.txt");
        ...
    }
    catch (FileNotFoundException fe)
    {
        log("File not found.");
    }
    catch (SQLException se)
    {
        //handle error
    }
    finally
    {
        if (fis == null)
        {
            throw new FileNotFoundException();
        }

        if (stmt != null)
        {
            try
            {
                stmt.close();
            }
            catch (SQLException e)
            {
                log(e);
            }
        }
    }
}

A Kubernetes API server sends instructions to Kubelets to create workload, queries status of Kubelet-managed resources, and provides optional port-forwarding services to Kubelets. By default, the API server does not verify a Kubelet's serving certificate before establishing connection. This connection is therefore susceptible to a man-in-the-middle attack.

Example 1: The following command starts a Kubernetes API server without specifying a root certificate bundle to verify the Kubelet's serving certificate with the --kubelet-certificate-authority flag.

...
spec:
  containers:
  - command:
    - kube-apiserver
    - --audit-log-maxage=50
    - --audit-log-maxbackup=20
    - --audit-log-maxsize=200
  image: gcr.io/google_containers/kube-apiserver-amd64:v1.6.0
    ...

If you are using Blaze DS to perform logging of any unexpected events, the services-config.xml descriptor file specifies a "Logging" XML element to describe various aspects of logging. It looks like the following:

Example 1:

<logging>
    <target class="flex.messaging.log.ConsoleTarget" level="Debug">
        <properties>
            <prefix>[BlazeDS]</prefix>
            <includeDate>false</includeDate>
            <includeTime>false</includeTime>
            <includeLevel>false</includeLevel>
            <includeCategory>false</includeCategory>
        </properties>
        <filters>
            <pattern>Endpoint.*</pattern>
            <pattern>Service.*</pattern>
            <pattern>Configuration</pattern>
        </filters>
    </target>
</logging>

This target tag takes an optional attribute called level, which indicates the log level. If the debug level is set to too detailed a level, your application may write sensitive data to the log file.

Secure password management is essential to prevent attackers from gaining access to sensitive resources or abusing the application functionality. Lack of proper protection can leak account information including the passwords, which could severely compromise the application.

Example 1: Transmitting passwords as part of query parameters can expose them to any attacker monitoring the traffic between the client and the server.

http://www.example.com/sws/manager.pl?add&pass=PassWord

Any information passed as part of the URL can be written to the server logs, usually in plaintext format. If an attacker gains access to the log files, any passwords transmitted through the URL are exposed.

Exposure to parameter tampering attacks result from improper validation of characters accepted by the application. Whenever a parameter is passed into a dynamically generated web page, it must be assumed that the data is incorrectly formatted. Insufficient validation of parameters can enable attackers to severely compromise the application resources as well its operation. The following forms of input when processed without proper validation can lead to disclosure of sensitive information or expose the application to arbitrary command execution.

Query String: Web applications often use query strings as a simple method of passing data from the client and the server. Query strings are a way to add data calls to a hyperlink, and then retrieve that information on the linked page when it is displayed. By manipulating query strings, an attacker can easily steal information from a database, learn details about the architecture of your web application, or possibly execute commands on your web server.

Post data: Because manipulating a query string is as easy as typing text in the address bar of a browser, many web applications rely on the POST method coupled with the use of forms rather than GET to pass data between pages. Even if the POST data is not directly visible in the browser, failure to cleanse the information received through the POST parameters can enable an attacker to conduct the same attacks as done with the QUERY parameters.

Headers: Both HTTP requests and responses use headers to deliver information about the HTTP message. Validate all HTTP headers because headers such as the "referrer" or "user-agent" are often logged to a database for traffic statistics. Failure to validate this information can enable attackers to inject malicious data into the logs and execute arbitrary commands.

Cookies: Many web applications use cookies to save information (for example, user ID's and timestamps) on the client's machine. By tampering with these values, or poisoning the cookie, malicious users can gain access to the accounts and information of other users. Furthermore, attackers can also steal a user's cookie and gain direct access to the user's account and bypass authentication.

Cookie Manipulation vulnerabilities occur when:

1. Data enters a web application through an untrusted source, most frequently an HTTP request.

2. The data is included in an HTTP cookie sent to a web user without being validated.

As with many software security vulnerabilities, cookie manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP cookie.

Cookie Manipulation: When combined with attacks like Cross-Site Request Forgery, attackers may change, add to, or even overwrite a legitimate user's cookies.

Being an HTTP Response header, cookie manipulation attacks can also lead to other types of attacks like:

HTTP Response Splitting:
One of the most common Header Manipulation attacks is HTTP Response Splitting. To mount a successful HTTP Response Splitting exploit, the application must allow input that contains CR (carriage return, also given by %0d or \r) and LF (line feed, also given by %0a or \n)characters into the header. These characters not only give attackers control of the remaining headers and body of the response the application intends to send, but also allows them to create additional responses entirely under their control.

Many of today's modern application servers will prevent the injection of malicious characters into HTTP headers. For example, recent versions of Apache Tomcat will throw an IllegalArgumentException if you attempt to set a header with prohibited characters. If your application server prevents setting headers with new line characters, then your application is not vulnerable to HTTP Response Splitting. However, solely filtering for new line characters can leave an application vulnerable to Cookie Manipulation or Open Redirects, so care must still be taken when setting HTTP headers with user input.

Example 1: The following code segment reads the name of the author of a weblog entry, author, from an HTTP request and sets it in a cookie header of an HTTP response.

String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
     cookie.setMaxAge(cookieExpiration);
     response.addCookie(cookie);

Assuming a string consisting of standard alphanumeric characters, such as "Jane Smith", is submitted in the request the HTTP response including this cookie might take the following form:

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

However, because the value of the cookie is formed of unvalidated user input the response will only maintain this form if the value submitted for AUTHOR_PARAM does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", then the HTTP response would be split into two responses of the following form:

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

Clearly, the second response is completely controlled by the attacker and can be constructed with any header and body content desired. The ability of attacker to construct arbitrary HTTP responses permits a variety of resulting attacks, including: cross-user defacement, web and browser cache poisoning, cross-site scripting, and page hijacking.

Some think that in the mobile world, classic web application vulnerabilities, such as header and cookie manipulation, do not make sense -- why would the user attack themself? However, keep in mind that the essence of mobile platforms is applications that are downloaded from various sources and run alongside each other on the same device. The likelihood of running a piece of malware next to a banking application is high, which necessitates expanding the attack surface of mobile applications to include inter-process communication.

Example 2: The following code adapts Example 1 to the Android platform.

...
	CookieManager webCookieManager = CookieManager.getInstance();
        String author = this.getIntent().getExtras().getString(AUTHOR_PARAM);
	String setCookie = "author=" + author + "; max-age=" + cookieExpiration;
        webCookieManager.setCookie(url, setCookie);

...

Cross-User Defacement: An attacker will be able to make a single request to a vulnerable server that will cause the server to create two responses, the second of which may be misinterpreted as a response to a different request, possibly one made by another user sharing the same TCP connection with the server. This can be accomplished by convincing the user to submit the malicious request themselves, or remotely in situations where the attacker and the user share a common TCP connection to the server, such as a shared proxy server. In the best case, an attacker may leverage this ability to convince users that the application has been hacked, causing users to lose confidence in the security of the application. In the worst case, an attacker may provide specially crafted content designed to mimic the behavior of the application but redirect private information, such as account numbers and passwords, back to the attacker.

Cache Poisoning: The impact of a maliciously constructed response can be magnified if it is cached either by a web cache used by multiple users or even the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, then that user will continue to receive the malicious content until the cache entry is purged, although only the user of the local browser instance will be affected.

Cross-Site Scripting: Once attackers have control of the responses sent by an application, they have a choice of a variety of malicious content to provide users. Cross-site scripting is common form of attack where malicious JavaScript or other code included in a response is executed in the user's browser. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site. The most common and dangerous attack vector against users of a vulnerable application uses JavaScript to transmit session and authentication information back to the attacker who can then take complete control of the victim's account.

Page Hijacking: In addition to using a vulnerable application to send malicious content to a user, the same root vulnerability can also be leveraged to redirect sensitive content generated by the server and intended for the user to the attacker instead. By submitting a request that results in two responses, the intended response from the server and the response generated by the attacker, an attacker may cause an intermediate node, such as a shared proxy server, to misdirect a response generated by the server for the user to the attacker. Because the request made by the attacker generates two responses, the first is interpreted as a response to the attacker's request, while the second remains in limbo. When the user makes a legitimate request through the same TCP connection, the attacker's request is already waiting and is interpreted as a response to the victim's request. The attacker then sends a second request to the server, to which the proxy server responds with the server generated request intended for the victim, thereby compromising any sensitive information in the headers or body of the response intended for the victim.

Open Redirect: Allowing unvalidated input to control the URL used in a redirect can aid phishing attacks.

Format string vulnerabilities occur when:

1. Data enters the application from an untrusted source.



2. The data is passed as the format string argument to a function like sprintf(), FormatMessageW(), or syslog().
Example 1: The following code copies a command line argument into a buffer using snprintf().

int main(int argc, char **argv){
	char buf[128];
	...
	snprintf(buf,128,argv[1]);
}

This code allows an attacker to view the contents of the stack and write to the stack using a command line argument containing a sequence of formatting directives. The attacker may read from the stack by providing more formatting directives, such as %x, than the function takes as arguments to be formatted. (In this example, the function takes no arguments to be formatted.) By using the %n formatting directive, the attacker may write to the stack, causing snprintf() to write the number of bytes output thus far to the specified argument (rather than reading a value from the argument, which is the intended behavior). A sophisticated version of this attack will use four staggered writes to completely control the value of a pointer on the stack.

Example 2: Certain implementations make more advanced attacks even easier by providing format directives that control the location in memory to read from or write to. An example of these directives is shown in the following code, written for glibc:

	printf("%d %d %1$d %1$d\n", 5, 9);

This code produces the following output:

5 9 5 5

It is also possible to use half-writes (%hn) to accurately control arbitrary DWORDS in memory, which greatly reduces the complexity needed to execute an attack that would otherwise require four staggered writes, such as the one mentioned in Example 1.

Example 3: Simple format string vulnerabilities often result from seemingly innocuous shortcuts. The use of some such shortcuts is so ingrained that programmers might not even realize that the function they are using expects a format string argument.

For example, the syslog() function is sometimes used as follows:

	...
	syslog(LOG_ERR, cmdBuf);
	...

Because the second parameter to syslog() is a format string, any formatting directives included in cmdBuf are interpreted as described in Example 1.

The following code shows a correct usage of syslog():

	...
	syslog(LOG_ERR, "%s", cmdBuf);
	...

Keyboard extensions are allowed to read every single keystroke that a user enters. Third-party keyboards are normally used to ease the text input or to add additional emojis and they may log what the user enters or even send it to a remote server for processing. Malicious keyboards can also be distributed to act as a keylogger and read every key entered by the user in order to steal sensitive data such as credentials or credit card numbers.

Header Manipulation vulnerabilities occur when:

1. Data enters a web application through an untrusted source, most frequently an HTTP request.

2. The data is included in an HTTP response header sent to a web user without being validated.

As with many software security vulnerabilities, Header Manipulation is a means to an end, not an end in itself. At its root, the vulnerability is straightforward: an attacker passes malicious data to a vulnerable application, and the application includes the data in an HTTP response header.

One of the most common Header Manipulation attacks is HTTP Response Splitting. To mount a successful HTTP Response Splitting exploit, the application must allow input that contains CR (carriage return, also given by %0d or \r) and LF (line feed, also given by %0a or \n)characters into the header. These characters not only give attackers control of the remaining headers and body of the response the application intends to send, but also allows them to create additional responses entirely under their control.

Many of today's modern application servers will prevent the injection of malicious characters into HTTP headers. For example, recent versions of Apache Tomcat will throw an IllegalArgumentException if you attempt to set a header with prohibited characters. If your application server prevents setting headers with new line characters, then your application is not vulnerable to HTTP Response Splitting. However, solely filtering for new line characters can leave an application vulnerable to Cookie Manipulation or Open Redirects, so care must still be taken when setting HTTP headers with user input.

Example 1: The following code segment reads the name of the author of a weblog entry, author, from an HTTP request and sets it in a cookie header of an HTTP response.

String author = request.getParameter(AUTHOR_PARAM);
...
Cookie cookie = new Cookie("author", author);
     cookie.setMaxAge(cookieExpiration);
     response.addCookie(cookie);

Assuming a string consisting of standard alphanumeric characters, such as "Jane Smith", is submitted in the request the HTTP response including this cookie might take the following form:

HTTP/1.1 200 OK
...
Set-Cookie: author=Jane Smith
...

However, because the value of the cookie is formed of unvalidated user input the response will only maintain this form if the value submitted for AUTHOR_PARAM does not contain any CR and LF characters. If an attacker submits a malicious string, such as "Wiley Hacker\r\nHTTP/1.1 200 OK\r\n...", then the HTTP response would be split into two responses of the following form:

HTTP/1.1 200 OK
...
Set-Cookie: author=Wiley Hacker

HTTP/1.1 200 OK
...

Clearly, the second response is completely controlled by the attacker and can be constructed with any header and body content desired. The ability of attacker to construct arbitrary HTTP responses permits a variety of resulting attacks, including: cross-user defacement, web and browser cache poisoning, cross-site scripting, and page hijacking.

Cross-User Defacement: An attacker will be able to make a single request to a vulnerable server that will cause the server to create two responses, the second of which may be misinterpreted as a response to a different request, possibly one made by another user sharing the same TCP connection with the server. This can be accomplished by convincing the user to submit the malicious request themselves, or remotely in situations where the attacker and the user share a common TCP connection to the server, such as a shared proxy server. In the best case, an attacker may leverage this ability to convince users that the application has been hacked, causing users to lose confidence in the security of the application. In the worst case, an attacker may provide specially crafted content designed to mimic the behavior of the application but redirect private information, such as account numbers and passwords, back to the attacker.

Cache Poisoning: The impact of a maliciously constructed response can be magnified if it is cached either by a web cache used by multiple users or even the browser cache of a single user. If a response is cached in a shared web cache, such as those commonly found in proxy servers, then all users of that cache will continue receive the malicious content until the cache entry is purged. Similarly, if the response is cached in the browser of an individual user, then that user will continue to receive the malicious content until the cache entry is purged, although only the user of the local browser instance will be affected.

Cross-Site Scripting: Once attackers have control of the responses sent by an application, they have a choice of a variety of malicious content to provide users. Cross-site scripting is common form of attack where malicious JavaScript or other code included in a response is executed in the user's browser. The variety of attacks based on XSS is almost limitless, but they commonly include transmitting private data such as cookies or other session information to the attacker, redirecting the victim to web content controlled by the attacker, or performing other malicious operations on the user's machine under the guise of the vulnerable site. The most common and dangerous attack vector against users of a vulnerable application uses JavaScript to transmit session and authentication information back to the attacker who can then take complete control of the victim's account.

Page Hijacking: In addition to using a vulnerable application to send malicious content to a user, the same root vulnerability can also be leveraged to redirect sensitive content generated by the server and intended for the user to the attacker instead. By submitting a request that results in two responses, the intended response from the server and the response generated by the attacker, an attacker may cause an intermediate node, such as a shared proxy server, to misdirect a response generated by the server for the user to the attacker. Because the request made by the attacker generates two responses, the first is interpreted as a response to the attacker's request, while the second remains in limbo. When the user makes a legitimate request through the same TCP connection, the attacker's request is already waiting and is interpreted as a response to the victim's request. The attacker then sends a second request to the server, to which the proxy server responds with the server generated request intended for the victim, thereby compromising any sensitive information in the headers or body of the response intended for the victim.

Cookie Manipulation: When combined with attacks like Cross-Site Request Forgery, attackers may change, add to, or even overwrite a legitimate user's cookies.

Open Redirect: Allowing unvalidated input to control the URL used in a redirect can aid phishing attacks.