SECURITY ISSUE suspected

Ask the community
,
1

I might be wrong on this but I wanted to check anyway. Lets say we run some html code in an iFrame to allow a user to authenticate with google.

  1. The user clicks ok to allow access to their details.

  2. Google sends us an IDtoken containing the user details.

  3. We check the token to make sure it has been signed by google.

  4. We check that the token has been issued for our website domain.

  5. We grant access to our website if steps 3 & 4 are met.

I could be wrong but i believe there is a potential security flaw in WIX with regards to step 4.

As far as i can see all requests from a html iFrame on a live WIX website come from the domain filesusr.com. The request does not come from your WIX website domain i.e MyWebsite.com

This means that in order to allow successful google authentication in this scenario all WIX websites would have to authorize the domain filesusr.com.

So if we consider the security check in step 4 a malicious user could easily bypass the security checks. All they would have to do is create a WIX website with iFrame authentication then get a user to click on the authentication link then forward the resulting token to any other WIX website.

An official WIX website would check that the token had been signed by google and that it was for domain filesusr.com. Both checks would pass even though the token was not for their website. A malicious user could then potentially get access to user info on another persons WIX website.

I must be missing something here, is there something preventing this from happening ?

2

Hey Mike,

It’s always best to put code with credentials in the backend if possible. If you absolutely, positively need for the code to be in an HtmlComponent, then see the post Secure a Google Maps API key in an HtmlComponent (the same technique applies for all Google API keys).

3

@yisrael-wix

Thanks for responding. As far as I can see there are no keys exposed in the above scenario when using html for authenticating with google. Below is an example of the html code ( from Google ) we would run in the iFrame to authenticate.

The issue is that every request from an iFrame comes from the same domain filesuser.com. As you can see in the code below there are no keys exposed.

<!doctype html>

4

@mikemoynihan99 The HtmlComponent isn’t really any different than running the above script on a regular HTML page. As I mentioned before, the most secure method is to run the authentication in the Backend. If that’s impossible for this scenario, then the HtmlComponent won’t really be any worse than a regular HTML page.

5

@yisrael-wix

When an authentication request is made from regular HTML page is comes from a unique domain i.e. MyWebsite.com.

So when we validate on step 4 we check that the token was issued for MyWebsite.com.

HtmlComponents on WIX websites make the requests all from the same domain filesuser.com.

So when we validate on step 4 the token could have been issued for any WIX website.

6

@mikemoynihan99 As I recall, these URLs have an identifying component that at least ties it to the site owner. Even if it doesn’t identify the specific site, identifying the site owner is sufficient protection. This is how I’ve done it on my projects.

Again, I always rely on backend code - when possible. That’s really the best and most secure.

7

@yisrael-wix

Ok thanks. I’ll check a few of the google tokens to see if to see if the owner is identified as part of the url in the token.

In regards to the backend I think the google token still is going to be received from the front and then passed to the back end. What I mean is that a malicious user could pass a token from the frontend to the backend.

8

I implemented the same thing and have the same question, so have you run into any conclusions?

9

1194×1290 73.3 KB

I think I have met the same issue, what is filesusr.com and how can I edit it?

10

@mikemoynihan99
Each user gets a specific subdomain under fileuser.com in the referenced example it is " yisraelh1-wixsite-com.filesusr.com " so if you were to white list your own unique generated sub-domain on google configuration for the referrer, you will not share the mentioned referrer validation with other users. as @yisrael-wix noted in the example, you could also whitelist the specific resource of the embedded html component url, but do note that the url could change if you update your html component code, and you will need to update your configuration, you can use asterisk as in the example to whitelist a partial path.
Also note that if you wish, you can host your html code on any host with any domain, and populate the html component with a URL .

Please let me know if you still have security related questions.