[HN Gopher] In protest of the web{*} bulldozer, a response to we...
___________________________________________________________________
In protest of the web{*} bulldozer, a response to websocket port
scanning
Author : bjt2n3904
Score : 58 points
Date : 2020-05-20 18:21 UTC (4 hours ago)
(HTM) web link (medium.com)
(TXT) w3m dump (medium.com)
| mindslight wrote:
| The problem is that these APIs have been developed with little
| concern paid to security. Compounding this, Mozilla hasn't even
| tweaked the implementation details to retain what security they
| could. This is seemingly due to a mistaken idea that sandbox
| escape is the only security property that matters, allowing these
| APIs to leak identifying information like sieves.
|
| For example, AFAICT the common wisdom for mitigating Location
| with user.js is to set it to Ask for every site instead of a
| blanket Deny, because the latter actually turns out to be more
| fingerprintable. Whereas Deny should be indistinguishable from
| Ask with a negative response.
| TazeTSchnitzel wrote:
| > Web{Assembly}: Enables binary executables to run in your
| browser
|
| "Binary executables" makes it sound like it's machine code, but
| WebAssembly is more like a bytecode for JavaScript.
| TeMPOraL wrote:
| I'm of two minds about it. On the one hand, JS should've been
| compiled in the first place; that we spent some two decades
| making computers parse increasingly complex scripts repeatedly
| is a sad waste, and it spawned what's probably the biggest hack
| ever to become a standard practice: minifying code. On the
| other hand, WebASM webapps will be an order of magnitude less
| inspectable.
| TazeTSchnitzel wrote:
| Why will WebAssembly applications be less inspectable? JS
| applications are already aggressively minified multi-megabyte
| blobs.
| TeMPOraL wrote:
| I can take a look at a minified piece of JS after
| reformatting, and quickly guess what many of the functions
| do just by their shape. I won't be able to do that anywhere
| as easily with a piece of decompiled bytecode, especially
| if it went through an optimization pass.
| qeternity wrote:
| On the other hand, V8 is the most widely run, heavily
| invested and thus optimized JIT compiler in history. So I
| think most of the interpreted vs compiled mistakes have been
| Google'd out at this point.
| TeMPOraL wrote:
| It helps with execution speed, but not with the speed of
| parsing the plaintext code and interpreting (or compiling)
| it.
| kbenson wrote:
| > Firstly, WebSockets seem to be prohibited from accessing
| 192.168.0.0/16 and 10.0.0.0/8. In Firefox, it raises
| SecurityError.
|
| And 172.16.0.0/12 I hope. I did a little Googling and didn't
| quickly find a list of sources they are blocking in Firefox (or
| is it part of the standard?), but I hope that one is included.
| It's not as common, but it's still a private network and used
| sometimes.
| moonbug wrote:
| Gee, good job no one uses IPv6.
| pdonis wrote:
| _> And 172.16.0.0 /12 I hope_
|
| Yes, at least on my Firefox (76.0.1 on Ubuntu).
|
| However, Chrome will happily open a websocket to addresses in
| the 192.168., 10., and 172.16. ranges. It fails for 127.0.0.1,
| but only because it says there's nobody listening (not, as
| Firefox does, because of a security error accessing that IP in
| the first place); for localhost it can actually verify that no
| service is running on that port, whereas for remote hosts in
| the private ranges it can't.
| swiley wrote:
| I remember being a little surprised websockets could violate the
| same origin policy. It was only a matter of time before that was
| going to be abused.
|
| It's a shame because it meant you could run your own server for
| eg js/html games.
| [deleted]
| TazeTSchnitzel wrote:
| > I remember being a little surprised websockets could violate
| the same origin policy. It was only a matter of time before
| that was going to be abused.
|
| WebSockets don't have the Same Origin Policy like
| XMLHttpRequest does, yes, but they are required to tell the
| server they connect to what origin they came from, so the
| server can enforce whatever restrictions it likes.
|
| WebSockets were also designed with preventing abuse in mind:
| note the protocol obfuscation and weird headers, which I think
| are there so you can't confuse non-WebSocket-aware servers and
| non-HTTP protocols.
|
| However, as with XMLHttpRequest and other ways to do an HTTP
| request, it's not possible for the browser to know if a
| destination server speaks HTTP without trying to connect to it,
| and I guess that's why port scanning is possible.
| qeternity wrote:
| I'm a bit surprised that anyone with a remotely techie background
| has been unaware of websockets until now.
| qorrect wrote:
| Yeah his intro turned me off immediately. Why would I want to
| read this guys uninformed opinion ?
| bjt2n3904 wrote:
| I generally do embedded and radio things. :) I'm not gonna lie,
| I can't follow web stuff with the speed at which it changes.
| bijection wrote:
| > Unlike the rest of the technologies, [Websockets] seems to have
| somewhat of a purpose -- even if it's been made redundant by
| things like HTTP/2 streams. ... Give it a few months, and there
| will be some NodeJS fad where everyone wants to re-implement HTTP
| with WebSockets, and load every asset for their website through
| JavaScript to save a tenth of a microsecond in some edge case
| involving tech buzzword bingo. ... Once this happens, disabling
| WebSockets breaks the internet.
|
| To be fair to Websockets, they've been around for almost a
| decade, pre-dating http/2 by a few years, and the duplex
| communication they offer is a fundamental building block for all
| kinds of stuff, from games to trading websites to chat systems.
|
| Although the Battery API is a different story, the author's point
| about Websockets seems to be based on somehow having overlooked
| them for quite a while.
| TazeTSchnitzel wrote:
| Yes, and WebSockets are a clean and fast replacement for
| horrible hacks that preceded them. Nobody liked having to
| constantly poll the server one way or another, or god forbid,
| use Flash.
| saagarjha wrote:
| All the new web standards are a bit tiresome, to be honest, and
| some of them have the flimsiest justification. I remember someone
| pushing the Ambient Light Sensor API on Twitter at some point and
| the example they gave was "you can offer dark mode to your users
| if the brightness you detect is low". Like, really? There are
| actual browser APIs for this, and they offer a better signal of
| user intent than brightness levels could ever do. Can you please
| just think these through?
| hoten wrote:
| Extrapolating the reasons behind a particular standard being
| created from a random Tweet is a bit disingenuous. Here are the
| examples that the standard proposal cites:
|
| https://w3c.github.io/ambient-light/#usecases-requirements
|
| The camera one especially seems convincing to me.
| brundolf wrote:
| The web already has a user-facing permissions system; it wouldn't
| be hard to add many of these under that umbrella (USB, Bluetooth,
| and Sensors stand out as obvious candidates that should've been
| behind that barrier from the beginning). Battery Status
| definitely seems pointless overall.
|
| But I don't agree with the overall thesis, that the web
| fundamentally should not get features like these. Though,
| obviously, some of these "standards" have been rushed through and
| poorly executed.
|
| I think for this we can blame Chromium's dominance. As the author
| said, many of these features were probably motivated by Chrome
| OS. And the devil's bargain of letting Chromium take such
| complete control over the web is that Google can strongarm
| whichever new "standards" they like into the Web.
|
| The standards committee doesn't want WebBatteryStatus? Fine,
| we'll implement it anyway and now Chrome desktop/mobile,
| Chromebooks, and Edge will all have it. Sites that want to use it
| will probably just use it and throw up a "Use Chrome"
| notification for Firefox and Safari.
| chipperyman573 wrote:
| I own a business and recently had to change all the pictures on
| my website from webp to png because safari both refuses to
| render webp _and_ pretends to accept them. I hate it so much
| and see very real costs in increased bandwith (every image is
| around 3-4x bigger) but I have no choice because I want people
| with iphones to be able to buy things from me. Safari is
| honestly just as bad as chrome but for different reasons (ios
| safari was arguably the single biggest cause of the death of
| flash, for example). I also had to go through and fix a few
| other pseudo css classes that only safari didn 't support which
| was really annoying, what a waste of time.
|
| I don't think many people would consider "Don't use safari"
| banners a valid option unless the website was somehow really
| focused on non-apple users or not trying to sell something.
| brundolf wrote:
| I use Roll20, a popular web app for playing tabletop games
| with others over the internet. It doesn't work in Firefox or
| Safari; it's the only reason I keep Chromium on my machine.
| Kalium wrote:
| Really? That's very odd. I use in just fine with Firefox
| weekly.
| brundolf wrote:
| It might only be the video/audio chat that's broken, but
| I know something about it was broken
| fenwick67 wrote:
| About 6 months ago I remember it being totally unusable
| on FF, even without using the AV stuff.
| chipperyman573 wrote:
| For every example you can find me of a website that doesn't
| support safari I could find 10 that make exceptions to do
| so. The point isn't that nobody does it, it's just that
| most companies who want to make money from the general
| population (aka most of them) have to.
|
| Roll20 is also such a niche thing already it's not really a
| fair example. People who want to use roll20 will use
| another browser because they want to play dnd with their
| friends. Most stores don't have that social aspect.
| brundolf wrote:
| My point is that if YouTube stopped working on Firefox
| because they didn't agree to a new standard Google had
| invented, lots of people would stop using Firefox.
|
| It takes someone who really cares about these issues to
| bother switching back and forth between two different
| browsers because you want to use a non-Chromium for most
| things but have to use Chromium for a couple of things.
| The vast majority would just say "well, whatever" and
| switch completely.
| [deleted]
| uryga wrote:
| > _safari both refuses to render webp and pretends to accept
| them_
|
| weird, i haven't had that issue! i run a site that's set up1
| to redirect image requests to a WebP version if the Accept
| header allows it; half our team uses Macs w/ Safari and no
| one reported any issues with images.
|
| ---
|
| 1 wordpress + webp-express: https://github.com/rosell-
| dk/webp-express i guess it's possible they special-case
| Safari, i'll check later
| chipperyman573 wrote:
| It could've been my setup, to be honest I had just finished
| fixing all the pseudo classes and was kind of frustrated
| and decided to just switch to png after I couldn't figure
| it out in 5 minutes hahaha
|
| But whatever the case is, Safari definately does not
| support webp and special exceptions need to be made to
| support this edge case.
| josteink wrote:
| > The web already has a user-facing permissions system; it
| wouldn't be hard to add many of these under that umbrella (USB,
| Bluetooth, and Sensors stand out as obvious candidates that
| should've been behind that barrier from the beginning)
|
| Let's add Javascript to that list too.
|
| Not all sites need it, and given the abuse it's responsible
| for, it shouldn't be permitted unless a user opts in.
| vbezhenar wrote:
| Chrome allows to disable JavaScript by default and only
| allowing it on some websites. Probably privacy and security-
| conscious users use that feature.
| hombre_fatal wrote:
| That was also the logic behind Windows Vista's UAC popup.
| fenwick67 wrote:
| > I think for this we can blame Chromium's dominance. As the
| author said, many of these features were probably motivated by
| Chrome OS. And the devil's bargain of letting Chromium take
| such complete control over the web is that Google can strongarm
| whichever new "standards" they like into the Web.
|
| The dark side to this is that the Chrome team can implement an
| API as an experiment, then when it's ready, propose it to the
| standards body and push it through before anybody else can
| catch up.
| brundolf wrote:
| Yeah, that too
| alerighi wrote:
| I don't think these features are bad, they are useful in some
| ways. Why we need USB on the browser? Think about updating the
| firmware of a device, you just go to the webpage, connect the
| device to the USB and update it, without having to download and
| install a tool to flash it, for an operation that you need to
| do just one time. This is only one example of many that we can
| make, another could be IDEs in the browser to program boards
| like Arduino, without installing software on the PC.
|
| Battery status? It could be useful to know if the PC is
| connected to a power source and the level of the battery, even
| for a stupid scenario like watching a video, when I'm low on
| battery I usually reduce the resolution of a YouTube video
| because reproducing a 4k60p video uses a lot of resources, and
| drains the battery quickly. It would be useful if the webapp
| could just do that automatically, maybe on YouTube an option
| like reduce resolution when low on battery. Or for games, or
| whatever uses a lot of resources.
|
| Think about it: the only reason because Electron apps exist
| (and we waste 200Mb of disk for each one of them) is only
| because browsers don't have APIs to access the filesystem! To
| me is a waste, the browser should give each application (let's
| stop calling them sites, they are no longer that) the APIs and
| permissions to access hardware, just like on mobile devices you
| have a dialog that says "this app would like to access the
| internal storage, consent or deny?".
|
| Where is the problem? The user should give the privilege (only
| one time) and you finally can do basically 99% of work in the
| browser (and maybe the browser introduces also API to run the
| application in a window), you no longer need Electron just to
| do these kind of things, is still more secure than Electron
| because the code is sandboxed by the browser, and you don't
| have to worry about packaging your software for different
| operating systems.
| vbezhenar wrote:
| Another use-case for USB is to access crypto tokens. There
| are USB devices which store private key and allow to perform
| crypto operations. It's much safer than storing private key
| in file system. Using those keys in website is a useful
| feature.
| saagarjha wrote:
| > I don't think these features are bad, they are useful in
| some ways.
|
| That's the whole point: they look like APIs that might be
| useful for something but then they invariably become used for
| fingerprinting or an attack surface and we find out that
| nobody was actually using it at all, even though we came up
| with a couple of legitimate-sounding use cases for it.
|
| > the code is sandboxed by the browser
|
| What's the point of a sandbox if you keep poking holes in it
| by adding new APIs?
| mindslight wrote:
| > _The standards committee doesn 't want WebBatteryStatus?
| Fine, we'll implement it anyway and now Chrome desktop/mobile,
| Chromebooks, and Edge will all have it. Sites that want to use
| it will probably just use it and throw up a "Use Chrome"
| notification for Firefox and Safari._
|
| The right answer is for Mozilla to implement the API, and leave
| it disabled by default. Disabled meaning reporting 90% full all
| the time, or some suitable probability distribution.
| josteink wrote:
| > Each brings the browser closer and closer to my desktop, and
| seems solely driven by ChromeBook developers.
|
| Yes. So let's reject them all.
|
| Let sane desktop browsers tell the web that these APIs don't
| exist in a meaningful way, and that building applications that
| rely on them is a waste of time.
|
| Mozilla, Microsoft and Apple? Pretty please?
| vbezhenar wrote:
| One website can use resources from other website using img,
| script, link tags. That was since WWW invented. User agent will
| retrieve related resources from other websites.
|
| Those port scanners abuse that feature. <img
| href="https://website-resolving-to-127-0-0-1.com:1234"> is a
| legitimate code and browser is expect to establish TLS connection
| to 127.0.0.1:1234.
|
| Trying to patch that fundamental behaviour is hard.
|
| Websockets are not enemy here. They are just convenient tool. It
| could be implemented without websockets.
|
| Imagine that google.com added <img src=yourpoorwebsite.com> into
| their main page. Now you've got billions of requests and your
| website is DDoSed. Who's bad here? Browser which allows requests
| from google.com to yourpoorwebsite.com? Or Google who decided to
| kill your website?
| cygx wrote:
| _Trying to patch that fundamental behaviour is hard._
|
| There's prior art for this, though:
|
| https://web.archive.org/web/20121001002815/http://my.opera.c...
___________________________________________________________________
(page generated 2020-05-20 23:00 UTC)