2

I created an API recently that allows video and audio files to be uploaded and it was working fine until one customer uploaded a large video and I got this error:

Failed to read the request form. Multipart body length limit 134217728 exceeded.

From many posts it's evident that the philosophy behind request size limitation is to reduce the chances of DDoS attack. (Please correct me if I'm wrong).

However, I uploaded a large video myself, and watched the bandwidth both on my local PC and on the server. I have a VPS for this app and I can watch bandwidth using Task Manager's Performance tab, by selecting Ethernet and seeing the graph of send and receive.

The point is, I saw that a high traffic going on for some minutes when I was uploading the file, and then I saw that error. This means that the resources of the server are being consumed even when there ASP.NET Core rejects the request.

So, I don't understand this part. How ASP.NET Core diminishes the chance of DoS, or DDoS attacks by limiting request size, while bandwidth is taken in reality? A logical way would to drop the request from the beginning for multipart/form-data content types if the request payload/body was too huge and even do not consume the bandwidth.

mohammad rostami siahgeli
  • 6,787
  • 9
  • 49
  • 89

1 Answers1

2

Dotnet can only know the size of the file by uploading it (consuming bandwidth in your example).

The solution to this problem is to set a smaller limit for the size of uploaded files.

The way dotnet works, it will stream the file (process it little by little). Once it hits the max upload size, it will return an error.

You are right that this doesn't prevent an attacker from uploading many large files - dotnet will still have to upload/stream them until the max size is reached. The way to mitigate attacks like these is through other means - rate limiting, IP blocking, DDoS protection at the CDN etc

TomDane
  • 1,010
  • 10
  • 25