Allows say on MySQL database (whether it matters).
You're only safe from SQL injections should you consistenly use parameterized queries. You're nearly safe from SQL injections if you are using proper getting away everywhere (but there might be, and it has been, bugs within the getting away programs, so it is not as foolproof as parameters).
Should you call a saved procedure, adding the arguments by concatenation, I'm able to still give a random query in the finish of among the input fields - for instance, for those who have CALL CheckLogin @username='$username', @password='$password', using the $-things representing directly concatenated variables, nothing stops me from altering the $password variable to see "' DROP DATABASE --".
Clearly, should you cleanup the input in advance, this adds to stopping SQL injection, but this could potentially remove data that should not happen to be washed.
No, you won't be completely safe. As others have pointed out, parameterized queries will always be what you want -- regardless of how you are being able to access the database.
It's a little of the urban legend by using procs you are safe. I believe the main reason individuals are under this delusion happens because many people think that you'll call the procs with parameterized queries out of your code. But when you do not, if for instance you need to do something similar to the below, you are available:
SqlCommand cmd = new SqlCommand("exec @myProc " + paramValue, con); cmd.ExecuteNonQuery();
Because you are using unfiltered content in the consumer. Once more, all they need to do is terminate the road (""), add their harmful instructions, and boom -- you are hosed.
(Being an aside, if you are on the internet, do not take unfiltered junk in the query string from the browser -- that causes it to be absurdly simple to do very bad items to your computer data.)
Should you parameterize the queries, you are in far better shape. However, as others here have pointed out, in case your proc continues to be producing dynamic SQL and performing that, there might be issues.
I ought to observe that I am not anti-proc. Procs can be quite useful for fixing certain issues with data access. But procs are not a "silver-bullet means to fix SQL injections.
It is dependent what your saved procs do. When they dynamically generate SQL according to their parameters, after which execute that SQL, then you are still vulnerable. Otherwise, you are far more prone to be fine - however i hesitate to seem 100% confident!
not a chance. If you are creating SQL that creates a saved procedure you are still a target.
You ought to be creating parametized queries around the client side.
No, while you could still use D-SQL inside your saved methods... and validating and restricting your input may be beneficial regardless.
Saved Methods aren't an assurance, because what's really vulnerable is any dynamic code, which includes code inside saved methods and dynamically produced calls to saved methods.
Parameterized queries and saved procs known as with parameters are generally invulnerable to injection as lengthy because they avoid using arbitrary inputs to create code. Observe that there's lots of dynamic code also is not susceptible to injection (for example integer parameters in dynamic code).
The advantages of a largely (I am unsure 100% is actually possible) saved procs-based architecture, however, is the fact that injection can also be somewhat defended against (although not perfectly) for dynamic code in the client side because:
Only Professional permissions are granted to the user context the application is hooking up under, so any Choose, Place, UPDATE, Remove queries only will fail. Obviously, DROP etc shouldn't be permitted anyway. So any injection would need to be as Professional, so ultimately, only procedures that you've defined inside your SP layer may even be accessible (not arbitrary SQL) to inject against.
Among the numerous other advantages of determining your database services as some saved methods (like every abstraction layer in software) are a chance to refactor your database underneath without having affected applications, a chance to better understand and monitor the usage designs inside your database having a profiler, and a chance to selectively optimize inside the database without needing to deploy new customers.