Missing TaintedSql for tainted integers

[cgocast]

This code snippet https://psalm.dev/r/0d4f65473b is a slight modification of the snippet given in the TaintedSql documentation https://psalm.dev/docs/running_psalm/issues/TaintedSql/ The cast to string has been changed to a cast to int.

An attacker could delete thousands of users from the table by doing multiple GET requests with a range of "user_id". Therefore I would expect that Psalm raises a TaintedSql, even if this code snippet is not vulnerable to classical SQL injection.

I'll write a PR to fix this issue.

[psalm-github-bot]

I found these snippets:

https://psalm.dev/r/0d4f65473b

<?php //--taint-analysis

class A {
    public function deleteUser(PDO $pdo) : void {
        $userId = self::getUserId();
        $pdo->exec("delete from users where user_id = " . $userId);
    }

    public static function getUserId() : int {
        return (int) $_GET["user_id"];
    }
}

Psalm output (using commit 4746f83):

No issues!

[orklah]

You may want to look at #6993

I assumed back then that some types could not transmit taints, the rule may be more complex than that then

[cgocast]

Thank you @orklah for the interesting link.

In my opinion, which type transmit taints or not depends on the issue. For instance, numerics shoud transmit taints for TaintedSql, but they should not for TaintedHtml.

Of course there will be some specific SQL queries where integers are safe. But I prefer those cases to be handled with a @psalm-taint-escape sql annotation