Exadra37
I came across this article that have some disturbing facts about using websockets from javascript in the browser for port scanning your machine.
The author discovered this after reading another article about why Ebay is port scanning localhost via websockets.
So this made him wondering how far he could go, and he starts with this question:
This got me thinking. I know that popular JavaScript frameworks use websockets in development to automatically reload pages when content changes. Could a malicious website eaves-drop on that traffic, and find out when developers are saving their code?
The reality was slightly worse than I had thought.
And then finds this disturbing facts:
But what happens when the developer makes a typo? The webpack dev server helpfully tries to send a bunch of debugging and stack information to the developer’s screen, by way of its websocket connection.
Now things are getting juicy. We’ve got code snippets, paths to files, locations, all sorts of bits of useful info.
It gets even better if eventually the Dev accidentally typos on a line containing useful data:
Now we’ve got a copy of this developer’s AWS Dev credentials. Quick, fire up the bitcoin miners!
What are your thoughts on this? Did you ever imagine that this could get so far?
I really need to do a POC of attacking Phoenix WebSockets, because more I read about them, more concerned I get with using them.
Where Next?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Elixir, Erlang & messaging conferences from Code Sync. Next up: ElixirConf US (10–11 Sep) & Code BEAM Europe (21–22 Oct), Haarlem + online.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ai
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #elixirconf-eu
- #api
- #forms
- #metaprogramming
- #hex
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
The deployment platform built for Elixir: PaaS ease, VPS control.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
dimitarvp
I did imagine it will go this far, yes. The insanity that is serving you code (JS) which your browser – which is essentially a small OS – executes almost without scrutiny, mandated that one day this will happen.
As excited as I am for some tech innovations – WebSockets included – we definitely need to get back to basics and even the drawing board for a lot of stuff.
But there’s no funding for that so I predict a lot of very embarrassing security incidents will keep happening for years to come.
egze
On the other hand - the only way to find out all the edge cases and make it better - is to use it. Even the best mind of the world can’t think of all things that can go wrong. Every single invention in human history had issues, but it was improved and made better.
So please do some tests if Phoenix Websockets can be exploited and create an issue if it is the case.
Exadra37
Don’t interpret my post as a complain about Phoenix websockets, I am just trying to raise awareness
And yes If when I get time to do the POC and I found an issue I will let Chris McCord know about them
chrismccord
Skimming the article, the author is using an external site that has js connect to localhost, right? If so, changing
check_origin: falsetocheck_origin: ["myapp.local"]indev.exswith a host file entry would suffice to prevent another host from establishing a websocket connection to your local server.hauleth
PSA: Do not use
.localfor your local development domain. It is reserved for mDNS and you should use.localhostwhich is currently reserved but unassigned to anything.chrismcg
I use
.testmainly because it’s a bit less to type than.localhost. (In conjunction with puma-dev to route foo.test to the right port)hauleth
I have plans for creating similar tool that will be language independent and will automatically create TLS certificates using local CA.
chrismccord
I had
In general I still use .dev, but good to know about mdns!
.devinitially but I thought someone would call me out for it being a real tld now, but I failed on my 2nd choicehauleth
.devhas few other “problems”, for example enforced HSTS in Chrome, not mentioning people using it as their TLD (like me).Exadra37
What is the reason behind having
check_origin: falsein developments? Why not keep it as in production?