I've just added support for a `literal-string` type to Psalm:
https://psalm.dev/r/9440908f39
This will remain whether or not the RFC passes, but if it passes the
is_literal check will be used to inform Psalm in a similar fashion to how
array_is_list (coming in 8.1) will inform Psalm's list array type.
Adding the literal-string type guard to our main SQL creation endpoint
identifies roughly 20% of all DB queries that would _not_ pass the
`is_literal` check, and would need to use some sort of explicitly unsafe
endpoint. From my perspective biggest issue with the current approach is
that
implode(', ', [1, 2, 3])
is treated as non-literal. We have a lot of queries that look like
WHERE `foo` IN (' . implode(', ', self::ALLOWED_IDS) . ')'
and these would all have to take the "unsafe" path, which is a bit
annoying. Could you add the same flag to ints, or is that too hard?
On Sat, 12 Jun 2021 at 13:00, Craig Francis <cr...@craigfrancis.co.uk>
wrote:
> Hi Internals,
>
> I'd like to start the discussion on the is_literal() RFC:
>
> https://wiki.php.net/rfc/is_literal
>
> is_literal() brings a proven way to identify Injection Vulnerabilities to
> PHP, already used by Google in their Java and Go projects, and is currently
> being added to JavaScript. It's a lightweight and simple approach:
> "Distinguishing strings from a trusted developer from strings that may be
> attacker controlled", allowing Libraries to identify the mistakes made by
> the thousands of developers using them incorrectly.
>
> When Libraries use is_literal() to protect against these mistakes, we can
> trust their output, and (as covered in the Future scope section) PHP can
> then raise warnings with certain native functions like PDO::query,
> mysqli_query, exec, preg_match, etc. (we would only consider warnings,
> anything stricter like exceptions would be in many years time, if at all -
> the intention is to alert and inform people, not break things).
>
> The length is due to the FAQ Section, on why it's needed, how it can be
> used by Libraries, and the important differences of using this flag versus
> the flawed Taint Checking approach with its false sense of security
> (error-prone escaping).
>
> Thanks,
> Craig Francis
>
>
> PS: If anyone wants to discuss face-to-face on Zoom, I'll be available (UK
> Time/BST/UTC+1) at:
>
> https://chat.craigfrancis.co.uk/
>
> Saturday 12th June, 6pm to 8pm;
> Sunday 13th June, 10am to Midday;
> Monday 14th June, 5pm to 7pm;
> Tuesday 15th June, 9pm to 11pm;
> Thursday 16th June, 10am to Midday;
> (other times on request)
>
