1

I have been looking at tips to securing Websocket Connections and found this article https://portswigger.net/web-security/websockets which states that one should "Hard code the URL of the WebSockets endpoint, and certainly don't incorporate user-controllable data into this URL."

Currently I have been taking a part of the URL using window.location.pathname (which I'm not sure if this can be manipulated) in order to grab a name (i.e., music, movies, etc) that I then compare with entries in my DB to make sure they exist in order to continue with the connection. I have also seen similar examples doing this for reasons such as a chat room in order to keep chats for a single topic to the same ServerEndpoint. I found this page from Oracle that talks about creating this on a Java Server, to which they call it "URI Templating" https://docs.oracle.com/javaee/7/tutorial/websocket008.htm

The thing I want to know is how is one supposed to hard-code the URL if we have dynamically created data that affects the URL (again Music, Movies, etc topics that can be added). The only way I can think of now is creating a script on the html page I'm serving up that has the Websocket info hard coded when serving the page from the server, but since I'm looking to work with a WebWorker, I'm not sure if there will be some issues with that.

As a NOTE: Invalid URLs wont load the Websocket JS file/code so if I it's not a valid room (i.e., Music), there is no connection. Malicious URLs are the only way I can see something happening with this setup, and I can see why hard-coded is mentioned as the secure method; however if I'm stopping invalid URLS from loading the correct page, as well as checking to make sure the part I'm grabbing (i.e., Music), actually exists in the DB, would this be secure?

So, my question is, is what I'm currently doing not secure, by referencing the window.location.pathname and doing the checks stated above? If it is not secure, and needs to be hard-coded, how should I go about creating a "hard-coded" Websocket URL when I have variable data that could be used as the endpoint URL? I'm also curious if a malicious URL would affect users on a case-by-case basis, or is there something deeper going on with being able to create any endpoint URL?

Thank you.

2

Assuming you control all the server-side code on a given origin (that is, there's nothing at the same scheme://host:port combo that is controlled by somebody else), then that's the only part you need to hard-code. In other words, you can hard-code wss://my.domain.com/ (with the port implicit) and as long as you (or a trusted third party) control all the content on that domain, it's fine to dynamically generate the rest of the path to the WS endpoint.

Regarding spoofing the window.location, this is sort of possible - code running on the page can set any path (without changing the origin, or causing an actual navigation) by calling pushState - but that's only a risk if either the site allows untrusted content to be passed to pushState, or if the site can be loaded using a URL with a "weird" path that might look like it's for one page but actually be for another. Assuming you're successfully "stopping invalid URLs from loading the correct page", it's probably not a big concern.

With that said, it's pretty easy to avoid performing concatenation of the WS URI on the client. One option is just to have a single WS endpoint (or a small, known set of them) and send data like what type of media the user is accessing in a message body. Another is to have a fixed list of known WS endpoints that are hardcoded in the script, and select one dynamically based on the current page/URL. Finally, you can ask the server to give you the current endpoint or list of endpoints (generating it dynamically, perhaps in response to some info sent with the request, rather than hard-coding) using AJAX, and either just use the returned one or pick one from the returned list as appropriate.

2
  • Thank you for your answer. I control the domain content, it's just the path to which endpoint is dynamic. Thank you for letting me know about the Push State issue, I will check that out... Is there anything you recommend I look into with push state? Unless there is some things I need to check for (such as some characters being encoded into others that might cause some weird issue) I make sure the URLS are valid or else 404. The issue with having a list and such is that the content will constantly grow (similar to a chatroom application adding new rooms), so that's the issue with a list. – MXBuster Feb 21 at 0:55
  • So overall it seems that as long as I'm checking to make sure the path is valid and exists in the db, I should be okay with the way I'm doing things now (even if I don't look into the Push State stuff)? You mention having 1 or a few connections already hard-coded, but wouldn't giving that info out like that be a security issue by presenting all possible connections to be exploited? A little off topic, but I also am curious when checking a db in general is it wise to put the value into the query, or compare the 1 value to the list of all values from the db to prevent SQLI or something else? – MXBuster Feb 21 at 0:59

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.