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.
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?
@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.
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.
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.
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.
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.
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.
A server to proxy the request acts as an unauthenticated guest. If the user’s own browser makes the request, it is authenticated by default (e.g. sending cookies and auto-logged in, thereby exposing personal data). Therefore there are severe security risks with allowing it from the user’s browser, but not from a proxy server.
You need to understand this is exactly what CORS is designed to solve. This is why I suggested that you don’t appear to understand the purpose of CORS. Either use a proxy server as you suggest, or configure CORS on the servers you want to access. That will solve your problem. I’m just passing by to tell you that pursuing a suggestion to weaken an essential pillar of web security will get you nowhere and it will never be implemented. You need to take a completely different approach.
I do. I think it’s a good thing to have for most uses, but it’s important to be able to bypass security with the user’s permission when it limits what applications can do.
Read my previous messages regarding how a similar attack can be conducted using methods that are possible to carry out with current standards.
One of which is an inefficient hack and the other one of which is a non-starter, as the entire point of this is to allow access to servers the developer doesn’t control.
I could, but that’s not what I’m about. The proxy server is a hack (that can be expensive for a few use cases). Native programs are a distribution headache. I want to deliver programs with the convenience of the web and the privacy and performance of native programs, which I’ve been trying to lay the groundwork for by submitting this proposal and supporting others.