A little part of this is similar to my PR #3881
(The PathCreation stuff)

A little part of this is similar to my PR #3881
(The PathCreation stuff)

Thanks for the update. Seems like your PR covers the PathCreation part so I will update this PR before a merge.

This looks like a good approach. Could you make the naming of those new library files consistent? Some have a Lib suffix while others don't. Personally I'd drop the Lib bit.

This looks like a good approach. Could you make the naming of those new library files consistent? Some have a Lib suffix while others don't. Personally I'd drop the Lib bit.

I have dropped the Lib suffix from the new libraries.

ResponseSplittingLocal.ql and UrlRedirectLocal.ql don't compile, hence the PR check failure.

ResponseSplittingLocal.ql and UrlRedirectLocal.ql don't compile, hence the PR check failure.

Was just about the ask about the failing Pull-Request-Check.
Will look into those.

It seems that they are not covered by a unit test.
Will see if I can add those.

Which parts of LdapInjection[Lib].qll are expected to be reusable?

The SqlInjection[Lib].qll file should not be exposed in its entirety. It should be split in two files with the configuration and the queryTaintedBy predicate kept in a .qll next to the queries. Furthermore, once the top half of the file becomes importable we should make sure that it starts with import java as the very first import (and remove the subsequently superfluous import semmle.code.java.Expr).

This what I would like to discover through this PR. In the other libraries there are also private predicates that I would like to split out, but haven't yet because I wanted first to validate the approach.

The end-goal would be to only have extensible elements in these libraries.

Which parts of LdapInjection[Lib].qll are expected to be reusable?

The goal was the LdapInjectionSink, but I have to reconsider my assessment because it is not an abstract class.

The goal was the LdapInjectionSink, but I have to reconsider my assessment because it is not an abstract class.

In that case, consider splitting the file such that the query specific parts are moved to the query and the sink is refactored as an importable abstract class.

This what I would like to discover through this PR. In the other libraries there are also private predicates that I would like to split out, but haven't yet because I wanted first to validate the approach.

The approach is fine, it just needs individual care and attention for each query, as we don't necessarily want to expose everything, and once we expose something the quality requirements to the QL code goes up.

(I've only reviewed a few of the files - I have a lot more review comments coming)

This what I would like to discover through this PR. In the other libraries there are also private predicates that I would like to split out, but haven't yet because I wanted first to validate the approach.

The approach is fine, it just needs individual care and attention for each query, as we don't necessarily want to expose everything, and once we expose something the quality requirements to the QL code goes up.

Given that, I will continue and ensure that only the extensible parts remain in the libraries to prevent unnecessary exposure.

Given the scope of this, perhaps it would be easier to review and merge if we split this up into several PRs - with one PR for each CWE directory?

Given the scope of this, perhaps it would be easier to review and merge if we split this up into several PRs - with one PR for each CWE directory?

Sounds good. I will split it up in a PR per CWE directory.

Sounds good. I will split it up in a PR per CWE directory.

Minor convenience thing: Please include "Java: " as a prefix in the PR titles.

This PR will be split into one PR per CWE directory.