## Injection-Type Vulnerability Restrictions

### Predefined Vulnerability Types (only identify the following types)

* `COMMAND_INJECTION`
* `SQL_INJECTION`
* `PATH_TRAVERSAL`
* `INSECURE_FILE_UPLOAD`
* `SSRF`
* `FORMAT_STRING_VULNERABILITY`
* `BUFFER_OVERFLOW`
* `NOSQL_INJECTION`
* `CSV_INJECTION`
* `XXE_INJECTION`

## Security Knowledge
### Vulnerability Rules and Boundaries
* For COMMAND_INJECTION
  * Concatenation/execution of commands.
* For SQL_INJECTION
  * Only focus on string concatenation parts.
  * Do not assume ORM is safe by default; analyze based on specific code.
  * ORM typically precompiles when passing values, but cannot precompile and protect against structural elements like column names, table names, sorting, etc.
* For PATH_TRAVERSAL
  * The trigger point must be an "actual file operation" (read/write/create/delete).
* For SSRF
  * Requires controllable parameters to initiate an HTTP request.
* For FORMAT_STRING_VULNERABILITY:
  - The trigger point must be a format output function (`printf`, `sprintf`, `fprintf`, etc.).
  - Only report a vulnerability when user input is directly used as the format string argument.
  - User input as the value of a format argument (e.g., `printf("%s", user_input)`) is not a vulnerability.
  - There must be actual memory read/write risk (e.g., using `%n` for writing or `%s` for reading).
  - `printf(user_input)` -- user input directly as the format string.
  - `sprintf(buffer, user_input, arg1)` -- user controls the format string.
* For BUFFER_OVERFLOW:
  * The trigger point must be a memory operation function or string operation function (`memcpy`, `strcpy`, `sprintf`, `wcscpy`, `wcscat`, `strcat`, etc.).
  * Only report a vulnerability when the source data length may exceed the target buffer size.
  * There must be a clear size mismatch or lack of bounds checking.
  * Safe bounds-checking functions (e.g., `strncpy` with correct length) are not vulnerabilities.
* For AUTHENTICATION_BYPASS
  * Defects in authentication logic, such as: parameter validation that can be bypassed, predictable password reset links, relying on untrusted fields for validation (e.g., Referer header), missing validation (e.g., validating username but not password, allowing empty passwords, fixed passwords, super sessions), session credential generation lacking randomness and being predictable (e.g., generated based on user ID), etc., which could lead to authentication logic bypass.
* For HARD_CODED_CREDENIAL
  * Only detect authentication-related credentials, including but not limited to keys, passwords, tokens, etc.
  * Assignment code in global scope is also reported.

### False Positives (do not report)
* Only insufficient parameter validity validation, only printing/logging user input, without calling vulnerability trigger points -- do not report.
* For SQL_INJECTION
  * NoSQL (Mongo, etc.) related calls -- do not report.
  * No direct SQL statement concatenation, using parameterized passing, or escaping taint parameters to defend against SQL injection -- do not report.
* For PATH_TRAVERSAL
  * Only checking whether a file exists, without performing read/write/delete/create operations -- do not report.
  * Only initiating HTTP requests (e.g., `proxy.ServeHTTP`, etc.) unrelated to file operations -- do not report.
  * Only calling cache/database deletion functions like `redis.Client.Del`, not involving the file system.
  * Only calling metadata retrieval functions like `stat`/`lstat`/`fstat`, without subsequent write/create/delete/rename call chains.
  * Only controlling file content, unable to control file path -- do not report.
  * Taint parameters filter directory traversal characters -- do not report.
  * Only calling macro definitions.
  * Log directory initialization only (path is not user-controlled input) -- do not report.
  * Third-party functions that cannot be confirmed as system/common library functions and cannot be proven to perform file read/write operations.
* For SSRF
  * Not calling C or C++ standard library/third-party library to initiate requests -- do not report.
  * Calling custom functions to initiate requests -- do not report.
  * URL is not controllable -- do not report.
  * Taint parameters have URL/IP whitelist validation, cannot arbitrarily initiate requests -- do not report.
* For PATH_TRAVERSAL and INSECURE_FILE_UPLOAD
  * Object storage like Amazon S3, OSS, etc. cannot be directory traversed -- do not report.
* For FORMAT_STRING_VULNERABILITY
  * `printf("%s", user_input)` -- user input as a parameter value -- do not report.
  * Only format string constants have issues but are not user-controllable -- do not report.
