Integrate feedback from security audit #36
Assignees
utopiah (Fabien Benetou)
Clear assignees
utopiah (Fabien Benetou)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: utopiah/biggu_s_gate#36
Reference in New Issue
Block a user
Similarly to #37 this has to be seen within the context of prototyping. Consequently even though users are invited to self-host their instance, and ideally federate, they also understand that this is experimental. Typical good practices are suggested proper passwords, data backup, isolation through e.g container without being the main initial focus.
Authentication via a token as in https://git.benetou.fr/utopiah/offline-octopus/src/branch/master/index.js would probably not pass in another context but here it might be acceptable with warnings.
Currently the API is not restricted, even write endpoints.
Sanitized some path input but should be entirely constrained instead.
Note that with the current system in place to generate nickname, there is no (to verify) no PII, namely no birthdate, no name, no contact information stored.
Consider https://cooldowns.dev
Clarify surface on frontend and backend (see #55).
Backend is expected to run in a container and behind a reverse proxy.
Consider https://developer.mozilla.org/en-US/docs/Web/API/Trusted_Types_API
Note that
eval()is used few times in core places.jxrcommandsSee also https://voicesofvr.com/1719-rip-rec-room-reflections-memories-with-shawn-whiting/ on cross platforn UGC and "hacker" problems. Seems to revolve around competition and in-game economy.
Crucial aspect of distinguishing genuine skill
Eval token for NAF,
See https://git.radicallyopensecurity.com/ngi/ngics-federating-pedagogical-immersive-experiences (authentication required)
Consider https://docs.docker.com/reference/dockerfile/#add---checksum and if possible npm equivalent for https://git.benetou.fr/utopiah/biggu_s_gate/src/branch/main/package.json#L6
See work done in
87efccc4c0Work done in
87efccc4c0thanks to audit from radicallyopensecurity (non-public link for now).Note that not all issues are solved but the biggest ones are. The most impactful changes are :
WORKSHOPenvironment variable to distinguish between WAN and LAN. A lot of experiments can be run safely on LAN where the typical setup is either a single XR headset (hosting its own instance thanks to e.g Termux, entirely offline and standalone, as demonstrated for the first time or more traditionally with an affordable server, e.g SBC like RPi Zero.Overall it was a very interesting process and definitely valuable. The biggest fear was that the project would be either basically unusable, that there would be only problems but no practical suggestions (e.g. only patterns but not libraries with reasonable default settings). The report once finalized by RadicallyOpenSecurity will be made public with their approval. The purpose here is to show workshop participants that a professional programmer always has a lot to learn. It is also done with the hope that institutions, e.g. libraries, toy libraries, schools, etc will see that the work is done with contributions from a lot of different professionals and even if though the medium, XR, is new, good security practices are still in place.
That being said more must still be done. Some issues remain open despite the bulk of the work now done. It would be positive to do another audit in the future to see if the patterns (reasonable defaults, input sanitation, environment distinction) are followed while still trying genuinely novel ways to learn.
Finally note that a discussion on using the project itself to teach about security could be done. Indeed the project aims at helping kids in particular but in truth anyone to remix content. This is done in XR but without hiding that it is done with code. Consequently making more "tangible" not just code but also how it must be correctly handle, and when, would be very interesting. An idea was to showcase input validation visualization, e.g. a line going from text as code to evaluation heading to a (virtual) CPU (see #149 on-going experiments) and if there is user input a cylinder around, as a kind of "shield" to insure it is properly verified to make sure the CPU (or rather the environment its runs in) behaves as expected. Users could then pick different cylinders with predefined validation methods, e.g. regex on email format or color ranges. I think it might learners, including myself, understand pragmatically. This is coherent with past work on #35 namely where the project can help to follow good practice by surfacing and manipulating its own artefacts.