I've seen that SQL injection strings are often constructed like this:
' ; DROP DATABASE db --
Therefore, if I disallow the use of semicolons in my application's inputs, does this 100% prevent any SQL injection attack?
I've seen that SQL injection strings are often constructed like this:
' ; DROP DATABASE db --
Therefore, if I disallow the use of semicolons in my application's inputs, does this 100% prevent any SQL injection attack?
It MAY stop from injecting a secondary DDL statement like your drop since they'll likely create a syntax error within a select, but it won't stop statements like this:
Return more data than intended
' or 1=1
Delete with output
' or 1 in (select * from (delete someOtherTable OUTPUT DELETED.* ) a)
Injection attacks revolve around ANY manipulation of the intended SQL statement, not just termination of that statement and injecting a second statement.
Injection Attacks Come from Un-sanitized User Input
It's important, however, to not conflate a SQL injection attack entirely with dynamic/inline sql. SQL injection attacks come from UN-SANITIZED USER INPUT used in dynamic sql. You can "build" a query with no problem as long as the components of that query all come from sources that you trust. For example we use schemas to hold custom structures...
$"select * from {customSchemaName}.EmployeeExtension where id=@id and clientid=@clientId"
The above is still a parameterized query from an input point of view, but the schema name is an internal system lookup that no interface has access to.
I make the case for inline/dynamic sql here: https://dba.stackexchange.com/a/239571/9798