I prefer to use prepared statement but i'm studiyng defense techniques from SQL injection. I've read that stored procedures are used to limit the database privileges allowing only the execution privilege on the procedures but in some cases can be used to avoid sql injection.
Someone can give me an example using mysql?
Stored procedures has absolutely nothing to do with injections.
To protect from injection, you have to format your SQL properly, be it SELECT query, a procedure call or anything. That. Is. All.
Related
I have an insert query that I want to execute using the JavaScript V3 AWS client, against an AWS Aurora MySQL Serverless database. I am using the Data API of the database. I got the #aws-sdk/client-rds-data set up in my code and I can connect and execute arbitrary SQL queries using the ExecuteStatementCommand.
What I would like to know is that how I make SQL prepared statements and execute them. I have an INSERT query whose values are user provided. I cannot just concatenate those values into the SQL query as it would create an SQL injection vulnerability.
Unfortunatelly, I couldn't find how to make prepared statements and execute them in the #aws-sdk/client-rds-data package's documentation.
If somebody knows how to do it, could that someone please explain. Big thanks in advance!
I'm not a user of the AWS SDK for client-rds-data, but I'm inferring the following from the documentation, and my own knowledge of MySQL.
I see that interface ExecuteSqlCommandInput has a property sqlStatements, which allows multiple SQL statements separated by semicolons. This precludes the use of query parameters, because in MySQL you can't use prepare() on a string that includes multiple SQL statements.
Whereas ExecuteStatementCommandInput has a property sql (a single statement) and a property parameters which is an array of scalar parameters (i.e. each scalar corresponds to one parameter placeholder in the sql string). This should allow you to run a parameterized SQL query.
Re your comment: When you said you wanted to use prepared statements to avoid SQL injection vulnerabilities, I assumed you understood how prepared statements protect against those vulnerabilities.
In fact, using prepared statements alone is not a defense. You have to separate dynamic inputs from your SQL query by using query parameters. It just happens that using query parameters requires using prepared statements, so people say "use prepared statements" to defend against SQL injection, when they should say "use query parameters, which implies you must use prepared statements."
Tutorials about using SQL with query parameters are abundant. Here's one for Node.js: https://www.veracode.com/blog/secure-development/how-prevent-sql-injection-nodejs
The calling convention for the AWS SDK is different, but the concept is the same. I have only found reference documentation for AWS SDK, no code examples or task-oriented documentation. This is disappointing but unfortunately typical for AWS.
As this document says prepared statements are server side statements like functions or procedures (correct me if I'm wrong).
But I have some trouble finding defined prepared statement on my database. I'm currently working with MySQL Workbench and in the left side pane I can see all my procedures and functions and I can't see any of defined prepared statements here.
So is there any query which I can use to get their names?
The doc says
A prepared statement is specific to the session in which it was created. If you terminate a session without deallocating a previously prepared statement, the server deallocates it automatically.
So Prepared Statements get deleted automtically after the session ends. Besides, a Prepared Statement does not have a name It is just a query string.
I'm coming from an Oracle world where I can use DBMS_SQL for dynamic SQL with an unknown number of bind variables. Apparently this is not possible in MySQL. So my question is how do you protect against SQL Injection in MySQL? I thought this would be easy to lookup but every example I find is with PHP & MySQL. I'm only dealing with MySQL stored procedures, no PHP. Here is a snippet:
set #sql_string=concat(#sql_string,'col1=''',someRandomText,''' where col2=''',moreRandomText,''';');
Is there a protection function that could be applied to someRandomText to prevent SQL Injection (http://bobby-tables.com/)?
Thanks!
I need to convince someone that he needs to sanitize the user input in addition to the user of stored procedures. well I know I sound crazy but I do not feel comfortable enough with store procedures only. My first reason is that I am able to cause errors in the stored procedure but because of the fact that the application itself handles errors such that error messages are coded it is difficult for outside to understand the what there are. but I still think that this is not secure.
Does any one has a suggestion ? or am I wrong to doubt stored procedures?
No it's not safe on it's own. You can also do in a stored procedure something like this:
SET #sql = 'Select * from products where name like ''' +#spinput+''' ';
exec(#sql);
With the wrong value in #spinput you can inject code.
However you can write stored procedures that are safe against sql injection.
Even if you use proper parameters, you can still mess with the database. You could insert a script that goes in as a parameter, but when it's displayed on a web page starts doing something it shouldn't. Use parameters to ensure your database is used as intended, but also sanitize the output later - never trust user-entered data.
Using stored procedures normally protects against SQL injection, but is not the only solution to prevent SQL injections, and it doesn't protect against all forms of SQL injection.
It's not the stored procedure itself that makes the big difference, but parameterised queries, which is the most common way to call a stored procedure. By putting the values used by the query in parameters, you let the database library handle them instead of having to escape them correctly yourself.
It's possible to write code that is safe against SQL injections without using parameterised queries, but it's difficult. You have to know exactly what characters you need to escape in a string for the specific database that you are using, and if you get it wrong you are pretty much as unprotected as if you didn't know about SQL injections at all.
If you use parameterised queries, then the step of sending the values into the database is safe from SQL injection, but the query itself might not be. If the query generates and executes SQL code itself, you have the same problem with escaping strings correctly. It's however not so usual to create SQL code in the SQL code, and if you do it you are very aware of that you are doing it.
I have a website using mySQL database and I want to do common tasks like add users, modify their info, etc. I can do it perfectly with regular queries. Im using prepared statements to increment security.
Should I use stored procedures to increment the security or the results will be the same? I though that may be using stored procedures I can restrict the direct interaction that a possible attacker could have with the real query. I'm wrong?
I guess it would depend on what language youre using. Using a prepared statement with a sql string that contains all of the sql to be executed, or using a prepared statement with a sql string that executes a stored procedure are going to be about equivalent in most languages. The language should take care of the security around the prepared statement. C# for example will validate the input, so sql injection vulnerabilities are greatly reduced unless your prepared statement is written so poorly that feeding it bad (but expected, ie, 1 vs 0) variables will dramatically change the result set. Other languages may not provide the same level of validation though, so there may be an advantage depending on exactly what your stored proc looks like.
Using a stored procedure is better for maintainability, but there are not many scenarios where its going to provide any sort of change in security level, assuming the program is properly designed to begin with. The only example i can think of off the top of my head would be a stored procedure that takes raw sql strings from user input, and then executes that sql against the db. This is actually less secure than using a prepared statement unless you went to great lengths to validate the acceptable input, in which case you better have a really good reason for using such a stored proc in the first place.
Basically, what I'm saying boils down to the fact that you're going to need to read the documentation for your language about prepared statements, and determine what vulnerabilities, if any, using prepared statements may have, and whether or not those can be eliminated in your specific scenario by switching to a prepared statement that calls out a stored procedure instead of executing a sql query directly.
The results would be the same (assuming that you set your stored procedure up right).
there appears to be a pretty good write up on it here. Though I would never suggest you try to escape user input yourself. (They mention this as option 3)