I've read multiple times that leaked ETags from Webservers are considered an information leakage vulnerability.

For example in the server response headers:

ETag: X/"1234-56789"

But I have not found a reason why this is a problem or how this may be abused.

Of course any additional information that is not required for the application to function should be redacted, but what's the damage a a leaked ETag (therefore inode) can do?

Edit: Rapid7 for example see's this as with a severity of four.

up vote 6 down vote accepted

The ETag header is used for effective caching of server side resources by the client. The server send an ETag header in the HTTP response to some string and the client caches the response content and associates the string given in the ETag header with it. If the client wants to access the same resource again it will send the given string within some If-None-Match header in the HTTP request and the server will only return the full content if the resource has been changed and otherwise tell the client that the cached content can be used. See Wikipedia for more details.

This means, that every client can get such an ETag header from the server, i.e. the value of the header is not secret. Thus contrary to your question the leakage of such a header itself is not the problem.

The problem is instead if the value of the header (i.e. the string) provides information about the server which should stay secret. Often the value of the header is just a hash over the content of the resource which is not a problem at all. But for example the Apache web server can base the ETag on the inode number, last modification time and/or size of the file. Using these meta information a unique ETag can be created much faster compared to computing the hash of the content. Only, at least the inode number is considered internal information to the server and should not be exposed to the client. While not be usable in attacks directly knowledge of lots of inode numbers can be used to gain for example information about the underlying file system which might help in further attacks against the server.

This means that the inode number should not be extractable from the ETag header because it should stay secret. This was fixed with Apache 1.3.27 (long ago), i.e. the inode number is still used to compute the ETag but in a way that it cannot be extracted from the ETag value.

Edit: Rapid7 for example see's this as with a severity of four.

The CVSS score is computed from several parts. The details for this specific problem can be seen here but it essentially boils down to that it is trivial to use, can be done over the network, needs no authentication and provides some internal information about the server.

  • Thank you for the extensive answer! How can you differentiate between an ETag leaking internal information and an ETag using irrelevant data? For example nikto reported a leaked inode: + Server leaks inodes via ETags, header found with file /, fields: 0x0123 0xCh1egT4IuhBcS1sKdO2LdGK4ulc (values have been randomized) – Breakfast Serial May 25 at 6:09
  • 1
    @BreakfastSerial: You cannot say for sure. These scanners use heuristics only, i.e. (often very simple) pattern which look like something which was known to leak information. And because of this they often report false positives, see ETag leaking inodes false positive #469. Don't put too much trust into scanners, both because they report problems which are not there and similar because they don't find all real problems. – Steffen Ullrich May 25 at 7:06
  • I see, thank you for the response! – Breakfast Serial May 25 at 7:41

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.