Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

CORS policy blocks login popup on sub domains #5656

Open
jdarwood007 opened this issue May 5, 2019 · 5 comments

Comments

Projects
None yet
3 participants
@jdarwood007
Copy link
Member

commented May 5, 2019

Description

Access to XMLHttpRequest at 'https://www.site.tld/forums/index.php?action=login' from origin 'https://support.site.tld' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource.

I suggested a fix for this in #5654 for Cron.php via just a hard code because of the complexity of this. However this occurs in the main SMF application. This will also affect other implantations where CORS takes effect due to sub domains.

My suggestion here is we add a feature (YUP!) to allow CORS for Any (*), Referral sub-domain detection (*.site.tld), Referral Multiple domain handling, and disabled (don't see the header).
When we do sub domain detection, we need to know the main domain and may need that value specified for us, (i.e.: site.tld). Via the referral header we can parse the domain and if its from the sub domain, allow it via returning the matching sub domain for this header.
When we do multiple domain, we should have them manually specify all domains that are allowed. If we find a match in the referral, we allow it (via returning the matching referral domain for this header.

I believe this should be a blocker issue for release, as this will impact sites needing to specify a CORS header.

Steps to reproduce

  1. Install SMF on www.site.tld/forums/
  2. Use SSI.php with $ssi_theme set and call ObExit(), generating a page within SMF template system.
  3. Navigate to the page
  4. Attempt to login.

Additional information/references

See #5654 for how we fixed Cron.php
https://www.moesif.com/blog/technical/cors/Authoritative-Guide-to-CORS-Cross-Origin-Resource-Sharing-for-REST-APIs/
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Access-Control-Allow-Origin

@MissAllSunday

This comment has been minimized.

Copy link
Contributor

commented May 5, 2019

At work we "solved" the issue using apache to change the header if the request comes from the same domain:

SetEnvIf Origin ^(https?://.+\.somedomain\.com(?::\d{1,5})?)$ CORS_ALLOW_ORIGIN=$1 Header append Access-Control-Allow-Origin %{CORS_ALLOW_ORIGIN}e env=CORS_ALLOW_ORIGIN Header merge Vary "Origin"

Of course this will mean SMF will have to have a way to change its .htaccess whenever $scripturl changes.

@jdarwood007

This comment has been minimized.

Copy link
Member Author

commented May 5, 2019

Not a viable option if .htaccess isn't allowed or using another engine (such as Nginx)
But essentially the same idea just within SMF to handle this.

@MissAllSunday

This comment has been minimized.

Copy link
Contributor

commented May 5, 2019

True, but I would rather prefer to offer a custom solution for those who needed (a wiki page for every major HHTP server) than open all SMF installs.

@Sesquipedalian

This comment has been minimized.

Copy link
Member

commented May 28, 2019

I can see adding a simple toggle to allow CORS from all subdomains when requests are sent via SSI.php, but anything beyond that would get too complex very quickly.

Checking whether a request is from a subdomain of the same domain that SMF is running on should be simple enough.

if (!empty($modSetting['allow_cors']) && !empty($_SERVER['HTTP_ORIGIN']) && filter_var($_SERVER['HTTP_ORIGIN'], FILTER_VALIDATE_URL) !== false)
{
	$board_domain = array_slice(explode('.', parse_url($boardurl, PHP_URL_HOST)), -2);
	$origin_domain = array_slice(explode('.', parse_url($_SERVER['HTTP_ORIGIN'], PHP_URL_HOST)), -2);

	if ($board_domain === $origin_domain)
	{
		header('Access-Control-Allow-Origin: ' . $_SERVER['HTTP_ORIGIN']);
		// More headers?
	}
}

@Sesquipedalian Sesquipedalian added this to the Final milestone May 28, 2019

@jdarwood007

This comment has been minimized.

Copy link
Member Author

commented Jun 1, 2019

Sounds reasonable.

We should add a securityHeaders() type function to our template_header() call. This function would take are of all the headers such as cors, frame options, etc. Also make it expandable easily as more security headers are coming down. There is even more headers than what we have implanted already or discussed in the pipeline.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.