61

This is ebay running a local port scan over websockets. It has been reported recently: https://twitter.com/JackRhysider/status/1264415919691841536 (original research) https://www.bleepingcomputer.com/news/security/ebay-port-scans-visitors-computers-for-remote-access-programs/ (bleeping computer article) I don't think it's malicious, but it is bad practice, ...


51

What if the attacker decides to tamper the "from:id" such that it could send arbitrary messages to anyone from any user? Create a session, and use the session identifier as identifier, not the user ID directly. E.g. let user send credentials, and upon successful validation, return a (short lived) session handle, that can be used in future messages. ...


17

There's been some discussion of this recently, e.g. here and here. Suggested reasons for port scanning include: a) fingerprinting to uniquely identify your machine for future reference, or b) attempting to determine whether your machine is part of a botnet, since botnets often use VNC services over various standard ports to control their bots.


16

That's a lot of questions. We'll stick just to the core problem and mitigation technique: There's the chance that my connection may be proxied or otherwise examined by a caching proxy. And there's a decent chance that I can fool the proxy if I can get the right data into my request and the desired data into the response. The basic idea was demonstrated in a ...


13

Basically, you have to treat every input from the user as potentially malicious. Vidarlo has already mentioned two security issues and how they can be prevented in his answer. I'd also add that the content itself ("text:") could contain malicious code (e.g. javascript snippets). Make sure that this code is not executed on the receiving end. And I'd also ...


12

(tl;dr at bottom) Encryption is essentially free at this point, even on dial-up connections. Almost every major language has it built-in, or has a library for it, etc. The advantage of not using TLS/SSL is a very small fraction of a second start-up time, a very negligible reduction in CPU usage (a small fraction of a percent), and about 4kb of bandwidth ...


12

A German computer magazine was writing about this observation last week and asked eBay for a statement. eBay's answer was: There is some widely spread software that is either Malware or legit software which can be miss-used to steal the eBay password. This software is listening on certain TCP ports. By trying to establish a connection to these ...


12

What if the attacker decides to tamper the "from:id" such that it could send arbitrary messages to anyone from any user? Do not use from:id in your API. You already know it from user authenticated session instead and have zero reason for user to transmit it to you in the first place. And if there's nothing to transmit, there's nothing to tamper. On that ...


11

Actually, this has nothing to do with moving CryptoCat to a browser plugin/extension. It's not even related to SSL at all. Having that in mind, Stephen's answer is somewhat misleading. I'll attempt to address that. CryptoCat is still JavaScript & HTML. Give me your full attention, assume that SSL is doing its job and you're 100% sure that you're ...


11

These days it's near impossible to thwart a traffic based DoS without some kind of hefty physical firewall in the network. However, if you're talking about other forms of DoS then there are a few things you can do to help. Use asynchronous/non-blocking sockets. A malicious user could open up any number of connections to your sockets consuming all of your ...


11

Why doesn't websockets support custom headers? It's unlikely to be an oversight ... I agree that this looks like an oversight. This actually does not surprise me since in my opinion the implementation of WebSockets inside the browser was not well-thought-out in the first place. The most glaring issue is that WebSockets ignore the same origin policy or CORS ...


9

tl;dr: "Yes, WebSocket is the first way to open an unlimited number of connections to a single server, so it indeed likely needs additional protection to prevent DOS attacks. But we don't really have a way to implement this correctly ..." (https://bugs.webkit.org/show_bug.cgi?id=32246#c4) since i'm interested in that topic too, but dont have the time to ...


7

The client-side socket.io library does not have the ability to .join() a room. That ability is only in the server-side library (because that's where the rooms are maintained) and thus the only place it can actually be processed. So, the only way to join a room is to make your own message for a join request from client to server and process that message ...


7

First, websocket connections are initialized from javascript which gets executed by the web browser on the client. That means typical websocket connections are outbound connections, not inbound connections. Inbound websocket connections would only be possible when the host runs a websocket server. A normal browser will usually not do this. And even when the ...


7

The Wikipedia description (https://en.m.wikipedia.org/wiki/WebSocket) of the protocol seems to sum it up best. To quote: In addition to Upgrade headers, the client sends a Sec-WebSocket-Key header containing base64-encoded random bytes, and the server replies with a hash of the key in the Sec-WebSocket-Accept header. This is intended to prevent a caching ...


6

Checking the Origin header prevents a WebSocket from being used by another website that the user is also visiting (e.g. to extract data). As per the link: WebSockets are not restrained by the same-origin policy This is because the protocol upgrade request will have access to the user's cookies, so if you're not checking the origin the request could have ...


6

Allowing arbitrary TCP sockets originating from the web browser means that an attacker can use the browser as a trampoline to connect to arbitrary services on the users local network. This can for example be local mail servers which often are setup to trust any internal system to send mail and thus can be misused to send phishing mails which look like they ...


6

Ignoring the obfuscation, this is just a normal persistent XSS attack. Your approach will not solve this. For one, the payload isn't actually in the src attribute, but the id attribute. An attacker could also simply skip the obfuscation (or use a different one): <img src=x onerror=alert('do the thing')> The reason for the obfuscation is likely to ...


5

The reason for the masking is to make websocket traffic look unlike normal HTTP traffic and become completely unpredictable. Otherwise any network infrastructure equipment which is not yet upgraded to understand the Websocket protocol can mistake it for normal http traffic causing various problems. This is especially a problem for caching proxy servers and ...


5

Socket.io creates a WebSocket, and WebSockets follow the normal Same-Origin Policy rules. However, it is possible to make a WebSocket into a cross-origin resource using the Access-control-allow-origin HTTP header, which commonly known as CORS. If for some reason CORS was being used to create a cross-origin WebSocket, then it is possible that this ...


5

SSL will usually not help. If the attacker has complete control over the computer, then he wins. He can inspect and modify the memory of all process in the computer. If the attacker is only a non-administrative user, then he won't be able to spy on process from other users. However, if the attacker can run code as the same user as either the server or the ...


5

In a word, YES, websockets DO represent a security problem to your local machine. First off, some clarification there is a difference between binding to 127.0.0.1 and 0.0.0.0 ... as one will only allow your computer to connect and the other will allow any computers on your network to connect. BOTH of these are dangerous, however, binding to 127.0.0.1 is ...


5

Secure WebSockets (wss://) properly protect the data during transfer, same as HTTPS does. But outside of this the application logic might introduce enough problems to impact the security of the data, similar to just using HTTPS instead of HTTP does not magically make the application safe against things like XSS, CSRF, SQL injection... . On top of this ...


4

A CSRF attack on WebSocket is possible, if you rely on authentication cookies. From RFC 6455 §1.3: The |Origin| header field [RFC6454] is used to protect against unauthorized cross-origin use of a WebSocket server by scripts using the WebSocket API in a web browser. The server is informed of the script origin generating the WebSocket connection request. ...


4

From what I know of the WebSockets protocol whilst it allows two way message passing, at a TCP level the connection is initiated by the client and as such the most firewall configurations (e.g. those which allow standard web browsing) will allow WebSockets communication without further configuration. Indeed looking at the Wikipedia Article, this is touted ...


4

Unless you're sending on the order of exabytes through that connection, AES should not degrade in security over that time frame. The duration that the WebSocket is open doesn't degrade it's security, so only the data flow through it may eventually (after a lot of use) erode the security given by AES. Keep in mind that the entire Internet generated about 1,...


4

Securing secure websockets Secure Websockets start life as a standard HTTPS request and only connect if a valid HTTPS connection can be established with the server. As a result, websockets will automatically respect any public key pinning, strict transport policies, etc, which the server sets in the response headers when the client first attempts to ...


3

The Origin header allows you to prevent another website from exposing your websocket-service to their users. Let's say you build a web application which consists of a relatively uninteresting HTML+Javascript client on www.example.net which receives data from your far more exciting server backend through websockets on ws.example.net. Now someone else ...


3

From the WebSockets FAQ at the IETF: By having a client send out an encoded random number and having a server give a response that can only be generated by aWebSocket server, the client can verify that they are indeed talking to a WebSocket server and not to some other kind of server. ... Thus the main idea is that WebSockets cannot be used to talk to ...


3

There are two generic solutions to this problem. Both solutions are based on the approach to not publish information in the public that should not be public. This implies that you have to implement some sort of authentication mechanism in your application, e.g. a log in form that creates a new session (and new temporal session keys). Needless to say, you ...


Only top voted, non community-wiki answers of a minimum length are eligible