Vulnerability : Server-Generated ACAO Header From Client-Specified Origin

[krillingws]

kitsune-application-development-kit/KAdmin/Utils/AllowCorsFilter.cs

Lines 12 to 20 in 811be8f

	public override void OnActionExecuting(ActionExecutingContext context)
	{
	context.HttpContext.Response.Headers.Add("Access-Control-Allow-Origin", new[] { (string)context.HttpContext.Request.Headers["Origin"] });
	context.HttpContext.Response.Headers.Add("Access-Control-Allow-Headers", new[] { "Origin, X-Requested-With, Content-Type, Accept, Cache-Control, DeveloperId, WebsiteId" });
	context.HttpContext.Response.Headers.Add("Access-Control-Allow-Methods", new[] { "GET, POST, PUT, DELETE, OPTIONS" });
	context.HttpContext.Response.Headers.Add("Access-Control-Allow-Credentials", new[] { "true" });
	context.HttpContext.Response.StatusCode = 200;
	}

This vulnerability affects the admin dashboard.

The client's Origin header is reflected in the Access-Control-Allow-Origin header from the server, granting any domain access to CORS resources behind the admin dashboard. There should be a white-list in the configuration that lists allowed Origin headers.

The issue is made worse with "Access-Control-Allow-Credentials: true". Now that any domain can access the endpoints, they also can also authenticate as another user. This can be done by sending a crafted link to a user who is logged in (presumably, unless session token is persistent) - once clicked, the script would send a CORS request to sensitive endpoints and the browser would send along their cookies since "Access-Control-Allow-Credentials: true" is set.

More info on vulnerability - https://portswigger.net/web-security/cors#server-generated-acao-header-from-client-specified-origin-header