This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-08-12
Channels
- # aleph (3)
- # announcements (15)
- # architecture (6)
- # babashka (35)
- # babashka-sci-dev (10)
- # biff (5)
- # calva (9)
- # cherry (1)
- # cider (44)
- # clj-kondo (31)
- # cljfx (1)
- # clojure (108)
- # clojure-europe (32)
- # clojure-norway (12)
- # clojurescript (15)
- # conjure (3)
- # cursive (8)
- # datahike (1)
- # datalevin (19)
- # datascript (1)
- # datomic (59)
- # emacs (4)
- # graphql (3)
- # jobs (1)
- # luminus (6)
- # meander (9)
- # membrane (45)
- # nbb (67)
- # off-topic (16)
- # portal (3)
- # remote-jobs (1)
- # scittle (8)
- # shadow-cljs (46)
- # test-check (7)
- # tools-deps (5)
- # vim (63)
- # web-security (11)
- # xtdb (15)
I ended just restricting the origin, which seemed easier to implement and just as secure. Maybe that token was a method before that was an option? Unclear.
Not sure if this relates to your immediate problem but > the login depends on the websocket connection The origin is forgeable for websocket connections 🙂
@U01BP1CB37B What i think is being protected by the server checking the origin is an http upgrade to ws request with a different (malicious) origin, that could exposed auth information in cookies. > The origin is forgeable for websocket connections Can you be explain more? I turned off the token because it was throwing errors for reasons i haven't gotten around to understanding, if you think that causes an issue i would love to know.
Sure -- I don't really have the context for your immediate problem but here's some reading that may be interesting 🙂
https://devcenter.heroku.com/articles/websocket-security#origin-header
> However, remember that the Origin
header is essentially advisory: non-browser clients can easily set the Origin
header to any value, and thus “pretend” to be a browser.
Meaning that if you're using the Origin
header as some kind of security check on your backend, it can easily be forged by a malicious client
interesting, this is frustrating because of the massive amount of emphasis put on the origin.
i really should just use keycloak and just follow instructions verbatim.
could a non-browser client make a get request and get all the session cookies though?
Yea, i think it's safe. the malicious client can spoof the origin, but it won't get the cookies then, because it's not making the request from the browser which has them.
i mean, i would like to add the token, it's frustrating that i can't figure out why it's failing. But i'll circle back to it...
I added a comment to the old https://github.com/ptaoussanis/sente/pull/338 on senti about the concern, just to see if anyone can clarify.
For my use case, this bit summarizes the whole thing nicely:
> A non-browser client, however, cannot access the session cookies stored in your browser. Even if the attacker spoofs Origin
, their request will be denied because they’re not authenticated.
> from https://dev.solita.fi/2018/11/07/securing-websocket-endpoints.html