Insufficient Cross-Domain Configuration

Insufficient Cross-Domain Configuration refers to the cross-domain policy file (crossdomain.xml) that grants a web client – such as Adobe Flash Player, Adobe Reader, etc. – permission to handle data across multiple domains. 

When a client hosts content from a particular source domain and that content makes requests directed towards a domain other than its own, the remote domain will need to host a cross-domain policy file that grants access to the source domain, allowing the client to continue with the transaction. Policy files grant read access to data, permit a client to include custom headers in cross-domain requests, and are also used with sockets to grant permissions for socket-based connections. 

Insufficient Cross-Domain Configuration reflects a poorly configured Flash or Adobe application that can be compromised to allow an attacker inappropriate access to all of the resources allowed in the Cross-Domain Configuration file. 

As the Acrobat family of products became more powerful over the years (i.e. support for JavaScript and web service interaction), the line between document and application gradually blurred. With the addition of interactive form features, multimedia, and scripting, PDFs became more capable with each release. On the one hand, support for JavaScript and dynamic content within a Web page allows developers to add rich interactivity and behaviours to their content. Yet these features can be abused by attackers, and default configurations for clients that support them make such attacks even more dangerous.

One of the earliest attempts to combat such attacks was Netscape’s same-origin policy introduced with Netscape Navigator 2.0. The policy prevented a document or script loaded from one origin from accessing resources loaded from another origin. To counter the same-origin policy, a wide variety of attack patterns evolved, including cross-site scripting (XSS) and cross-site request forgery (XSRF). These attack patterns have one thing in common: they exploit the trust shared between a user and a website by circumventing its primary protection mechanism (the same-origin policy).

The Same-Origin Policy (SOP) restricted information sharing between applications and allowed sharing only within the domain the application was hosted on. This was a precaution to protect systems from giving up confidential information. But, with the growing usage of web-applications and microservices, there is a need to pass information from one subdomain to another, or between different domains for practicality purposes. This need might be for rendering purposes or for crucial functionality such as passing access tokens and session identifiers to another application.

With SOP in place, in order to allow cross-domain communication, developers had to use different techniques to bypass SOP and pass sensitive information. The ‘by-passing’ happened too much to a point that it became a security issue. So, in order to enable information sharing without compromising the security posture of applications, the Cross-Origin Resource Sharing (CORS) was introduced in HTML5.

What is CORS?

Cross-Origin Resource Sharing (CORS) is a mechanism that enables web browsers to perform cross-domain requests using the XMLHttpRequest API in a controlled manner. These cross-origin requests have an Origin header, that identifies the domain initiating the request. It defines the protocol to use between a web browser and a server to determine whether a cross-origin request is allowed.

Key CORS Headers

There are a number of HTTP headers related to CORS, but the following three response headers are the most important for security:  

Access-Control-Allow-Originspecifies which domains can access a domain’s resources. For instance, if requester.com want to access provider.com’s resources, then developers can use this header to securely grant requester.comaccess to provider.com’s resources.

Access-Control-Allow-Credentials specifies whether or not the browser will send cookies with the request. Cookies will only be sent if the allow-credentials header is set to true.

Access-Control-Allow-Methods specifies which HTTP request methods (GET, PUT, DELETE, etc.) can be used to access resources. This header lets developers further enhance security by specifying what methods are valid when requester.com requests access toprovider.com’sresources.

e.