| Summary: | [enh] Support HTTP over Unix sockets via http://localhost:[/tmp/socket]/foo convention. | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Kelly Price <bugs> |
| Component: | WebKit Misc. | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Enhancement | CC: | ap |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
|
Description
Kelly Price
2015-01-24 05:16:41 PST
Allowing access to local resources seems highly questionable from security standpoint. Services with UNIX sockets were not designed for malicious requests from all over the Internet. What is the need for this? This is mainly just to get a de-facto standard in place (I'm kinda scared about pushing out an IETF RFC draft), but can be useful for when the browser and server are on the same machine (a unconnected kiosk where TCP/IP is badly configured, for instance). As a proof of concept I'm working on a refreshing display of LOLcats collected from Cheezburger.com and stored locally (curated content) on a Raspberry Pi. (Yeah, I can just do TCP/IP, but then that gets into security sensitive issues for some places.) Since Unix sockets cannot be accessed over TCP/IP (they are by definition machine only) the only security issue is how the server is (mis)configured (and thus out of scope for this enhancement). The real use case is over on PHP (and yes, I've filed a bug over there as well as with Chromium and Mozilla) where services that are not exposed on any TCP/IP port can be accessed by a PHP process with native commands. |