Go: sanitize simple types in go/request-forgery

[owen-mc]

Should fix this issue.

[Copilot]

Pull Request Overview

This PR refactors the CodeQL Go request forgery analysis to sanitize simple types (numeric and boolean types) that are unlikely to carry taint. It also introduces a shared sanitizer class and deprecates an existing SQL injection sanitizer.

Key changes:

• Creates a new shared SimpleTypeSanitizer class for simple types like numbers and booleans
• Applies this sanitizer to the request forgery detection to reduce false positives
• Deprecates the existing NumericOrBooleanSanitizer in SQL injection analysis in favor of the shared sanitizer

Reviewed Changes

Copilot reviewed 8 out of 8 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
go/ql/lib/semmle/go/security/Sanitizers.qll	New shared sanitizer module with SimpleTypeSanitizer class
go/ql/lib/semmle/go/security/RequestForgeryCustomizations.qll	Adds simple type sanitization to request forgery analysis
go/ql/lib/semmle/go/security/SqlInjectionCustomizations.qll	Deprecates existing sanitizer in favor of shared implementation
go/ql/test/query-tests/Security/CWE-918/tst.go	Adds test case for simple type sanitization
go/ql/test/query-tests/Security/CWE-918/RequestForgery.ext.yml	Test configuration for the new test case
go/ql/test/query-tests/Security/CWE-918/RequestForgery.expected	Updated expected test results
go/ql/lib/change-notes/	Documentation for the changes

[smowton]

LGTM

[owen-mc]

I ran multi-repo analyses before and after. One repo out of the 1000 had alert changes: we go from 26 to 21 results on valyala/fasthttp, which all go through this function which examines a string byte by byte and escapes certain characters. This isn't what I thought the sanitizer would do, but it is good because this is an escaping function.