security mechanisms (against path traversal) is in place

we access files from local storage, not sure if this can be leveraged to access files outside of the storage directory.

also json/javascript injections should be checked

Just my first few thoughts about this:

• path traversal
  • since the id is generated to be alphanumerical with dashes, this could be easily enforced to prevent path traversal via fake id (TODO!)
  • since we define the storage types ourselves (via enum), fastAPI should enforce them to be contained in that enum, so path traversal via tampered type should also be impossible (may add a check to be safe?)
  • all other (url-)paths that are not defined in the main.py should be rejected automatically
• json/ javascript injection
  • only possible for authenticated users, as no one else can create or edit the objects to be stored on the server
  • i should probably stop html evaluation of the data to be displayed (not done at the moment), so that even a compromised account can not subtly do this (it can still put fake urls in the data, and delete or change anything else)
• compromised user accounts
  • passwords are ONLY stored as bcrypt hashes, so a password database leak should not be a big problem (except the way it happened would be...)
  • if the deployed product integrates certificates, MITM would be practically impossible
  • if the user uses an insecure password, or re-uses it, or gives it so someone else, their account could become compromised, and we would be unable to do anything about this. We either need to accept this risk, or introduce further access restrictions on who is able to change which data. Since the number of users will likely be very small and restricted, i think this is an acceptable risk
  • general risk of compromised accounts could be mitigated by better logging of user actions, and maybe automated alerts if too many changes are happening in quick succession

just tested to be sure: javascript injection via the dataset name is possible

url and metadata are put into textfields, which are not evaluated by the browser

this means only the name can be manipulated, and this only works in the dataset list, not in the specific dataset view

Thanks for you comments. This is a complex subject, let us keep an eye on this.

-I think that having a mechanism in place that prevents access outside of the data dir makes sense (i tried to pull something like that together). So that even if the oid is manipulated the access outside of the dir is not possible.

-I noticed that I put some (non-sanitized) user content in the response (e.g. Not found exception included oid) this is probably not a good idea. Especially if the jsons are then put in html somehow. I don't know how far the fastapi helps here.

mentioned in issue #9 (closed)

In c5cdcdc4 all html-characters that might cause security issues are now encoded if they are part of some dataset property.

These are " ' < > &.

The json/ javascript injection security issue should therefore be solved.

2444e5d0 brings a verification of the oid. This means that only requests are processed, where the oid is a valid UUID. Since valid UUIDs only contain [a-z0-9] and dashes ('-'), they can not be used to cause a path traversal.

Since fastAPI ensures that the location_data_type property is always one of the configured strings (currently dataset and storage_target), the storage adapter is only used with non-traversing directory- and filenames. Any slash ('/') or other special character would result in the request being rejected with a 400 Bad Request error.

This means (from my understanding) that path traversal should be impossible now.

during the check I noticed that there is already support fo uuid in pydantic, so I changed it in d8d5d5a2 . This has the advantage of being more visible in the docs, what you think?

That's a very good idea and i completely agree with you.

closed