wsgi should limit max body size of a request

[Nikhil Komawar]

Currently the wsgi server does not check for the size of the body in the request and it could result into someone uploading a really big image or infinite steam of data resulting into DOS attack or bringing down the service all together.

[Mark Washenberger (markwash)]

I can't say for certain, but it seems like people would normally solve this problem at their load-balancer level.

[Dan Prince (dan-prince)]

We never applied the wsgi request size limiting middleware to Glance because Glance does actually need to receive rather large files (images). This middleware was always sort of a "if all else fails" approach anyway because as Mark points out there other places (outside of Glance) where request size attacks might be better guarded against.

If we do add any sort of request size checks to glance we'll need to be sure to exclude requests which actually upload image data.

[Nikhil Komawar (nikhil-komawar)]

I was wondering, now that Glance is moving as a public facing endpoint, if we can have a configurable limit on the size of data. That way a small private deployment of Glance for example one in academic institutions (not behind a proxy) can be safe from human errors too.

[Luke Wollney (luke-wollney)]

This is a known failure and was seen while executing recent functional tests

[Zhi Yan Liu (lzy-dev)]

I think we have two ways could go for this issue:

1. To document this issue in operation document to make operator aware this potential issues (e.g. DDOS, memory overflow), and as a solution operator should do a such checking on the length of request payload in their load-balancer or front proxy server.

2. Implement a middleware in OpenStack/Glance to check the length on request.

From the perspective to make OpenStack/Glance function be self-contain, I personally trend to think this issue should be covered by a built-in middleware - way #2. But after talking this with Nova API maintainer, from the perspective to see this as a common potential security defect, the result is we see this could be easier solved by operator in the real productive deployment, so way #1 is more suitable for us.

[Ian Cordasco (icordasc)]

So if we are going to choose #1, we need to alert the documentation team. Beyond that, we need to make sure that it's known that we do no validation of the content-length provided by the user. Users expecting an error in those cases will be surprised.

[Ian Cordasco (icordasc)]

Hey Jelly,

We prefer that users allow hudson openstack to assign issues appropriately to avoid confusion. When you submit a review for this bug, it will be assigned to you as expected.

Cheers,
Ian