commit 3a8f5dbf9c49fdf1cf2d0b7ba35b82f25f88e634
Author: Tim Burke <email address hidden>
Date: Tue Dec 11 15:29:35 2018 -0800
Verify client input for v4 signatures
Previously, we would use the X-Amz-Content-SHA256 value when calculating
signatures, but wouldn't actually check the content that was sent. This
would allow a malicious third party that managed to capture the headers
for an object upload to overwrite that with arbitrary content provided
they could do so within the 5-minute clock-skew window.
Now, we wrap the wsgi.input that's sent on to the proxy-server app to
hash content as it's read and raise an error if there's a mismatch. Note
that clients using presigned-urls to upload have no defense against a
similar replay attack.
Notwithstanding the above security consideration, this *also* provides
better assurances that the client's payload was received correctly. Note
that this *does not* attempt to send an etag in footers, however, so the
proxy-to-object-server connection is not guarded against bit-flips.
In the future, Swift will hopefully grow a way to perform SHA256
verification on the object-server. This would offer two main benefits:
- End-to-end message integrity checking.
- Move CPU load of calculating the hash from the proxy (which is
somewhat CPU-bound) to the object-server (which tends to have CPU to
spare).
Reviewed: https:/ /review. openstack. org/629301 /git.openstack. org/cgit/ openstack/ swift/commit/ ?id=3a8f5dbf9c4 9fdf1cf2d0b7ba3 5b82f25f88e634
Committed: https:/
Submitter: Zuul
Branch: master
commit 3a8f5dbf9c49fdf 1cf2d0b7ba35b82 f25f88e634
Author: Tim Burke <email address hidden>
Date: Tue Dec 11 15:29:35 2018 -0800
Verify client input for v4 signatures
Previously, we would use the X-Amz-Content- SHA256 value when calculating
signatures, but wouldn't actually check the content that was sent. This
would allow a malicious third party that managed to capture the headers
for an object upload to overwrite that with arbitrary content provided
they could do so within the 5-minute clock-skew window.
Now, we wrap the wsgi.input that's sent on to the proxy-server app to
hash content as it's read and raise an error if there's a mismatch. Note
that clients using presigned-urls to upload have no defense against a
similar replay attack.
Notwithstanding the above security consideration, this *also* provides to-object- server connection is not guarded against bit-flips.
better assurances that the client's payload was received correctly. Note
that this *does not* attempt to send an etag in footers, however, so the
proxy-
In the future, Swift will hopefully grow a way to perform SHA256
verification on the object-server. This would offer two main benefits:
- End-to-end message integrity checking.
- Move CPU load of calculating the hash from the proxy (which is
somewhat CPU-bound) to the object-server (which tends to have CPU to
spare).
Change-Id: I61eb12455c3737 6be4d739eee55a5 f439216f0e9
Closes-Bug: 1765834