在网络抗议中{*}推土机

A story cropped up this morning on my feed. Someone had discovered that while visiting eBay, their web browser was running a port scan on localhost with WebSockets. Presumably, the browser fed that information back to eBay, so they could do a risk assessment of some sort. Is the user a part of a fraud network?

今早在我的饲料上冒出一个故事。 有人发现，在访问eBay时，他们的Web浏览器正在使用WebSockets 在localhost上运行端口扫描 。 据推测，浏览器会将这些信息反馈给eBay，因此他们可以进行某种风险评估。 用户是欺诈网络的一部分吗？

Needless to say, this is mildly alarming. My web browser could be used to port scan my network? I try to follow security fairly closely, and I didn’t even know this could happen. What’s more, the scan just happened silently in the background, only visible to those who would happen to look for it.

不用说，这有点令人震惊。 我的网络浏览器可用于端口扫描我的网络吗？ 我试图相当严格地遵循安全性，但我什至不知道这种情况会发生。 更重要的是，扫描只是在后台默默进行，只有那些会寻找的人才能看到。

I know enough web development to be dangerous… but to be honest, I haven’t read up on WebSockets. Could a malicious bit of JavaScript attack my desktop’s SSH server with a 0-day payload?

我知道足够多的Web开发都非常危险……但是，老实说，我还没有读过WebSockets。 恶意JavaScript会以0天有效负载攻击我台式机的SSH服务器吗？

The answer is no, and yes. And I have some thoughts to add at the end.

答案是否定的，是的。 最后我要补充一些想法。

这还不算什么大事… (This isn’t all THAT big deal…)

After about half an hour of research, this is what I found.

经过大约半小时的研究，这是我发现的。

First, I looked into whether WebSockets were as dangerous as I thought. Honestly, I didn’t know what they did, because I had no incentive to look into them until now. My initial fear was that WebSockets could be used to fire arbitrary packets at my computer or other devices on my network.

首先，我调查了WebSockets是否像我想的那样危险。 老实说，我不知道他们做了什么，因为直到现在我还是没有动力去研究他们。 我最初的担心是WebSockets可用于在我的计算机或网络上的其他设备上激发任意数据包。

• Firstly, WebSockets seem to be prohibited from accessing 192.168.0.0/16 and 10.0.0.0/8. In Firefox, it raises SecurityError. Odd that it can access localhost, but meh.

  首先，似乎似乎禁止WebSocket访问192.168.0.0/16和10.0.0.0/8。 在Firefox中，它引发SecurityError 。 奇怪的是它可以访问localhost ，但是。

• In Firefox, WebSockets can’t open to port 21, 22, or 23. The console spits back the same SecurityError. I was hoping that WebSockets would be blocked for privileged ports (< 1024), but it didn’t raise an error for port 24. It seems that Firefox maintains a blacklist? (I didn’t investigate this further, or build a complete list of ports.)

  在Firefox中，WebSockets无法打开到端口21、22或23。控制台会吐出相同的SecurityError 。 我希望WebSockets可以被特权端口(<1024)阻止，但是它不会为端口24引发错误。似乎Firefox维护了一个黑名单？ (我没有对此进行进一步调查，也没有建立端口的完整列表。)

• Finally, I ran a simple netcat listener on my machine, and opened a WebSocket to it. Netcat spit out an HTTP request with a few headers indicating it was a WebSocket. The console wouldn’t let me send data until the connection was established, either.
  最后，我在机器上运行了一个简单的netcat侦听器，并为其打开了一个WebSocket。 Netcat发出一个带有几个标头的HTTP请求，表明它是WebSocket。 在建立连接之前，控制台也不允许我发送数据。

My fears were satisfied a bit. WebSockets only work on localhost, and you can’t send entirely arbitrary payloads. There are some restrictions to make that more difficult. Even still — I was able to replicate the author’s observation: WebSockets can definitely be used as a port scanner.

我的恐惧得到了一点满足。 WebSockets仅在localhost上工作，并且您不能发送完全任意的有效负载。 有一些限制使操作变得更加困难。 即便如此，我仍然能够复制作者的观察结果：WebSockets绝对可以用作端口扫描程序。

The next part was discovered by accident. I wanted to see if eBay would portscan me as well, and replicate that part of the author’s research.

下一部分是偶然发现的。 我想看看eBay是否也可以移植我，并复制作者研究的那一部分。

• I could not get eBay to port scan my computer, in either Firefox (with some privacy plugins like uBlock), or with a fresh Google Chrome browser. Even when logging in, I didn’t get port scanned.
  我无法在Firefox(带有uBlock等一些隐私插件)或全新的Google Chrome浏览器中通过eBay进行端口扫描。 即使登录，也没有扫描端口。

• Furthermore, I tried to open a WebSocket to localhost from the console while on eBay, but discovered it was blocked by a Content Security Policy — a header sent from the website. (Very curious! I had assumed it was some 3rd party script was doing the port scanning and eBay didn’t know… but it seems that whatever script that runs would need to work in conjunction with whatever sent the CSP!)

  此外，在eBay上，我试图从控制台打开一个WebSocket到localhost ，但是发现它被内容安全策略(网站发送的标头)阻止。 (很好奇！我以为这是第3方脚本在进行端口扫描，而eBay却不知道……但是看来，无论运行什么脚本都需要与发送CSP的命令一起使用！)

This is a bit of a neutral finding. Why isn’t localhost blocked by default? I can understand that may be use cases for it… perhaps some proprietary software that interfaces your browser with a daemon running on the computer. But that should be a requested permission, not something granted by default.

这是一个中立的发现。 为什么默认情况下不阻止localhost ？ 我知道这可能是用例……也许是一些专有软件，可以将您的浏览器与计算机上运行的守护程序连接。 但这应该是请求的权限，而不是默认授予的权限。

Wouldn’t you be concerned if a message popped up on your screen? “eBay wants to access the internal network on your computer. Allow access?”

您是否担心屏幕上弹出消息？ “ eBay希望访问您计算机上的内部网络。 允许访问？”

简要介绍端口扫描 (A brief aside on port scanning)

The author of the aforementioned article inferred that port scanning was a slightly offensive operation. I agree, but with one caveat.

上述文章的作者推断，端口扫描是一种令人反感的操作。 我同意，但有一个警告。

If I place a computer on the public facing internet, port scans from anonymous users are fair game. Mainly, because if you point a web browser at my IP address to see if it responds… technically that’s a port scan! That isn’t malicious behavior, is it? I don’t want to try and write a law… you can check if ports are open, but only these ones, and only so fast. That just seems to violate the “zero, one, many” principle.

如果我将计算机放在面向公众的互联网上，来自匿名用户的端口扫描是公平的游戏。 主要是因为如果您将Web浏览器指向我的IP地址以查看其是否响应……从技术上讲，这就是端口扫描！ 那不是恶意行为，不是吗？ 我不想尝试制定法律……您可以检查端口是否打开，但是只能检查这些端口，而且速度非常快。 这似乎违反了“ 零，一，多 ”原则。

Things get a bit more gray if your port scanner starts sending arbitrary data to try and elicit more information from a service — like what version of software is running. Still though, fair game. If I have a service listening to the public internet, it should be designed to be resistant to abuse. I have to accept the risk that my daemon is vulnerable to a 0-day of some sort if I’m hosting it on the public internet.

如果您的端口扫描程序开始发送任意数据以尝试从服务中获取更多信息(例如正在运行的软件版本)，则情况将更加灰暗。 不过，公平的游戏。 如果我有收听公共互联网的服务，则应设计成可以防止滥用。 如果我将其驻留在公共互联网上，则我的守护程序可能会受到0天攻击的风险，我必须接受这一风险。

If I don’t want to accept that risk, the answer is simple. Don’t open a port on the public internet. Either put up a firewall so it’s only accessible over VPN, or close it.

如果我不想承担这种风险，答案很简单。 不要在公共互联网上打开端口。 要么设置防火墙以使其只能通过VPN访问，要么将其关闭。

Port scanning is an entirely valid operation, and not necessarily malicious. But when a website is using my browser to traverse NAT and scan my local machine for open ports — that’s malicious behavior. Even if it’s done to “protect users”. My personal network is off limits. I can connect to you, but you can’t (and shouldn’t) connect to me without my explicit permission.

端口扫描是完全有效的操作，不一定是恶意的。 但是，当网站使用我的浏览器遍历NAT并扫描本地计算机上的开放端口时，这就是恶意行为。 即使这样做是为了“保护用户”。 我的个人网络无法访问。 我可以与您建立联系，但未经我的明确许可，您不能(也不应该)与我建立联系。

…但是我仍然感到沮丧。 (…but I’m still frustrated.)

Over the past decade, I’ve watched the emergence of what I’ll refer to as Web{*} technology. It’s a bit of a cloudy, vague term… but I can give you some examples of it. (Though the curly braces don’t exist on the standards, I felt it helped illustrate my point better.)

在过去的十年中，我目睹了所谓的Web {*}技术的出现。 这是个模糊，模糊的术语……但是我可以举一些例子。 (尽管标准中不存在花括号，但我认为它可以更好地说明我的观点。)

• Web{Sockets}: As mentioned in this article.
  Web {Sockets}：如本文所述。
• Web{Bluetooth}: Allows the browser to access Bluetooth devices through your computer
  Web {Bluetooth}：允许浏览器通过您的计算机访问蓝牙设备
• Web{RTC}: Enables your browser to do “real-time communication”
  网络{RTC}：使您的浏览器能够进行“实时通信”
• Web{Assembly}: Enables binary executables to run in your browser
  Web {Assembly}：允许二进制可执行文件在浏览器中运行
• Web{GL}: Allows your browser to communicate with your GPU
  Web {GL}：允许您的浏览器与GPU通信

• Web{USB}: Allows your browser to enumerate and communicate with USB devices. (Are you KIDDING me?!)

  Web {USB}：允许您的浏览器枚举USB设备并与之通信。 (你在跟我开玩笑吗？！)

• Web{???}: Allows your browser to access the accelerometers and other sensors on your system. At one point, it could read your battery charge status. (After particularly bad PR, the battery feature was deprecated.)

  Web {???}：允许您的浏览器访问系统上的加速度计和其他传感器。 一方面，它可以读取您的电池充电状态。 (在特别糟糕的PR之后 ，不推荐使用电池功能。)

These technologies can be characterized in the following ways…

这些技术可以通过以下方式进行表征：

• Each is enabled by default, and most people don’t know they even exist.
  默认情况下，每个功能都是启用的，大多数人甚至不知道它们是否存在。

• Each is difficult to disable, and likely lies hidden deep in about:config.

  每个都很难禁用，并且很可能隐藏在about：config中 。

• Each can be used to further fingerprint, identify, and exploit the user — but it seems that the feature developers either don’t think that this will happen, or don’t care. Perhaps it’s even their intention!
  每个功能都可以用来进一步指纹识别，识别和利用用户-但是功能开发人员似乎要么不认为会发生这种情况，要么不在乎。 也许甚至是他们的意图！
• Each adds a MASSIVE layer of complexity to the browser. Anyone want to try an accelerometer based side channel attack to recover keyboard strokes in separate windows?
  每一个都为浏览器增加了MASSIVE的复杂性。 任何人都想尝试基于加速度计的侧通道攻击来恢复单独窗口中的键盘笔触吗？
• Each brings the browser closer and closer to my desktop, and seems solely driven by ChromeBook developers.
  每个浏览器都使浏览器离我的桌面越来越近，并且似乎完全由ChromeBook开发人员驱动。

• For the rest of the web, each is an unnecessary gimmick.

  对于网络的其余部分，每个都是不必要的头。

This can best be illustrated with the battery feature. Honestly, I can’t imagine why that feature is needed. At all. Facebook, Twitter, GMail… none of these need access to it. Even if I were developing some… full screen web based application for mobile, I don’t need to know the battery. The operating system displays that in a pull down menu for me, and will notify me if there’s a problem.

最好用电池功能来说明。 老实说，我无法想象为什么需要该功能。 完全没有 Facebook，Twitter，GMail ...这些都不需要访问它。 即使我正在开发某种……基于全屏Web的移动应用程序，我也不需要知道电池。 操作系统会在下拉菜单中为我显示该信息，如果出现问题，则会通知我。

As a user, I don’t want redundant notifications. As a developer, I don’t care what’s happening on the user’s system. The “Web Battery API” has less utility than the infamous HTML <blink> tag. I can’t imagine the review process for how this got accepted as a web standard.

作为用户，我不需要多余的通知。 作为开发人员，我不在乎用户系统上正在发生的事情。 “ Web Battery API”的实用程序比臭名昭著HTML <blink>标签要少。 我无法想象它如何被接受为网络标准的审查过程。

This leaves me feeling a little bit like Arthur Dent, waking up to find out that my house is being bulldozed, and this had all been the plan for months.

这让我感觉有点像亚瑟·登特，醒来发现我的房子被推高了，这已经是几个月的计划了。

“But the plans were on display…”“On display? I eventually had to go down to the cellar to find them.”“That’s the display department.”“With a flashlight.”“Ah, well, the lights had probably gone.”“So had the stairs.”“But look, you found the notice, didn’t you?”“Yes,” said Arthur, “yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard.”

“但是计划在展示中……”“在展示中？ 我最终不得不去地下室找到它们。”“那是展示部门。”“带手电筒。”“啊，好了，灯光可能已经消失了。”“楼梯也是如此。”您找到通知了，不是吗？”“是的，”亚瑟说，“是的。 它被显示在一个锁着的文件柜的底部，文件柜被塞在一个废弃的厕所里，门上有一个标语“当心豹子。”

So, yes… WebSockets aren’t as big of a security risk as I had initially thought. Unlike the rest of the technologies, it seems to have somewhat of a purpose — even if it’s been made redundant by things like HTTP/2 streams. It’s a small change to deny localhost by default, and make the site request permission. But if you ask me, that’s a band-aid for a much bigger problem.

因此，是的……WebSocket并没有我最初想象的那么大的安全风险。 与其余技术不同，它似乎有一定的目的-即使它被HTTP / 2流之类的东西冗余了。 这是一个很小的更改，默认情况下拒绝本地主机 ，并获得站点请求权限。 但是，如果您问我，那是一个更大问题的创可贴。

The problem is that once a Web{*} feature is “on-by-default”, it’s hard to roll it back. 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. (What? I’d save much more time without this bloated framework? Shun the non-believer!) Once this happens, disabling WebSockets breaks the internet.

问题在于，一旦Web {*}功能为“默认状态”，就很难回滚它。 花费几个月的时间，就会出现一些NodeJS流行趋势，每个人都希望使用WebSockets重新实现HTTP，并通过JavaScript加载其网站的每项资产，以在涉及技术流行语宾果游戏的情况下节省十分之一微秒的时间。 (什么？如果没有这个肿的框架，我会节省更多时间？不相信那些人！)一旦发生这种情况，禁用WebSockets会中断Internet。

Now, if I want to have some modicum of control over what my browser does passively, I’ll need to install another plugin to control which sites use WebSockets. I’ll also need to revise my nginx config with Content Security Policies to deny the use of WebSockets on localhost, so that a malicious bit of JavaScript that lands on my website somehow can’t abuse my users.

现在，如果我想对浏览器的被动行为有所控制，则需要安装另一个插件来控制哪些网站使用WebSocket。 我还需要使用“内容安全策略”修订我的nginx配置，以拒绝在localhost上使用WebSockets，这样，落在我网站上的恶意JavaScript某种程度上就不会滥用我的用户。

This is just a mess. I’ve burned more than an hour of my time to understand how this affects me, and next week I’ll find that there’s another bulldozer coming in from another angle to lie down in front of. WebSockets can only connect… but now there’s WebSocketListener! Or how about WebRemoteDesktop! WebWiFiControl! WebCPUUsageMonitor! WebDMA! WebSmellovision!

这只是一团糟。 我已经花了一个多小时的时间来了解这对我有何影响，下周我会发现还有另一台推土机从另一个角度进来躺下。 WebSockets只能连接…但是现在有了WebSocketListener！ 或WebRemoteDesktop呢！ WebWiFiControl！ WebCPUUsageMonitor！ WebDMA！ WebSmellovision！

翻译自: https://medium.com/@bjt2n3904/in-protest-of-the-web-bulldozer-e0fce4567d26