[jira] [Comment Edited] (JCLOUDS-1571) Unable to provide custom signed headers using BlobRequestSigner#signPutBlob

["Filip Panovski (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/JCLOUDS-1571?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17310533#comment-17310533 ] 

Filip Panovski edited comment on JCLOUDS-1571 at 3/29/21, 9:44 AM:
-------------------------------------------------------------------

Updated the priority to "major" as I believe this to be a potential security vulnerability.


was (Author: fpano):
Updated the severity to "major" as I believe this to be a potential security vulnerability.

> Unable to provide custom signed headers using BlobRequestSigner#signPutBlob
> ---------------------------------------------------------------------------
>
>                 Key: JCLOUDS-1571
>                 URL: https://issues.apache.org/jira/browse/JCLOUDS-1571
>             Project: jclouds
>          Issue Type: Bug
>          Components: jclouds-blobstore, jclouds-core
>    Affects Versions: 2.3.0
>         Environment: Debian
> Java HotSpot(TM) 64-Bit Server VM (build 25.201-b09, mixed mode)
>            Reporter: Filip Panovski
>            Priority: Major
>
> (Disclaimer: I'm not 100% sure whether this is a bug report or a feature request, as I've found only scant information available)
> We have the use case where we wish to provide a signed aws-s3 {{PUT}} URL to a browser client which will be used to process a file upload (non-chunked, single URL). We are using version {{2.3.0}} (the latest public release).
>  The {{jclouds}} API has support for this via {{BlobStoreContext#getSigner}} , i.e. {{BlobRequestSigner#signPutBlob(String containerName, Blob blob, long timeInSeconds)}}.
>  However, there seems to be no support for signing custom headers as part of the URL.
>  The relevant AWS Documentation (link [here|https://docs.aws.amazon.com/AmazonS3/latest/API/sigv4-query-string-auth.html]) states that:
> {code:java}
> For added security, you should sign all the request headers that you plan to include in your request.
> {code}
> I dug around the {{jclouds-core}} code and saw that, for pre-signed {{PUT}} requests, a {{PhantomPayload}} is used which appears, for all intents and purposes, as a real payload with checksum and content-length.
> However, although this information is available at the time of signing, the only headers which are part of the signed headers are those which are either specifically annotated as such (e.g.: {{org.jclouds.s3.S3Client#putObject}}, which contains {{@Headers(keys = EXPECT, values = "100-continue"}}) or are otherwise part of normal request flow depending on media type (i.e. {{content-type}}, {{accept}}).
> The way I access the API is as follows:
> {code:java}
> @Override
> public URI getPreSignedPutUrl(final String blobId, final long contentLength, final String checksum,
>         final String mediaType) {
>     BlobStoreContext context = blobStoreContextProvider.getBlobStoreContext();
>     BlobRequestSigner signer = context.getSigner();
>     Blob expectedBlob = context.getBlobStore().blobBuilder(blobId)
>             .forSigning()
>             .contentType(mediaType)
>             .contentMD5(HashCode.fromString(checksum))
>             .contentLength(contentLength)
>             .build();
>     HttpRequest request = signer.signPutBlob(this.bucket.getName(), expectedBlob, 60);
>     return request.getEndpoint();
> }
> {code}
> What I _expected_ to happen was:
>  # A pre-signed URL is created with the blob I pass it.
>  # The blob's content-md5 and content-length values are passed through as part of the signed headers.
>  # The pre-signed URL includes these values so that only a specific file (or something that has exactly that checksum and content length) can be uploaded to said URL.
> What _did_ happen was:
>  # A pre-signed URL is created with the blob I pass it.
>  # {{RestAnnotationProcessor}} and the default {{S3Client}} API both seem to not take any of the blob metadata into account
>  # The pre-signed URL includes only the {{host}} header as a signed header.
> As a result, I can upload any file I wish to the pre-signed {{PUT}} URL, not just the one that I specifically intended, although metadata like content checksum and length is available and could also be signed within the request.
> For what it's worth, I did try to extend the existing {{BlogRequestSigner}} to include {{PutOptions}} (which have an effect on signed headers, as far as I can tell, see: {{[RestAnnotationProcessor#apply:282|https://github.com/apache/jclouds/blob/master/core/src/main/java/org/jclouds/rest/internal/RestAnnotationProcessor.java#L282]}}), but got lots of Guice binding errors that I was unable to resolve. I am relatively new to Guice, so that might have been user error - as the documentation is lacking though, I'm unsure if that's the preferred way.
> Lastly, https://issues.apache.org/jira/browse/JCLOUDS-1161 exists which seems loosely related to my issue. As I understand it though, the "workaround" described therein should no longer be necessary (since V4 is automatically used for {{aws-s3}} since ~{{2.2.0}}) and it does not help in my case either.
> Is the current behaviour, as described above, correct? Is the lack of a support for additional signed headers intentional? Is there another way that I'm not quite seeing?
> Any feedback would be greatly appreciated.



--
This message was sent by Atlassian Jira
(v8.3.4#803005)