Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
[SECURITY] Authentication Bypass by Forceful Browsing #987
About audited Directus version.
Unauthenticated attackers can bypass the application's authentication enforcement and directly access internal components, effectively circumventing the authentication credentials validation phase.
An attacker can get an access to the possible sensitive files.
Forceful Browsing attacks (direct access to internal components) can be used to exploit incomplete authentication enforcement in the server-side application. The forceful browsing technique enables attackers to access internal sensitive components, without undergoing the application authentication credentials validation phase.
Through the following link it is possible to get an access to application images that should be accessible after the authentication.
What problem does this feature solve?
Fixes security hole.
How do you think this should be implemented?
Would you be willing to work on this?
Maybe, with help/guidance from Directus team.
Makes sense. Will this effect caching, CDNs, latency, etc? Are there any drawbacks to this approach? If so, we should look into making it optional — especially since we'll be switching to UUID naming, which isn't "guessable" (part of the problem).
Any estimate on how long this will take to implement @itsmerhp?
@benhaynes Yes, It will effect on caching, CDNs, and latency.
According to approch provided by @itsmerhp
If you set the
We may think for a special token which only uses for accessing the image.
According to me, we should implement the UUID first,
@rijkvanzanten Let me know your thoughts. So we can finalize the approach.
Thanks @hemratna — that seems like a great approach. I agree that we should start with UUID since that partially solves the problem. After that we can write the permission gateway to secure files, which I think should be off by default (so files are public).
With the individual file permissions, files would still need to go through the permission gateway to check if each are
Instead of a toggle, let's use a Dropdown of options for file name. That will be more future-proof if we want to add more options in the future.
It looks like
I have a few questions in it:
Regarding file permission, we can give role-based permissions also, but as per me, there seem two problems in it.
Problem 2: For example File interface has been used in a collection as a field and for that collection, a role has not permission but for File Library(directus_files) that role has permission, then in that case how to restrict the listing of files of that collection in file directory?
Global vs Storage Adapter
We could make this a global setting, but I think it make more sense to have this be a configuration option for the storage adapter. That way you could have all
How this works...
Set for the each storage adapter, regardless of the role/user. Either way permissions would decide if you can see the asset through the App... but if set to public then you could still view the asset after logging out (since you know the actual asset URL).
You can still do this for public and private files... but public files can still be accessed when the user is not authenticated (if they know the exact asset URL).
We should use the existing
To keep things simple, I think we keep everything the same... but if you do not have access to Directus Files, then you're "Choose Existing Files" modal would be empty, and any relationships to files you don't have permission to would be
Does all this make sense?
TL;DR: We should add the ability to make files private at the storage adapter level, and those files get routed through a gateway that checks auth/permission. Any other features should be in a new ticket.
Just to make things more clear, We also need to give support for the multiple adapters of the same storage type.
Instead of writing
Writing our own
Implementing the ONLY AWS S3 ACL will not support private file mode for
Agreed, In the future, we might require an option for role wise permission, For example,
How to use AWS S3 ACL?
If the media is uploaded to storge which is set to
In case the user doesn't have permission this will return a blank string.
We also use the same concept for all the other file adapter which support inbuilt ACL like DigitalOcean Spaces, Google Cloud Storage, etc.
Thanks @hemratna! It seems like there are some great benefits to using the S3 ACL. Maybe we should have a core (
We could start with whichever is easier (S3 ACL or local gateway) and to the other later. The important thing is having support for private files somewhere.
@rijkvanzanten — thoughts on this approach?
Do you have a sense of time needed to integrate each of these options? @hemratna
Perhaps we should start with the global/local/fallback/default with an API endpoint that returns actual files (based on auth/acl)? Once we have that we could look into progressive enhancements for S3, etc.
Please let me know if I am missing anything for initial implementation.
Can we also support
If we use role-wise permission(App > Roles & Permissions) for files accessibility, then public/private can't be applied storage adaptor wise(for eg. can't set one local storage public and another private), permissions will be applied for all the files of all the local storage adaptors.
Approx Timeline: 40 hours
Perfect — thank you @itsmerhp!
This all sounds good, and the timeline works... but let's wait on starting this until the App is "stable". We have a much higher ticket count on the App and we should get most of those resolved before starting in on a bigger overhaul like this one.
In the meantime, if an external dev wants to give it a try we can help guide them and review the PR! But internally we need to triage the whole platform first.