15

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 ...


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 ...


10

(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 ...


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 ...


8

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 ...


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

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

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 ...


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

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

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 ...


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

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 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 ...


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 ...


3

Should web applications using websockets (...) include nonces verified by the server on each transmission to prevent CSRF? TL;DR: This is desirable, though not necessarily on each trasnmission (once per connection should suffice) and not to prevent CSRF, but XSS. This is more a safeguard than a strict necessity though. Details below. To answer whether or ...


3

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 ...


3

Lets say I want to talk to some otherwise unknown person on the Internet. And I want the message to be encrypted. Establishing a secure link is easy; D-H key exchange makes sure eavesdropping is impossible. But whom did I just establish my connection to? Was it the person I thought, or perhaps some other otherwise unknown person on the Internet who's playing ...


3

I think this is what you are looking for: Analysing, Testing and Fuzzing WebSocket Implementations with IronWASP. Looks like it has a nice set of tools for training and getting started with Web Socket Security. I stumbled upon this a few days ago but didn't get a chance to actually try their demo out. Just to give a summary of that blog post -- the author ...


3

WebSockets are an upgrade of a HTTP request: they start with a "normal" HTTP request containing an Upgrade header field and after the server send a matching response the connection switches from HTTP to the WebSockets protocol. The WebSockets protocol itself does not contain any verification of the peer, including no verification of the hostname. Thus any ...


2

Cryptographic point of view: the only way you can distinguish, from the outside, a fake device from a genuine one is by making the genuine device "know" some value that the attacker does not know. This can be the equivalent of a "password" (since there is no human involved, that password can be a sequence of 40 random characters, i.e. something quite strong ...


2

Note, my answer below assumes that the Origin header is being correctly checked and answers your question specifically. Socket hijacking is possible if there are no origin checks, or other valid authentication checks made in your own code when opening a new websocket. Original answer follows... Is it possible for an attacker to cause (by luring the ...


2

This leads to question #1: the Javascript code sent to the browser must contain the shared secret. So the shared secret is not very secret, is it? So how can we consider this a secure method of authentication? If you study the documentation of the Challenge Response Authentication with WAMP you should notice the following information: The client and the ...


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