@pwntester Sorry this PR didn't get more attention. I've fixed up the formatting problem that was stopping CI from running properly (though it did take 3 attempts). Do you think this should be merged? Could you add a test, possibly based on the code you put in the PR description? Also, I find it confusing that the title says "should not sanitize" but the change adds a sanitizer.

@owen-mc As I understand it, this is adding a sanitizer to SafeUrlFlow, which is used to discard sinks considered "safe" in the SSRF query. Safe sinks are those that have flow coming from a part of a request that is not user-controllable (e.g. the host or full URL, since those are determined by the destination server that hosts the application, and thus can't be arbitrarily set by an attacker). In other words, adding a sanitizer to SafeUrlFlow is removing a "sanitizer" from the SSRF query.

In this case, @pwntester wants to mark flows coming from a part of the request URL as unsafe. So, for an incoming request like:

https://application.server.safe.com/path?can=be&user=controlled#this-too

The scheme, authority, and possibly path of the URL can't be arbitrarily set, so they are sources of SafeUrlFlow. On the contrary, the query and fragment parts of the URL are user-controllable, so slice accesses on the full URL path can be considered sanitizers of SafeUrlFlow.

@pwntester or anyone, please correct me if I'm wrong, since this is my first time looking at the Go SSRF query and libraries 😄.

Thanks @atorralba (could not have explained it better with my own words 😄)