(defvar *wsd-client*)
(setf *wsd-client* (wsd:make-client "ws://localhost:8080/clog?r=316004"))
(wsd:start-connection *wsd-client*)
;; to steal information after stealing the connection
(wsd:on :message *wsd-client*
(lambda (message)
(format t "~&Got: ~A~%" message)))
;; Triggering an event on behave of someone.
;; The event-id(s) are still serial (I think that's Okay as long as connection ids won't be matched),
;; so the attacker can infer + scan to trigger them.
(wsd:send *wsd-client* "E:CLOG6099:click ")
Connection 316004 Ping
Connection 316004 Ping
Connection 316004 Ping
Reconnection id - 316004 to #<SERVER {70131A42F3}>
Connection 316004 Ping
Connection 316004 Ping
Connection 316004 Hook = CLOG6099:click Data = NIL ; this event was triggered by the attacker
Connection 316004 Ping
Connection 316004 Ping
I didn't write more code to finish the complete case of sample attack demo.
However, since the hook can be listened by some lisp objects which send javascript scripts to the client sides, attackers should be able to find a way to steal users' personal information. (as long as the web app dynamically displays those info via js-on-the-wire).
Solution
The connection ids should be at least as secure as session ids. Thus, according to secure session ids, connections ids should be picked from a large address space with a cryptographic grade random algorithm.
This PR is a candidate to solve #174 , which I think the problem exists.
Problem
https://github.com/rabbibotton/clog/blob/29fb063ad612d4caff30cef2ac6ba8f69e1355d0/source/clog-connection.lisp#L176-L179 Via https or not is not the point since CLOG does provide a way for a client to reconnect with a connection id. Then, an attacker can steal a connection if the attacker gets (by infer, scan, etc) someone's connection ID, which maps to
connection-data
viaclog-connection::*connection-data*
.I didn't write more code to finish the complete case of sample attack demo. However, since the hook can be listened by some lisp objects which send javascript scripts to the client sides, attackers should be able to find a way to steal users' personal information. (as long as the web app dynamically displays those info via js-on-the-wire).
Solution
The connection ids should be at least as secure as session ids. Thus, according to secure session ids, connections ids should be picked from a large address space with a cryptographic grade random algorithm.
So, I chose cl-isaac for the library.
Thanks. :)