[QUERY] BlobContainerClient is not restricted to a specific container

[mhichb]

Library name and version

Azure.Storage.Blobs 12.23.0

Query/Question

For blob client / blob container client, there is no validation to not leave the original container, e.g. in the following example

var path = $"../{otherContainerName}/{pathInOtherContainer}";

var credential = new DefaultAzureCredential();
var blobServiceClient = new BlobServiceClient(new Uri($"https://{storageAccountName}.blob.core.windows.net/"), credential);
var blobContainerClient = blobServiceClient.GetBlobContainerClient(containerName);
var blobClient = blobContainerClient.GetBlobClient(path);
var result = await blobClient.DownloadContentAsync();

result will be filled with the actual content of the file, even though the blob is in another container.

Is it a deliberate choice in design to not validate whether the blob path is contained within the original container? From naming and the fact that a container name was provided in construction, one might think that the client cannot access anything outside the provided container.

In the current situation, it's pretty easy to forget to validate the path and thus become vulnerable to https://cwe.mitre.org/data/definitions/22.html

Providing such a validation library-side would be nice IMO.

Environment

No response

[github-actions]

Thanks for the feedback! We are routing this to the appropriate team for follow-up. cc @xgithubtriage.

[amnguye]

The entire string of "$"../{otherContainerName}/{pathInOtherContainer}" would be considered the entire blob name/path in the code snippet you provided.

Since ".." and "/" are valid characters within the blob path. The SDK cannot automatically convert ".." as going back a parent directory. Unfortunately changing that behavior would be a breaking change, for customers who intentionally want this behavior.

The SDK cannot provide validation, as validation by the storage service can change. So by default we lean on the source of truth of validation which is the service.

For this scenario, I recommend creating a separate client for a different blob container.