6 ms·

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

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?

gskourou 6y ago
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-parameterized-statement-stop-all-sql-injection https://stackoverflow.com/questions/6786034/can-parameterize...
grey-area 6y ago
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.
- nkozyra 6y ago
  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.
  - grey-area 6y ago
    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.
viraptor 6y ago
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 https://portswigger.net/web-security/access-control/idor
acdha 6y ago
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 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.

gskourou 6y ago

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-parameterized-statement-stop-all-sql-injection https://stackoverflow.com/questions/6786034/can-parameterize...

grey-area 6y ago

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.

nkozyra 6y ago
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.
- grey-area 6y ago
  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.

viraptor 6y ago

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 https://portswigger.net/web-security/access-control/idor

acdha 6y ago

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 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.