Closed jonnytest1 closed 1 month ago
Looking at public String resourceKey(AbsoluteLocation resource) {...}
we assume the resource is an absolute location. Meaning it must carry the bucketName. Using resourcePath.substring(resourcePath.indexOf(bucketName) + bucketName.length())
we trim the first occurrence of the string bucketName. If the resource key contains a member matching the bucketName, this won't be affected.
This is, the resource type T
in AbsoluteLocation<T>
must make sure the absolute resource path always starts with the bucketName. Therefore, the "vulnerable datasafepath" stated above is not a valid reference to an absolute location.
so then the actual error is that the WriteToInboxImpl.java doesnt prefix the rootbucket ?
Not seeing the error in https://github.com/adorsys/datasafe/blob/develop/datasafe-inbox/datasafe-inbox-impl/src/main/java/de/adorsys/datasafe/inbox/impl/actions/WriteToInboxImpl.java. Can you elaborate?
wel it doesnt make sure the request is prefixed wtih the root bucket . we'Re using InboxService.write(WriteRequest.forDefaultPublic())
to write things into the inbox so either the WriteRequest should make sure the rootBucket is prepended (though its not gonna be convenient to inject it there since its staic) or the WriteToInboxImpl.java should make it sure when reading out the request.getLocation() or alternatively somewhere in the following resolver.resolveRelativeToPublicInbox
Hello @francis-pouatcha this change implies indirectly ensuring that the file paths in the generateUserWithInboxAndOutbox function and related test methods are correctly set up. As it is crucial to avoid NoSuchFileException , are there any other ways we can handle this ?
https://github.com/adorsys/datasafe/blob/develop/datasafe-storage/datasafe-storage-impl-s3/src/main/java/de/adorsys/datasafe/storage/impl/s3/StaticBucketRouter.java#L27
if the path provided as DocumentFQN to methods like storeDocument contains the rootbucket string in any way (even if it isnt at the start of the string ) everything in front of it will be stripped and allow writing to arbitrary files if any part of the path is user controlled by prefixing the user controlled part with a rootbucket and then adding the remaining folder structure completely ignoring any kind of user restrictions and allowing overwriting of system or other user's files
example rootbucket : "bucket" datasafepath: "users/myuserid/private/files/usercontrolled.aes" vulnerable datasafepath: "users/myuserid/private/files/bucket/users/otheruser/private/files/somefile.aes"
@ing some people as it seems kinda important :)
@max402 @jkroepke @valb3r