Are webservers's file serving safe against timing attacks?

Question

Context

I've been recently looking at UUIDs (mostly v4) and their uses to maybe start using them in some of my apps. I started asking myself some question about security as one does. Then I fell on the Is it safe to rely on UUIDs for privacy? question which led me to Are random URLs a safe way to protect profile photos?.

Simulation

To allow better understanding of my issue, here is how the targeted site would work:

• Some static content files are served publicly in a given folder site.com/uploads/
• The files are publicly accessible but their filenames are cryptographically random hashes like site.com/uploads/rnvaat22suhb1ftc0nxrm9hqfdafzoy4.pdf
  • In this instance, we will assume the dev storing static files in the public space did his due diligence of using cryptographically safest PRNG to generate the file name, making sure they are as "unguessable" as practically possible.
• To prevent the answers from going around the subject, we'll assume the dev cannot implement it in any other way (stupid yes! but spec is spec)

Issue

When comparing anything password-like (here, random file names), the devs implementing the comparison/lookup needs to make sure it is safe against timing attack. The problem is that, most of the time, the dev who placed the files on the server is not the one responsible for coding the web server/OS serving public static files and thus cannot control that part of the problem.

Let's say a bad actor finds out about this site and knows the existence of the public uploads/ folder. I believe timing attacks could be a problem here.

Using the site.com/uploads/rnvaat22suhb1ftc0nxrm9hqfdafzoy4.pdf example:

• Try site.com/uploads/aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.pdf -- 404
• Try site.com/uploads/baaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.pdf -- 404
• ...
• Try site.com/uploads/raaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa.pdf -- 404, but just a bit slower

Knowing that TCP timestamps exists and that HTTP is implemented using TCP. We know the server uptime and can abstract out the network jitter. If the server deactivated TCP timestamps, we could theoretically still be able to guess it by using statistics.

Is this a real and probable problem?

NOTE: I'm not looking for suggestion to "make the app better". I know attack mitigation tactics exist (throttling). They are not the idea here.

Answer 1

Often timing attacks are relevant when the error response can be the same for both a resource that exists and one that doesn't. An example would be checking a user login: if it returns faster when the user doesn't exist than when the user exists but has the wrong password, an attacker can use that to determine which users are in the system. You haven't specified any details about your applications that would have this sort of setup.

Perhaps the thing you're imagining is that someone requests "abcdefg" and it's a bit slower than "abbbbbb" and so they know there must be something that starts with "abc". That's the version of timing attacks commonly talked about in cryptography as applied to password-checking. Again, you haven't specified what your applications might use UUIDs for, but if it's like the linked photo use case, I don't think there's anything to be concerned about.

To really analyze that situation, you'd need to look at the algorithms for accessing files. This is probably less about web servers and more about the operating systems and filesystems. Does ext4, for example, use a hash table type of lookup for files in a directory that causes it to short circuit a little bit sooner for filename prefixes that don't exist? I'm not an expert there, but from what I can recall of my university classes a long time ago, no.

Timing attacks for web services are always difficult anyway because there's a lot of natural jitter caused by the network. To get good signal, you have to submit a lot of requests (enough to be able to use statistics to separate out the jitter noise). Multiplying that by the number of urls to try guessing would require a long and focused attack, and there's a really easy way to stymie that up front: very basic and liberal rate-limiting. Even if you let someone request a thousand times what a normal user would do, that would be plenty to stop this sort of attack.