[Proposal] Full Network Access in Progressive Web Apps

permissions
Tags: #<Tag:0x00007faf2ce3f610>
#13

You answered by point about CSP by talking about CORS. These are different technologies. I think you’ve missed my point…

#14

oh my god how did I miss that, should’ve waited a few hours and re-read it - one sec, gonna update OP


edit: quickly edited OP to mention CORS, will rework it more once I’m off work

#15

If you want to disable CORS, you’re opening an even bigger security vulnerability! Now users who approve the prompt could have all their private content stolen from social networks and messaging apps by the page that was given the permission. There is absolutely no way this will be allowed.

#16

Remember, the requesting page does not get state. These permissions also wouldn’t allow the page to read every byte going over the network.

#17

That doesn’t matter. You’re deliberately breaking a core security feature of the web that is essential for people’s ability to trust web content is private and secure.

#18

Could you elaborate more about the particular sort of attack you’re proposing? I can’t exactly tell what your argument is here. I understand that this is a huge security risk in itself, and that’s why I want to be careful about it, but I can’t take a certain situation into account when I don’t know what the situation is.

#19

There’s already lots of information on the web about how CORS works and why it’s important. I’m not here to re-explain all of that - I’m just pointing out this would be catastrophic for security and there is no way it will be accepted by browser makers. You should understand why security features exist before proposing to break them!

#20

Please see my previous reply, I’ve just edited it. I fully understand why the security features exist, but they can get in the way - that’s what this proposal is for.

#21

Sorry, I didn’t explain myself well when jumping to CORS. If you can render the sites yourself, which is obviously possible if you can make arbitrary requests, then CSP is meaningless. However, if the user is happy to say “Let example.com communicate with facebook.com unrestricted”, they’ve already got a lot of trust in the site. Even without this proposal they’re doomed.

Regarding:

That’s true, but having a good understanding of CORS, I don’t understand the following attack:

Can you please explain how approving the prompt lets them steal all of your private content, in a way that’s significantly easier than without this proposal?

#22

@AshleyScirra I think we both got heated there. I’d like to apologize for that.

I think neither of us fully understand what the other is saying, so let’s clean that up. Here are the relevant parts of my proposal in a nutshell:

  • It only has as much state as the page does. We could craft a request and send it to Facebook or whatever, but unless the page has somehow gotten the user’s login, it’s just an unauthenticated, unprivileged request.
  • The user has to grant the permission. There’s the usual screen-chair issue, and I need to work something out for that, but the important thing is that this permission isn’t given to every single page. As per the OP, the PWA would need to be installed, there needs to have been user action to trigger the request, and the user needs to have accepted the permission.

It is true that the user could be phished due to this API, but it could also be done in a million other ways that already exist. Unfortunately, there will never be a silver bullet to take care of phishing, and part of the protection has to be for the user to take care of.

In general, we’re pretty much just giving just a PWA the same power a PWA plus relevant backend would have, to remove the need for that middleman server to handle all requests.

1 Like
#23

Unrelated to the previous debate, but it also might be smart to add scoping based on the type of file. For example, in the case of the podcasts app from earlier, the page could request only access to XML files (for the RSS feed) and MP3/Ogg/whatever for the actual audio.

#24

If you don’t understand how bypassing CORS could be used to steal private information, then I think it’s fair to say you don’t understand why CORS exists.

#25

I fully understand. I think it’s worth the risk, as the same attack vector can be used in many other ways.

#26

Cross-origin requests pose a security risk because an application able to make requests to a third-party site is able to act on behalf of a user of that site, due to the fact that, if a user is logged into that site, the browser will send those requests with the cookies it has for that third-party site. Merely sending a request, without any included “proof” that it comes from any user at all, poses no security risk unless the site on the receiving end is handling user logins by the client’s IP address or something. The proposal made here is for STATELESS requests, as in, requests made without cookies or any other form of state a website might use to authenticate a user’s browser (to show that they are logged in).

CORS is necessary because, by sending requests authenticated as coming from the user by way of some sort of state sent in the request (saved from an existing, legitimate login), a malicious site could impersonate a legitimate one when dealing with the legitimate site’s backend. If that state is not present in the request, then simply making a request to the legitimate server from a malicious application does not pose any security risk I can think of. The fact that it’s done from the same browser that’s used for legitimate logins doesn’t mean the malicious request would have any way of proving itself to be legitimate. The session ID still isn’t there.

#27

I fully understand. I think it’s worth the risk, as the same attack vector can be used in many other ways.

No, it can’t - there is nothing else on the web platform that allows circumvention of CORS.

Basically there are 4 situations:

  • CSP is blocking you. This is fully under your control, so you can fix it. No bypass is necessary.
  • CORS is blocking you on your own server. This is fully under your control, so you can fix it. No bypass is necessary.
  • CORS is blocking you on someone else’s server. This is not under your control. You can ask them to change their CORS configuration to allow your web app.There are two possibilities:
    • They agree and make the change. No bypass is necessary.
    • They disagree, because they don’t want your web app to have access. This is also the default for security reasons. A bypass would only exist to circumvent this security configuration, which is against the wishes of the server owner.

Therefore, any kind of bypass only exists for malicious uses.

#28

The hypothetical email app in the use cases I listed is malicious?

#29

I’ve added a GitHub repo to the OP.

#30

Also,

No, it can’t - there is nothing else on the web platform that allows circumvention of CORS.

Yeah, sure, the means may not be the same, but the end result is. I could easily prop up a backend server that just proxies the data.

#31

@AshleyScirra

Any native app has access to that. If you have a server doesn’t mean you should be able to block requests by your choice. Imagine making a Google Chrome within Google Chrome. This would allow to do that. Server shouldn’t discriminate for any requests unless its on a page where unauthenticated requests are not allowed.

And as he said, I can do the same with the backend server. This would allow you to move everything to front end.

#32

I’d like to continue discussing the possibility of requesting access to certain origins. I think it’d be a useful way to hamper a lot of more dangerous usage, as well as reducing the damage a compromised app could do.