Don’t try to sanitize input – escape output

Re:Don’t try to sanitize input – escape output by anonsivalley652 on Thursday February 27, 2020 @04:56AM (#22431993)

Yeah, I "LOL" at these type of One True Way™ proclamatory headlines.

What I don't understand is the lack of using proper escaping functions when generating SQL. Templating SQL without escaping is the surest way to a SQL injection.

--- Bad

    "SELECT * FROM USERS WHERE name = '%'" % (name)

--- Good

    "SELECT * FROM USERS WHERE name = '%'" % sq_esc(name)

    # where sq_esc() doesn't add outer ', but escapes anything that needs it

And to defensive coding:

0. Sanitize input. Always, always.

1. Assert pre-condition invariants.*

2. Process.

3. Assert post-condition invariants.*

4. Generate correct output by understanding the output domain.

* Unit tests, smoke tests, integration tests and code-coverage alone are insufficient to cover complex code paths. Fuzzing with asserted invariants is a good way to shake the dust out of hairy code.

[ Parent | on HN ]

Re:Don’t try to sanitize input – escape output by DelightOne on Thursday February 27, 2020 @05:59AM (#22432258)

Defensive coding makes sense.

What is sql templating used for in the face of parameterized queries?

[ Parent | on HN ]