I'm curious, how would this allow an attacker to read arbitrary files in the server web directory?
Wouldn't the attacker need another vulnerability to actually read arbitrary files?

@intrigus-lgtm Yes, directory listing itself only enables filename and path disclosure directly.

While it's a common practice to hide the suffix of the real implementation in J2EE applications. For example, use ".xhtml" files to store application code in JBoss Seam applications then map these files to an arbitrary suffix like the widely used ".do". Normal access of ".do" actions will render dynamic contents while accessing ".xhtml" files directly will download the source code. One website I audited in the past has this vulnerability of directory listing thus allows downloading/viewing all source code of that application. That is what I meant reading arbitrary files in the server web directory. However, a properly configured application with additional safeguards will prevent downloading/viewing those .xhtml files. Thus I used the phrase "could allow".

Another possibility is that applications could have hidden configuration files storing credentials e.g. those connecting to a database or REST APIs, which could disclose sensitive information if they have an extension like "txt" or "config". Or applications could have some other types of private files like backup files ending with postfixes like "bak" or "git" that won't be rendered by the J2EE engine thus can have their contents disclosed through directory listing.

In summary, directory listing do not necessarily constitute a serious security vulnerability and commonly requires a MIME type mapping issue to actually read arbitrary files, which is typically exploitable in J2EE applications like the Seam example I mentioned above because additional protection mechanisms need to be explicitly configured.

Directory listing shall be disabled in the production environment in order not to expose information through directory listing, which enables launching further attacks. Java web applications typically host dynamic contents and I don't see how directory listing can be useful to any application. Java web servers used to have directory listing enabled by default but in recent years it's common to be disabled by default, which aligns with best practices of security.

@luchua-bc

Created Hackerone report 909374 for bounty 225682 : [111] Java : CWE-548 - J2EE server directory listing enabled
🎉

Thanks @xcorail a lot for the quick turnaround and the bounty:-)

@xcorail @luchua-bc Pardon my arrogance but I believe this issue is at best a joke if not spam. The query detects cases were directory listing is publicly visible. This by itself does not even count as a normal bug.

Consider the following directory structure. If the said config parameter is enabled and not other route is configured to handle the /static route, the attacker would be able to know that there are two js files named as jquery.js and script.js. That's all the query does. This does not even qualify as a bug let alone a security issue.

    j2ee_root
    |
    |--home.Do
    |--index.xhtml
    |--static
        |
        |--jquery.js
        |--script.js

When @luchua-bc talks about the source code of apps, I think he means if the source were stored in a non-executable format such as in a compressed zipfile, the attacker MAY be able to download it. The *.do files in the example won't ever be downloaded as J2EE will detect them as executables and run them instead. As for the xhtml files, they are supposed to be public anyways. Also, note that the directory lsiting is not for the entire host but limited to the webserver's web root directory. In my opinion, the only scenario where this would actually be useful is in a CTF where the source code is stored publicly accessible in the same directory as the JS files.

The secrets in the config file and all are covered by Github's secret scanning and are not for CodeQL to handle. There are PR's which were rejected earlier on these grounds. See (here)[https://github.com/github/codeql/pull/3738].

With that said, I seriously believe, that you should reconsider your decision here. I have had multiple queries which actually doing something security related rejected by GHSL. But here is this one most probably having a 99.99% false positive rate awarded with a 1800$ bounty.

@porcupineyhairs I still believe directory listing is a valid issue.

If you google "directory listing vulnerability cve", you will find many valid bugs/reports under this category. Using issues submitted to HackerOne as an example, two recently published reports are #461242 and #438299. All those reports were triaged by the associated companies and awarded as valid issues.

Speaking from my own experience of security researches, I have found high priority issues in this category too.

For your example, the concern is not with public JavaScript files as you said:

        |--jquery.js
        |--script.js

The concern is with files containing Java source code and sensitive configuration information. You misunderstood my .do example. It shall not be the following:

    j2ee_root
    |
    |--home.Do
    |--index.xhtml

Instead it shall be:

    j2ee_root
    |
    |--home.xhtml
    |--index.xhtml

The J2EE container maps .xhtml files to .do then renders pages with code executed when ".do" actions are accessed. With the Seam example I mentioned above, all Java source code is implemented in xhtml files using JSF/Seam tag libraries.

For Java websites created with the 20 years' old JSP technology, yes, directly accessing them will execute code instead of disclosing source code. However, if code is implemented in tag libraries, which became the main stream around 15 years ago, source code could be disclosed if source code files are accessed directly (.xhtml without server mapping in this example) while they are intended to be rendered with a custom extension (.do in this example).

Also it's pretty common to have some hidden files left on the PROD site. E.g. backup files and version files. A good example is .git directories and one discussion can be found here. Although popular directories like the .git directory can be detected through brute-force attacks e.g. with the popular diresearch tool, enabling directory listing enlarges the attack surface and makes attacks both easy and stealthy.

And unfortunately not all developers follow best security practices, there could be a lot of sensitive information left on the PROD site. A quote from the link above is:

An exhaustive scan shows hundreds of thousands of websites potentially exposing sensitive data such as database passwords, API keys and so on.

Hope the explanation answers your questions and helps to address your concerns.

One more comment - CodeQL already has this feature for .NET/IIS, which was committed in August 2018 and can be found at https://github.com/github/codeql/blob/master/csharp/ql/src/Security%20Features/CWE-548/ASPNetDirectoryListing.ql.

Query in this issue/PR made the Java version have the same feature consistently.