-
Notifications
You must be signed in to change notification settings - Fork 0
Description
Currently, the deserialization code that takes []byte messages from each WebSocket connection and builds structs such as reqSetOwnRole only performs basic validation of the data to make sure that it can be decoded.
However, it is important that the server help mitigate XSS attacks and also just ensure that users don't abuse the API. An example XSS attack would be a user sending the following WebSocket message:
set-own-name
<script>alert("you have been pwned")</script>
On the server, the deserialization code would see that the first line contains the text set-own-name and then it would try to decode a reqSetOwnName from the body, i.e., the next line of text in the WebSocket message. It would successfully produce a reqSetOwnName containing the string value <script>alert("you have been pwned")</script>. Finally, the server would send out new player state to all connected clients (generally browsers running a JavaScript-based frontend).
On the client side, the JavaScript would go and re-render the DOM to show the new player names. If the JavaScript does not sanitize the <script>alert("you have been pwned")</script> to escape the script tags, the browser would then execute that script, meaning the user who put a script in their username will have successfully executed it in everyone else's browsers!
Aside from security, the server should probably just enforce some reasonable maximum name lengths, etc. This sort of thing goes for all information users can submit.