AttackFlow Findings Dictionary

Finding A Way To Try AttackFlow Enterprise Edition?

If so, click to download 15 days full version for free!

Insecure CORS Configuration

The attacker can steal user-related information from the target web application in which the victim has an account

Severity

Critical

Fix Cost

Low

Trust Level

High

Cross Origin Resource Sharing (CORS) has emerged as a reaction to Same Origin Policy (SOP) restriction applied by browsers onto the web applications.

Same Origin Policy dictates that a resource loaded from a domain A can’t reach another resource on domain B if even one of the below criteria doesn’t match;

  • Protocol (https, http, data, ftp, etc.)
  • FQDN (fully qualified domain name, including the subdomain)
  • Port (80, 443, 8080, etc.)

Even though this is a very good security restriction that prevents random sites loaded in browser hijack users’ sessions or steal their information, it is also too tight for developers who own two domains with different resources but still want to communicate through the browser.

Therefore, CORS implements that if domain B allows domain A to access him by XHR requests and be able to parse the response then it returns a header including domain A, as such;

                
Access-Control-Allow-Origin: www.alloweddomain.com
                

This header’s value shouldn’t be a wildcard character (*), otherwise, any domain in a browser can make a request to domain B and be able to parse the response without the consent of the browser user.

            
Access-Control-Allow-Origin: *

The code below configures CORS insecurely by using wildcard.

[EnableCors("*", "*", "*")]
public class WindowController : ApiController
{
[EnableCors("*", null, "GET")]
public HttpResponseMessage Get()
{
return Request.CreateResponse(HttpStatusCode.OK;
}
...
                 
            

Cross Origin Resource Sharing (CORS) has emerged as a reaction to Same Origin Policy (SOP) restriction applied by browsers onto the web applications.

Same Origin Policy dictates that a resource loaded from a domain A can’t reach another resource on domain B if even one of the below criteria doesn’t match;

  • Protocol (https, http, data, ftp, etc.)
  • FQDN (fully qualified domain name, including the subdomain)
  • Port (80, 443, 8080, etc.)

Even though this is a very good security restriction that prevents random sites loaded in browser hijack users’ sessions or steal their information, it is also too tight for developers who own two domains with different resources but still want to communicate through the browser.

Therefore, CORS implements that if domain B allows domain A to access him by XHR requests and be able to parse the response then it returns a header including domain A, as such;

            
Access-Control-Allow-Origin: www.alloweddomain.com
                   
            

This header’s value shouldn’t be a wildcard character (*), otherwise, any domain in a browser can make a request to domain B and be able to parse the response without the consent of the browser user.

            
Access-Control-Allow-Origin: *

The code below configures CORS insecurely by using wildcard.

response.addHeader("Access-Control-Allow-Origin","*");

Yet another example for insecure CORS value using Spring MVC annotations.

@CrossOrigin(origins = "*", maxAge = 3600)
@Controller
public class BooksController {

@RequestMapping(method = RequestMethod.POST)
public String Check(Credentials credentials, HttpServletResponse response) {
...
// return
}
...
       

Finding A Way To Purchase AttackFlow Enterprise Edition?

If so, click to buy now for yearly subscriptions!