Two issues were found in the staticweb middleware. They might be just "normal" bugs, but I prefer to start with a private security bug first; however the impact looks rather low to me atm.
1.staticweb middleware does not check acls
The documentation says that a read-acl setting of ".r:*" must be set, however this is never checked in staticweb. At least in combination with tempauth this allows container listings without any ACL set. Note that the staticweb middleware must still be enabled on a container, and this can only done by an account owner (because it requires a POST to the container).
2. Might break clients if used before any auth module in the proxy pipeline
Actually this looks simple at first, but might be a little bit worse then #1. If an operator puts the staticweb middleware before the authentication middleware, it responds with a HTML listing for GET and HEAD requests if this is enabled on a container. In case of python-swiftclient this might lead to a situation where a user thinks there is an empty, private container but actually the container is public readable. Note: the documentation already says to put staticweb after an auth middleware in the pipeline.
For example, using master on swift and python-swiftclient on a SAIO (put staticweb before tempauth in the proxy pipeline to verify this):
# Create a new container and upload an object
vagrant@saio:~/swift$ swift upload container testobj
testobj
# Now in case of python-swiftclient: 0 objects, no ACLs, no enabled web listing
vagrant@saio:~/swift$ swift stat -v container
URL: http://saio:8080/v1/AUTH_test/container
Auth Token: AUTH_tk3f556ba123fe4ac5a17da69b5b99cc22
Account: AUTH_test
Container: container
Objects: 0
Bytes: 0
Read ACL:
Write ACL:
Sync To:
Sync Key:
Content-Type: text/html; charset=UTF-8
X-Trans-Id: tx233a6fd34a184c9e8d455-0055e00bb7
Note that this is still true if there is a public read acl set. Thus it is possible to list and download objects, but in case of python-swiftclient a private empty container is reported. Other clients might be affected as well (due to the HTML response).
A patch to fix both issues has been attached. Overall existing testing could be further improved; for example you can completely remove the read acl and all tests still pass on master.
Two issues were found in the staticweb middleware. They might be just "normal" bugs, but I prefer to start with a private security bug first; however the impact looks rather low to me atm.
1.staticweb middleware does not check acls
The documentation says that a read-acl setting of ".r:*" must be set, however this is never checked in staticweb. At least in combination with tempauth this allows container listings without any ACL set. Note that the staticweb middleware must still be enabled on a container, and this can only done by an account owner (because it requires a POST to the container).
2. Might break clients if used before any auth module in the proxy pipeline
Actually this looks simple at first, but might be a little bit worse then #1. If an operator puts the staticweb middleware before the authentication middleware, it responds with a HTML listing for GET and HEAD requests if this is enabled on a container. In case of python-swiftclient this might lead to a situation where a user thinks there is an empty, private container but actually the container is public readable. Note: the documentation already says to put staticweb after an auth middleware in the pipeline.
For example, using master on swift and python-swiftclient on a SAIO (put staticweb before tempauth in the proxy pipeline to verify this):
# Create a new container and upload an object saio:~/ swift$ swift upload container testobj
vagrant@
testobj
# Expected output saio:~/ swift$ swift stat -v container saio:8080/ v1/AUTH_ test/container 23fe4ac5a17da69 b5b99cc22 65fadd26- 0055e00b95
vagrant@
URL: http://
Auth Token: AUTH_tk3f556ba1
Account: AUTH_test
Container: container
Objects: 1
Bytes: 0
Read ACL:
Write ACL:
Sync To:
Sync Key:
Accept-Ranges: bytes
X-Storage-Policy: default
X-Timestamp: 1440746384.43528
X-Trans-Id: txa77acfe8bd004
Content-Type: text/plain; charset=utf-8
# Now enable listings saio:~/ swift$ swift post -m "web-listings: true" container
vagrant@
vagrant@ saio:~/ swift$ curl http:// saio:8080/ v1/AUTH_ test/container/
[...snipped...the html listing shown now, as expected including "testobj"]
# Now in case of python-swiftclient: 0 objects, no ACLs, no enabled web listing saio:~/ swift$ swift stat -v container saio:8080/ v1/AUTH_ test/container 23fe4ac5a17da69 b5b99cc22 c9e8d455- 0055e00bb7
vagrant@
URL: http://
Auth Token: AUTH_tk3f556ba1
Account: AUTH_test
Container: container
Objects: 0
Bytes: 0
Read ACL:
Write ACL:
Sync To:
Sync Key:
Content-Type: text/html; charset=UTF-8
X-Trans-Id: tx233a6fd34a184
Note that this is still true if there is a public read acl set. Thus it is possible to list and download objects, but in case of python-swiftclient a private empty container is reported. Other clients might be affected as well (due to the HTML response).
A patch to fix both issues has been attached. Overall existing testing could be further improved; for example you can completely remove the read acl and all tests still pass on master.