File permission manipulation errors occur when any of the following conditions are met:

1. An attacker is able to specify a path used in an operation that modifies permissions on the file system.

2. An attacker is able to specify the permissions assigned by an operation on the file system.

Example 1: The following code uses input from system properties to set the default permission mask. If attackers can alter the system properties, they may use the program to gain access to files manipulated by the program. If the program is also vulnerable to path manipulation, an attacker may use this vulnerability to access arbitrary files on system.

  String permissionMask = System.getProperty("defaultFileMask");
  Path filePath = userFile.toPath();
  ...
  Set<PosixFilePermission> perms = PosixFilePermissions.fromString(permissionMask);
  Files.setPosixFilePermissions(filePath, perms);
...

The misconception that any information stored in the binary SWF files is safe from unauthorized access often leads to programmers embedding sensitive information like passwords, cryptographic data, and sensitive business logic in them. Attackers can easily decompile binary SWF files and steal the sensitive information. This might lead to a compromise the system.
Example:

 if (password eq '783-1') {
    getURL('http://.../client_pages/.../783.html', '');
} 
else {
    if (password eq '771-2 Update') {
        getURL('http://.../client_pages/.../771.html', '');
    } 
    else {
        if (password eq '7990') {
            getURL('http://.../client_pages/.../799.html', '');
        }
}

By decompiling the binary SWF, an attacker can not only gain access to the passwords but also to locations of unexposed URLs.

When a Flash application is embedded within HTML, there are several flags that inform the Flash player if the SWF file can have access to content from the browser or from the network.
- AllowScriptAccess
This flag tells the Flash player to allow the SWF to communicate with the browser and HTML DOM using ExternalInterface, fscommand or getURL.
- AllowNetworkingAccess
This flag informs the Flash player that it is allowed to make networking calls like XML.load, loadVariables, LoadVars.load etc. If a Flash application should not communicate with the browser or needs to make any networking calls, the AllowNetworkingAccess tag must be set to "none".
1. If a Flash application should not communicate with the browser or needs to make any networking calls, the AllowNetworkingAccess tag must be set to "none".
2. If a Flash application should not communicate with the browser but needs to make networking calls, the AllowNetworkingAccess tag should be set to "internal".
3. If a Flash application needs to communicate with both the browser and the network, the AllowNetworkingAccess tag must be set to "all".

The stage size set in this Flash application must meet the minimum stage requirements as defined by Adobe. Flash security best practices dictate that all Flash objects have a minimum stage of 215 pixels wide and at least 138 pixels high so that Flash Player messages from shared objects, microphone, camera, and other components can be displayed fully to the user.
To protect against clickjacking and spoofing attacks, Flash Player requires the area of the stage that displays the dialog box be visible with the default window mode set.

The use of ENABLEDEBUGGER and ENABLEDEBUGGER2 enables support for remote debugging and also contains a poorly salted MD5 password hash. The tag does not offer any security guarantees and can be easily circumvented by using any hex editor tool. Not only is the remote debugging protection easily bypassed, the password the developer used to secure the file is easily recoverable. Flash uses a 16-bit salt added to the password and applies the MD5 hash algorithm to it. This is a weak salt and the password can be recovered using password cracking programs.

By default, Flash applications are subject to the Same Origin Policy which ensures that two SWF applications can access each other's data only if they come from the same domain. Adobe Flash allows developers to alter the policy either programmatically or via appropriate settings in the crossdomain.xml configuration file. However, caution should be taken when changing the settings because an overly permissive cross-domain policy will allow a malicious application to communicate with the victim application in an inappropriate way, leading to spoofing, data theft, relay, and other attacks.

Example 1: The following excerpt is an example of using a wildcard to programmatically specify to which domains the application is allowed to communicate.

   flash.system.Security.allowDomain("*");

Using the * as the argument to allowDomain() indicates that the application's data is accessible to other SWF applications from any domain.

By default, Flash applications are subject to the Same Origin Policy which ensures that two SWF applications can access each other's data only if they come from the same domain. Adobe Flash allows developers to alter the policy either programmatically or via appropriate settings in the crossdomain.xml configuration file. Starting with Flash Player 9,0,124,0, Adobe also introduced the capability to define which custom headers Flash Player can send across domains. However, caution should be taken when defining these settings because an overly permissive custom headers policy, when applied together with the overly permissive cross-domain policy, will allow a malicious application to send headers of their choosing to the target application, potentially leading to a variety of attacks or causing errors in the execution of the application that does not know how to handle received headers.

Example 1: The following configuration shows the use of a wildcard to specify which headers Flash Player can send across domains.

  <cross-domain-policy>
    <allow-http-request-headers-from domain="*" headers="*"/>
  </cross-domain-policy>

Using the * as the value of the headers attribute indicates that any header will be sent across domains.

By default, Flash applications are subject to the Same Origin Policy which ensures that two SWF applications can access each other's data only if they come from the same domain. Adobe Flash allows developers to alter the policy either programmatically or via appropriate settings in the crossdomain.xml configuration file. However, caution should be taken when deciding who can influence the settings because an overly permissive cross-domain policy will allow a malicious application to communicate with the victim application in an inappropriate way, leading to spoofing, data theft, relay, and other attacks. Policy restrictions bypass vulnerabilities occur when:

1. Data enters an application from an untrusted source.

2. The data is used to load or modify cross-domain policy settings.
Example 1: The following code uses the value of one of the parameters to the loaded SWF file as the URL to load the cross-domain policy file from.

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var url:String = String(params["url"]);
   flash.system.Security.loadPolicyFile(url);
   ...

Example 2: The following code uses the value of one of the parameters to the loaded SWF file to define the list of trusted domains.

   ...
   var params:Object = LoaderInfo(this.root.loaderInfo).parameters;
   var domain:String = String(params["domain"]);
   flash.system.Security.allowDomain(domain);
   ...

As a convenient debugging option, certain Flex authoring tools allow developers to export Flex projects with the source code files for the project. Failure to disable this access for production files could severely compromise the security of the application. It allows any end user to view the source of the Flex application by right-clicking the running SWF inside the browser and selecting view source. This results in a source disclosure vulnerability. It is recommended that this feature be turned off to avoid unintended access to the source code.

Source code often contains database usernames, passwords and connection strings, and locations of sensitive files. It also reveals the detailed mechanics and design of the application's logic, which can be used to develop other attacks.

Starting with Flash Player 7, SWF applications loaded over HTTP are not allowed to access data of SWF applications loaded over HTTPS by default. Adobe Flash allows developers to alter this restriction either programmatically or via appropriate settings in the crossdomain.xml configuration file. However, caution should be taken when defining these settings because HTTP loaded SWF applications are subject to man-in-the-middle attacks, and thus should not be trusted.

Example: The following code calls allowInsecureDomain(), which turns off the restriction that prevents HTTP loaded SWF applications from accessing the data of HTTPS loaded SWF applications.

   flash.system.Security.allowInsecureDomain("*");

Adobe Flash has been associated with multiple vulnerabilities since its inception. Many of which can lead to Remote Code Execution and Cross-Site Scripting attacks that can compromise user and/or system data and privacy.

Adobe has deprecated Flash with an end-of-life set to the end of 2020. Many browsers have already disabled Adobe Flash support by default, for example, starting in Chrome 76 and Firefox 69. Furthermore, starting in December 2020, Chrome, Firefox, and Microsoft Edge will completely eliminate support for Flash.
Using a deprecated, possibly vulnerable version of the player to execute an application introduces unnecessary risk. Consider updating your application to replace Adobe Flash with safer, alternative technologies that provide similar functionality such as HTML5, WebGL, and WebAssembly. Use of safe alternative technologies is critical to protect users from known player vulnerabilities including Cross-Site Scripting, and Remote Code Execution (on the client machine).

Hadoop cluster control errors occur when:

- Data enters a program from an untrusted source.

- The data is consumed by Hadoop cluster core components such as NameNode, DataNode, JobTraker to change the state of the cluster.

Hadoop clusters are a hostile environment. When security configurations from protecting unauthorized access to cluster nodes are not set properly, an attack may be able to take control the infrastructure. This leads to the possibility that any data that is provided by the Hadoop cluster to be tampered.

Example 1: The following code shows a Job submission in a typical client application which takes inputs from command line on Hadoop cluster master machine:

  public static void run(String args[]) throws IOException {

    String path = "/path/to/a/file";
    DFSclient client = new DFSClient(arg[1], new Configuration());
    ClientProtocol nNode = client.getNameNode();

    /* This sets the ownership of a file pointed by the path to a user identified
     * by command line arguments.
     */
    nNode.setOwner(path, args[2], args[3]);
    ...
  }

Including executable content from another web site is a risky proposition. It ties the security of your site to the security of the other site.

Example: Consider the following script tag.

  <script src="http://www.example.com/js/fancyWidget.js"></script>

If this tag appears on a web site other than www.example.com, then the site is dependent upon www.example.com to serve up correct and non-malicious code. If attackers can compromise www.example.com, then they can alter the contents of fancyWidget.js to subvert the security of the site. They could, for example, add code to fancyWidget.js to steal a user's confidential data.

Heap inspection vulnerabilities occur when sensitive data, such as a password or an encryption key, can be exposed to an attacker because they are not removed from memory.

The realloc() function is commonly used to increase the size of a block of allocated memory. This operation often requires copying the contents of the old memory block into a new and larger block. This operation leaves the contents of the original block intact but inaccessible to the program, preventing the program from being able to scrub sensitive data from memory. If an attacker can later examine the contents of a memory dump, the sensitive data could be exposed.

Example: The following code calls realloc() on a buffer containing sensitive data:

plaintext_buffer = get_secret();
...
plaintext_buffer = realloc(plaintext_buffer, 1024);
...
scrub_memory(plaintext_buffer, 1024);

There is an attempt to scrub the sensitive data from memory, but realloc() is used, so a copy of the data can still be exposed in the memory originally allocated for plaintext_buffer.

Heap inspection vulnerabilities occur when sensitive data, such as a password or an encryption key, can be exposed to an attacker because they are not removed from memory.

The VirtualLock function is intended to lock pages in memory to prevent them from being paged to disk. However, on Windows 95/98/ME the function is implemented as stub only and has no effect.

Programmers often trust the contents of hidden fields, expecting that users will not be able to view them or manipulate their contents. Attackers will violate these assumptions. They will examine the values written to hidden fields and alter them or replace the contents with attack data.

Example:

  Hidden hidden = new Hidden(element);

If hidden fields carry sensitive information, this information will be cached the same way the rest of the page is cached. This can lead to sensitive information being tucked away in the browser cache without the user's knowledge.

Cross-Origin Resource Sharing (CORS) 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 browsers restricted XHR requests to abide by the same origin policy. This policy sets the script execution scope to the resources available on the current domain and prohibits any communication to domains outside this scope. However, a few HTML tags, such as SCRIPT, IMG, and IFRAME, are exempt from the same origin policy and allow remote content to be loaded from a different domain. These are secure alternatives for the site that load content from remote domains and require no special permission or cross-domain policy from the hosting domain.
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 communicated in specialized response headers, such as:

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

However, caution should be taken when defining these headers because an overly permissive policy configured at the server level for a domain or directory on a domain can open more content for cross domain access than intended. CORS can allow a malicious application to communicate with victim applications, which can lead to information disclosure, spoofing, data theft, relay, or other attacks.
Implementing CORS can increase an application's attack surface and should be used only when necessary.

Cross-Origin Resource Sharing (CORS), 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 previously. 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 of more than 30 minutes is considered to be prolonged.

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 a 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 (CORS), 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

The X-XSS-Protection header is typically enabled by default in modern browsers. When the header value is set to false (0), cross-site scripting protection is disabled.

The header can be set in multiple locations and should be checked for both misconfiguration as well as malicious tampering.

Example: The following code configures a Spring Security protected application to disable XSS protection:

	<http auto-config="true">
        ...
        <headers>
            ...
            <xss-protection xss-protection-enabled="false" />
        </headers>
	</http>