Bug 173161
Summary: | Webkit rejects requests to localhost from https:// pages | ||
---|---|---|---|
Product: | WebKit | Reporter: | homakov <homakov> |
Component: | Evangelism | Assignee: | Jon Davis <jond> |
Status: | RESOLVED DUPLICATE | ||
Severity: | Normal | CC: | jond, webkit-bug-importer, wilander |
Priority: | P2 | Keywords: | InRadar |
Version: | Safari Technology Preview | ||
Hardware: | All | ||
OS: | All |
homakov
Due to Mixed Content warnings on https pages both mobile and desktop Safari reject access to http://127.0.0.1 and ws://127.0.0.1 which are localhost and technically not vulnerable to potential MitM attacks - there's no need to block these requests.
Here is a use case why our project badly needs this access: our app works as an authenticator like U2F that signs specific challenges given by the browser, so the user can log in some website.
When we simply open an app:// from the browser the app does not know who exactly opened it. We found a neat way to transfer unspoofable location.origin to the app: by making a request to localhost server which the app runs.
Our app has a WebSocket server at localhost:3101 and accepts requests from the browser, then checks Origin header to get trusted origin. It works like a breeze on all other desktop browsers and in Android. Firefox already fixed it in 55: https://bugzilla.mozilla.org/show_bug.cgi?id=1370861
It would be great if Safari could stop the blocking or at worst case allow a preflight request to let websites securely call our app websocket. It's really the only way for secure site<->app communication we could find.
Attachments | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/32675155>
homakov
CC
Alexey Proskuryakov
As discussed in the original, I do not think that this is a valid use case for a web browser, and should be prevented even more strictly.
*** This bug has been marked as a duplicate of bug 171934 ***