Since the entire website and its backend are open source, lichess more than any other chess websites is inviting to hackers and cheaters. In particular, I want to draw the attention of lichess developers and maintainers to a potential security hole that can easily be exploited.
As you know, the socket that communicates all the messages of the client to the lichess server and back is the Websocket object. A disquisitive hacker can reimplement the javascript prototype of a websocket object, thereby evesdropping on the messages that get sent back and fourth to the server. This information could then be linked to a chess engine software ( via chrome native app extention , for example) which then makes it possible to auto-transfer the moves to the chess software.
But then you might ask, how can the hacker reimplement websocket object after the page already loaded? It's simple: iframes.
The iframe is the pinnacle of security holes in modern web era. The fact is that an attacker can reimplement websocket on a window object of a newly inserted iframe, then load lichess in that iframe. Browser messaging for same origin is allowed, so all the critical messages get sniffed and sent back to the iframe host. Clever, huh?
A first thought that comes to my mind is to not allow iframes to be injected into DOM. I don't know how this can be done, but stackoverflow.com has figured it out. I can't insert an iframe element after the page is loaded there.
I believe patching this security hole is a good step towards reducing the number of bullet cheaters and encouraging fair play.
As you know, the socket that communicates all the messages of the client to the lichess server and back is the Websocket object. A disquisitive hacker can reimplement the javascript prototype of a websocket object, thereby evesdropping on the messages that get sent back and fourth to the server. This information could then be linked to a chess engine software ( via chrome native app extention , for example) which then makes it possible to auto-transfer the moves to the chess software.
But then you might ask, how can the hacker reimplement websocket object after the page already loaded? It's simple: iframes.
The iframe is the pinnacle of security holes in modern web era. The fact is that an attacker can reimplement websocket on a window object of a newly inserted iframe, then load lichess in that iframe. Browser messaging for same origin is allowed, so all the critical messages get sniffed and sent back to the iframe host. Clever, huh?
A first thought that comes to my mind is to not allow iframes to be injected into DOM. I don't know how this can be done, but stackoverflow.com has figured it out. I can't insert an iframe element after the page is loaded there.
I believe patching this security hole is a good step towards reducing the number of bullet cheaters and encouraging fair play.