OWASP Considerations

[marlon-tucker]

Hello

I'm currently attempting to deploy a TUS enabled application into Azure behind a WAF and am running into various issues with how the default OWASP rules are detecting the TUS protocol. I will be referencing Azure here, but under the hood Azure appears to be using ModSecurity along with the standard OWASP CoreRuleSets. Other cloud providers will all have very similar implementations.

Request Body Size Limits

The default policy for azure is to limit request bodies to 128kb and file uploads to 100mb. This limit comes into effect if the WAF is configured to do request body scanning.

File uploads are detected if the request is a multipart/form-data with a part that has a filename attribute.

Azure does have a way to increase these limits, but it's an additional cost feature

TUS uploads files in such a way they get treated as normal requests, and as such they are limited to a chunk size of 128kb.. It's not the end of the world, but equally, not very efficient either.

Content Type for uploads

TUS uploads files using the application/offset+octet-stream, which is not part of the default OWASP ruleset for allowed content types.

https://github.com/coreruleset/coreruleset/blob/v3.1.2/crs-setup.conf.example#L390-L400

application/octet-stream is in the default list of allowed content types.

As far as I can tell, Azure only allows this rule to be enabled or disabled, we can't update the underlying regex string. Personally I am of the opinion limiting content types to an arbitrary subset has limited security benefit but non the less it is what it is.

---

I accept that changing the TUS protocol so it doesn't fall afoul of these detections is going to be near impossible at this stage, however I wanted to shine a light on the issues so they are at least known about and can be taken into consideration in the future.

[Acconut]

Note: I transferred this issue to the repo covering tus v1, as this issue seems to be talking about this version. The tus-v2 repo was not the correct repo because tus v2 works a bit different.

[Acconut]

Thank you for these insights! They are always helpful with discovering the actual issues that arise when deploying tus services.

File uploads are detected if the request is a multipart/form-data with a part that has a filename attribute.

tus never uses the multipart format and, as such, this requirement will never be met. We have decided not to use multipart because for our use cases it does not provide any benefits and would only cause additional complexity.

TUS uploads files using the application/offset+octet-stream, which is not part of the default OWASP ruleset for allowed content types.

Ok, that seems overly restrictive. But again, the content type is now an integral part of the tus protocol.

I accept that changing the TUS protocol so it doesn't fall afoul of these detections is going to be near impossible at this stage, however I wanted to shine a light on the issues so they are at least known about and can be taken into consideration in the future.

Again, thank you for these insights! AFAICT, you are able to work around these issues. tus v2 will not have a pre-defined content type, and therefore the second issues should not be present. However, tus v2 will also not use multipart, so the first issues still needs a workaround.

I hope that helps!

[marlon-tucker]

yeah I expected that would be the response, but it's good to know the content type is not fixed for the v2 protocol.

I'm going to close this issue as there isn't a path to resolve the multipart form data use case. Having to restrict the chunks to 128kb is a pain but it is what it is.

[Acconut]

Having to restrict the chunks to 128kb is a pain but it is what it is.

I just want to let you know that this will likely cause bad upload performance for your application. Such a small chunk size is never a good option.