Go: Why is DotDotCheck modeled as a complete path-injection barrier?

Commencez par DotDotCheck dans TaintedPathCustomizations.qll (lignes 106-122), puis examinez le cas GOOD à la ligne 31 de TaintedPath.go ainsi que les tests de la requête d’injection de chemin Go. Vérifiez comment la branche false devient un isBarrier via SanitizerGuardAsSanitizer, et comparez le comportement attendu avec les indications de filepath.Base. Le travail est terminé lorsque le modèle et les attentes des tests concernés reflètent de manière cohérente la protection prise en charge contre la traversée de chemins.

Description of the issue

The Go go/path-injection query treats !strings.Contains(path, "..") as a complete path-injection sanitizer. This means that when Contains returns false, taint is fully blocked - no additional sanitizer is required.

I'm wondering why this is modeled as a complete barrier, because checking for the absence of ".." does not prevent absolute-path attacks. For example, /etc/passwd does not contain "..", passes the guard, and can read files outside any intended directory.

The query help seems to agree - it says this approach is "only suitable if the input is expected to be a single file name", and also warns that user-controlled paths "may be absolute paths". But DotDotCheck doesn't distinguish between single-component inputs and multi-component paths.

The existing test case at TaintedPath.go line 31 marks this pattern as GOOD with the comment "This can only read inside the provided safe path", but tainted_path = "/etc/passwd" would still pass the check and escape any safe path.

Affected sanitizer

DotDotCheck in TaintedPathCustomizations.qll (lines 106-122) matches strings.Contains(p, "..") and declares the false branch as a complete sanitizer guard. Through SanitizerGuardAsSanitizer, this becomes a full isBarrier node.

Steps to reproduce

func handler(w http.ResponseWriter, r *http.Request) {
    p := r.URL.Query().Get("file")
    if !strings.Contains(p, "..") {
        data, _ := ioutil.ReadFile(p)  // 0 alerts with DotDotCheck enabled
        w.Write(data)
    }
}

Question

Given that !strings.Contains(p, "..") only blocks one specific attack vector and not absolute paths, would it be more appropriate to model it as a non-barrier (or at least not a complete one), similar to how filepath.Base is documented as "not a sanitizer for path traversal" in mime.multipart.model.yml?

Environment

• CodeQL CLI 2.25.6
• CodeQL repository commit: f6f45d1536312f53eed079868e344a5906bf3d72
• Go 1.22.12 on Linux/amd64