How I bypassed Cloudflare's SQL Injection filter

Re:How I bypassed Cloudflare's SQL Injection filter by Snitch-Thursday on Friday September 18, 2020 @03:46PM (#24521127)

So...if I naively parameterize the inputs for my queries (select blah, blah, blah FROM customers WHERE id LIKE @id) and have the incoming request just check for an id parameter and make a SQL parameter named @id, with value = whatever the input is, am I 90% there?

Or are there still vulns/exploits for that kind of usage?

[ Parent | on HN ]

Re:How I bypassed Cloudflare's SQL Injection filter by viraptor on Friday September 18, 2020 @04:43PM (#24521697)

I'm terms of injection you're 100% there. Parameterised queries are safe (unless there's a bug in the database itself).

It doesn't mean you're safe in other contexts though. For example if you allow reading another user's data without checking permissions, you've got an IDOR vulnerability. https://portswigger.net/web-security/access-control/idor

[ Parent | on HN ]

Re:How I bypassed Cloudflare's SQL Injection filter by grey-area on Friday September 18, 2020 @04:35PM (#24521623)

Another safety measure worth looking at is always enforcing types for params before using them for anything. So if id is an int parse it to an int first. That way you know no extra data/commands can be in the param.

[ Parent | on HN ]

Re:How I bypassed Cloudflare's SQL Injection filter by nkozyra on Friday September 18, 2020 @08:07PM (#24523186)

You don't need to, though, that's what parameterized queries are for. I'd argue that providing out-of-bounds checks like that will increase the likelihood of someone relying on them down the road.

[ Parent | on HN ]

Re:How I bypassed Cloudflare's SQL Injection filter by grey-area on Saturday September 19, 2020 @01:39AM (#24525422)

The boundary for variable parsing should be the edge of your application. Otherwise you can't be sure that your validity checks (for example) are doing what you think they are, or that your sql is doing what you think it is.

As one example of this consider the rails vuln CVE-2013-0156. Lax param parsing and cleaning (or none), can lead to problems like this and even sqli if you meant to accept a string and instead accept something like an array or a symbol.

[ Parent | on HN ]

Re:How I bypassed Cloudflare's SQL Injection filter by acdha on Friday September 18, 2020 @05:10PM (#24521906)

That's most of it: the most common exploits are where someone would shove a quote into a query parameter (e.g. http://example.org/foo/bar/?id=%27%3BINSERT%20INTO%E2%80%A6) to see if you were just concatenating strings.

You can go further by actually validating types (e.g. “id should be a number between 1 and 20 digits”) but I'd class that more as general input validation since you want to do that everywhere even if you don't have SQL database.

[ Parent | on HN ]

Re:How I bypassed Cloudflare's SQL Injection filter by gskourou on Friday September 18, 2020 @04:09PM (#24521358)

I am not sure if parametrized statements solve 100% of your SQLi problems, but I know they at least offer basic protection. I have to study them in order to give you a complete answer, but I found this https://stackoverflow.com/questions/6786034/can-parameterize...

[ Parent | on HN ]