Background: I'm using Node-Red to accept potentially untrusted input and subsequently place that data in a Microsoft SQL Server database table. Whilst my environment is internal only, I would still like to protect against an internal malicious actor attempting to do silly things. Node-Red MSSQL modules do not protect against SQL injection at all, and I don't trust myself to adequately perform sanitation / catch edge cases.
I have seen some advice that using prepared statements with MySQL will go a long way to alleviating SQL Injection attacks, meaning that a variable set to '; DROP mytable; will not in fact drop mytable but rather treat that potential statement as a string. I have, however, been able to find very little readable / understandable information on using prepared statements with SQL Server.
That said, I was able to use the example insert statement below, so assume the advice may well be the same.
So the question is: can I use something like the following to alleviate the risk of SQL injection with Microsoft SQL Server?
INSERT INTO [DBName].[dbo].[User_Details]
(First_Name,
Last_Name,
Primary_Phone,
Secondary_Phone,
Email,
Organisation,
Home_Region,
Role)
VALUES ('Potato',
'Head',
'0444444444',
'0411111111',
'potato.head#myorganisation.com',
'My Organisation',
'State Office',
'Chief Ape')
If I cannot, are there other suggestions? There is no ORM available so far as I can tell, and I'm wary of regex sanitising etc as my ability to cover edge cases is probably not great.
Related
I started to learn Java a month ago.
Today I was studying some SQL phrases which are necessary for creating websites using JSP and Servlets.
I used SQL Developer and JDBC.
After doing some insert/delete/update manipulation, I accidentally clicked on 'commit' instead of 'roll back'.
So some of my data in certain tables are lost and so am I...
I think I must delete and re-install JDBC to have all the basic data that Oracle offers.
But I'd like to ask for some help here before doing that, if there is any simpler way.
Can anyone help me please?
Thank you in advance.
I am not sure if it will help but here is the SQL I used:
INSERT INTO DEPARTMENTS VALUES(280, 'DataAnalytics', null, 1700);
INSERT INTO DEPARTMENTS (DEPARTMENT_ID, DEPARTMENT_NAME, MANAGER_ID,
LOCATION_ID) VALUES(280, 'DataAnalytics', null, 1700);
UPDATE emps SET SALARY=30000WHEREEMPLOYEE_ID=101;
UPDATE EMPS SET (JOB_ID, SALARY, MANAGER_ID)= (SELECT JOB_ID, SALARY,
MANAGER_ID FROM EMPS WHERE EMPLOYEE_ID=108) WHERE EMPLOYEE_ID=109;
DELETE FROM EMPS WHERE EMPLOYEE_ID=108; DELETE FROM EMPLOYEES WHERE
EMPLOYEE_ID=103;
I think you may be confusing JDBC with SQL. JDBC is short for Java Database Connectivity, and it's a Java standard used to connect from Java to relational databases (See Oracle's documentation on JDBC here: https://docs.oracle.com/en/database/oracle/oracle-database/18/jjdbc/introducing-JDBC.html#GUID-864DB502-5E50-4044-8132-33D6AAF8927A). Depending on what version of the Oracle Database you're running, the JDBC driver version, and which client you're using, you may find that you are missing some functionality, but that functionality is probably completely separate from the SQL you ran.
When you use SQL Developer to connect, you may be using a JDBC connection, but in all likelihood, you are using either a Basic or TNS Connection Type. Those do not rely on JDBC. The SQL you ran from SQL Developer modified the data because that's what SQL is used for. SQL is short for Structured Query Language, and it's widely used to manage data in relational databases.
By using SQL Developer, you should have access to all of the standard functionality that Oracle has to offer. You may be missing some features, but that is completely normal if you or your organization does not have a licensing agreement with Oracle and have not configured those features. Reinstalling JDBC won't change that.
What are you trying to accomplish? If you want to restore your data, JDBC has nothing to do with that. You will have to either: 1. Flashback the database or table (depending on which version of Oracle you're running,) which will restore the database (or the relevant object(s)) back to a specific point in time before you executed those SQL commands. 2. Use OEM or RMAN to restore the database to a time before you executed those SQL commands, or 3. Delete the relevant data and re-create (or re-import) your data.
Since you committed the transaction to manipulate that data, these are likely going to be your only options to restore the database how it was. If you know the original values that belong in those tables, I suppose that you could also write up more SQL to change the values back to the original. This may result in your desired outcome, but be forewarned that this method (and option #3) would not be considered a restore, and all of the changes that you made up to that point would still be apart of the transaction history. If that doesn't matter, that may be the easiest route for you to pursue.
On one of my customers sites I think I've found a big security issue.
I found out that when I entered an semicolon ' in the search box, the script threw an sql error. So I started playing...
Entering the SQL command below in the searchbox executes the query:
'+AND+product_description.description+LIKE+'%Computers%
The query is executed on the database!
Is it safe to say that a hacker can do harm with executing selects, inserts and delete queries too? Based on the fact that my query is executed I'm almost sure it should be possible to do harm... Am I right?
Yes, you're right. You should always sanitize the input and not use it directly in such a way, or it's sooner or later will be compromised by SQL injection attacks.
Yes, you are right. This code is open for sql injection attacks.
That definitely is a form of SQL injection, and you're correct in being worried.
However, that alone is not enough to tell whether or not you can do things other than alter the query parameters in unexpected ways. The query might for example be altered to retrieve data from tables not listed in the original query, which might well be bad enough.
I strongly recommend to avoid using string concatenation in building SQL queries, but instead using "prepared statements" which only allow to replace provided placeholders with the user-selected data values. Even there the application would be wise to check the values for at least some sanity before passing them on to the database-
Your site is open to SQL injection attacks, and there is a lot you can do to protect it, but first short term thing I would recommend is create a user-id with only read-rights and use this ID for all queries. Hackers will still be able to extract data from your database, but won't be as easy to update or delete rows or tables...
This question already has answers here:
How does the SQL injection from the "Bobby Tables" XKCD comic work?
(13 answers)
Closed 3 years ago.
Can someone explain SQL injection? How does it cause vulnerabilities? Where exactly is the point where SQL is injected?
Can someone explain SQL injecton?
SQL injection happens when you interpolate some content into a SQL query string, and the result modifies the syntax of your query in ways you didn't intend.
It doesn't have to be malicious, it can be an accident. But accidental SQL injection is more likely to result in an error than in a vulnerability.
The harmful content doesn't have to come from a user, it could be content that your application gets from any source, or even generates itself in code.
How does it cause vulnerabilities?
It can lead to vulnerabilities because attackers can send values to an application that they know will be interpolated into a SQL string. By being very clever, they can manipulate the result of queries, reading data or even changing data that they shouldn't be allowed to do.
Example in PHP:
$password = $_POST['password'];
$id = $_POST['id'];
$sql = "UPDATE Accounts SET PASSWORD = '$password' WHERE account_id = $id";
Now suppose the attacker sets the POST request parameters to "password=xyzzy" and "id=account_id" resulting in the following SQL:
UPDATE Accounts SET PASSWORD = 'xyzzy' WHERE account_id = account_id
Although I expected $id to be an integer, the attacker chose a string that is the name of the column. Of course now the condition is true on every row, so the attacker has just set the password for every account. Now the attacker can log in to anyone's account -- including privileged users.
Where exactly is the point where SQL is injected?
It isn't SQL that's injected, it's content that's interpolated ("injected") into a SQL string, resulting in a different kind of query than I intended. I trusted the dynamic content without verifying it, and executed the resulting SQL query blindly. That's where the trouble starts.
SQL injection is a fault in the application code, not typically in the database or in the database access library or framework.
Most cases of SQL injection can be avoided by using query parameters. See How can I prevent SQL injection in PHP? for examples.
SQL Injection occurs when the user of an application is able to affect the meaning of database query. This often occurs when arbitary strings from user input are concatenated to create SQL which is fed to the database. For example lets say we had the following code (in PHP, but the same holds true for any language), which might be used to handle a user login.
$sql = "SELECT FROM users WHERE username='".$_GET['username']."' AND password='".$_GET['password']."'";
The harm is done when the user enters something like
administrator'; --
... for the username. Without proper encoding the query becomes:
SELECT * FROM users WHERE username='administrator'; -- AND password=''
The issue here is that the ' in the username closes out the username field then the -- starts a SQL comment causing the database server to ignore the rest of the string. The net result is the user can now log in as the administrator without having to know the password. SQL Inection can also be used to execute UPDATE, DELETE or DROP queries and really damage the database.
SQL Injection can be prevented by using parameterised queries, or applying your language/toolkit's escaping functions (such as mysql_real_escape_string() in PHP).
Once you understand SQL Injection you'll get the joke behind this cartoon.
This question has been answered many times on StackOverflow, but it's an important topic for everyone to know about, so I'm not going to vote to close this question.
Here are links to some of my past answers on this topic:
What is SQL Injection?
How do I protect this function from SQL injection?
Are Parameters really enough to prevent Sql injections?
Is SQL injection a risk today?
I also gave a presentation at the MySQL Conference this month, and my slides are online:
SQL Injection Myths & Fallacies
SQL injection is when things that're supposed to be data are treated as SQL code unwillingly.
For instance, if you were to do
mysql_query("SELECT * FROM posts WHERE postid=$postid");
Normally it'd get you the post with a given id, but assume that $postid is set to the string 10; DROP TABLE posts --; all of a sudden, the actual query you're sending is
mysql_query("SELECT * FROM posts WHERE postid=10; DROP TABLE posts --");
This is quite a problem, as you'd be losing your entire posts table due to a malicious user - oh dear.
The easiest way to prevent this is to use prepared statements, for instance through PDO or MySQLi.
The equivalent example in PDO would then be
$statement = $db->prepare('SELECT * FROM posts WHERE postid = :postid');
$statement->bindValue(':postid', $postid);
$statement->execute();
Doing this ensures that the database system knows that $postid is to be treated as data and not code, and will thus be handled appropriately.
SQL injection is where a malicious user will put SQL into input fields to try and run the SQL on your server.
The #1 advice that I adhere to is to use parameterized stored procedures rather than building raw SQL in code.
Stored Procedure parameters don't get executed, making them safe in most cases.
I found this paper to be an extremely good read about SQL injection techniques (link is to PDF): Advanced SQL Injection In SQL Server Applications.
Despite the title saying "Advanced", it's quite readable even if you don't have much knowledge about SQL injection.
To get some general background check out the Wikipedia article on SQL Injection.
In short SQL injection attacks can leave you vulnerable to all manor of database data theft and destruction. The exact details of what can be done to your system depend on the details of the system itself.
Any time you pass input from your users to your database you have a potential injection point. Web applications are often lacking in the this regard, as new programmers often do not understand the risks of handling input from users, and web applications are attacked by very smart people you never thought would find your program.
You will like this article from code project ; )
Summary
Encrypt sensitive data.
Access the database using an account with the least privileges
necessary.
Install the database using an account with the least privileges
necessary.
Ensure that data is valid.
Do a code review to check for the possibility of second-order
attacks.
Use parameterised queries.
Use stored procedures.
Re-validate data in stored procedures.
Ensure that error messages give nothing away about the internal
architecture of the application or the
database.
The point where SQL is injected is any point that your application accepts input from the user.
Whether this becomes a dangerous vulnerability for your web application depends on whether this input is later used as part of an SQL query without properly checking its type and escaping it if necessary.
Without proper escaping, some SQL code 'injected' by the user could be executed by the SQL engine as SQL code, rather than a simple string or value.
How to create a dynamic SQL statement, that will update any table given as one of parameter. Here I believe, i couldn't use "Set Column1 = Value ....." as the columns will differ according to the table.
This is an extremely poor idea. You can create massive havoc with your database doing such a thing. I can't imagine any dba who would allow it. You need to know the specifics of a table to insert into it properly, you need to be aware of what fields are required and what fields have default values. You need to know what kind of information and data types should be in each field so that you do not send bad data to the database. One proc that does all cannot properly check these things and certainly can't ever be properly tested. Further it means permissions must be at the table level which is a poor choice for internal security as well as for SQL injection attacks.
Could you provide more context? Are you executing arbitrary SQL statements from within scripts, such as Perl, PHP, or Python? Are you just trying to get a command-line .sql script working? What database server are you working on?
The solution can vary widely depending on your situation.
I've worked with T-SQL for years but I've just moved to an organisation that is going to require writing some Oracle stuff, probably just simple CRUD operations at least until I find my feet. I'm not going to be migrating databases from one to the other simply interacting with existing Oracle databases from an Application Development perspective. Is there are tool or utility available to easily translate T-SQL into Oracle SQL, a keyword mapper is the sort of thing I'm looking for.
P.S. I'm too lazy to RTFM, besides it's not going to be a big part of my role so I just want something to get me up to speed a little faster.
The language difference listed so far are trivial compared to the logical differences. Anyone can lookup NVL. What's hard to lookup is
DDL
In SQL server you manipulate your schema, anywhere, anytime, with little or no fuss.
In Oracle, we don't like DDL in stored procedures so you have jump through hoops. You need to use EXECUTE IMMEDIATE to perform a DDL function.
Temp Tables
IN SQL Server when the logic becomes a bit tough, the common thing is to shortcut the sql and have it resolved to a temp table and then the next step is done using that temp table.
MSSS makes it very easy to do this.
In Oracle we don't like that. By forcing an intermediate result you completely prevent the Optimizer from finding a shortcut for you. BUT If you must stop halfway and persist the intermediate results Oracle wants you to make the temp table in advance, not on the fly.
Locks
In MSSS you worry about locking, you have nolock hints to apply to DML, you have lock escalation to reduce the count of locks.
In Oracle we don't worry about these in that way.
Read Commited
Until recently MSSS didn't fully handle Read Committed isolation so you worried about dirty reads.
Oracle has been that way for decades.
etc
MSSS has no concept of Bitmap indexes, IOT, Table Clusters, Single Table hash clusters, non unique indexes enforcing unique constraints....
I get the impression most answers focus on migrating an entire database or just point to some differences between T-SQL and PL/SQL. I recently had the same problem. The Oracle database exists, but I need to convert a whole load of T-SQL scripts to PL/SQL.
I installed Oracle SQL Developer and ran the Translation Scratch Editor (Tools > Migration > Scratch Editor).
Then, just enter your T-SQL, choose the correct translation in the dropdown-list (it should default to 'T-SQL to PL/SQL'), and convert it.
I have to things to mention.
1) When I worked on Oracle 8, you could not do "Select #Result", you had to instead use the dummy table as follows "Select #Result from dual". Not sure if that ridiculousness still exists.
2) In the Oracle world they seem to love cursors and you better read up on them, they use them all the time AFAICS.
Good luck and enjoy,
it is not that different to MS SQL. Thankfully, I do not have to work with it anymore and I am back in the warm comfort of MS tools.
If you replace your ISNULL and NVL nonsense with COALESCE, it'll work in T-SQL and PL/SQL!
It's not trivial to map them back and forth, so I doubt there's a tool that does it automatically. But this link might help you out: http://vyaskn.tripod.com/oracle_sql_server_differences_equivalents.htm
The most important differences for plain T-SQL are:
NVL replaces ISNULL
SYSDATE replaces GETDATE()
CONVERT is not supported
Identity columns must be replaced with sequences <-- not technically T- or PL/ but just SQL
Note. I assume you do not use the deprecated SQL Server *= syntax for joins
#jodonell: The table you link to is a bit outdated, oracle has become somewhat more standards compliant after 9i supporting things like CASE and ANSI outer joins
I have done a few SQL server to oracle migrations. There is no way to migrate without rewriting the backend code. Too many differences between the 2 databases and more importantly differences between the 2 mind sets of the programmers. Many managers think that the 2 are interchangeable, I have had managers ask me to copy the stored procedures from SQL server and compile them in oracle, not a clue! Toad is by far the best tool on the market for supporting an oracle application. SQL developer is ok but was disappointing compared to toad. I hope that oracle will catch their product up to toad one day but it is not there yet. Have a good day :) chances are if you are migrating to oracle it is for a reason and in order to meet that requirement you will need to rewrite the back end code or you will have many issues.
In Oracle SQL Developer, there is a tool called Translation Scratch Editor. You can find it from Tools > Migration.
The Oracle SQL Developer is a free download from Oracle and it is an easy install.
If you're doing a one-off conversion, rather than trying to support two versions, you must look at Oracle Migration Workbench. This tool works with Oracle's SQLDeveloper (which you really should have if you are working with Oracle). This does a conversion of the schema, data, and some of the T-SQL to PL/SQL. Knowing both well, I found it did about an 80% job. Good enough to make it worth while to convert the bulk of procedures, and hand convert the remainder "tougher" unknown parts.
Not cheap ($995) but this tool works great: http://www.swissql.com/products/sql-translator/sql-converter.html
A few people have mentioned here converting back and forward. I do not know of a tool to convert from MSSQL to Oracle, but I used the free MS tool to convert a Oracle db to MSSQL and it worked for me and converted a large db with no problems I can call. It is similar to the Access to MSSQL tool that MS also provide for free. Enjoy
jOOQ has a publicly available, free translator, which can be accessed from the website here: https://www.jooq.org/translate
It supports DML, DDL, and a few procedural syntax elements. If you want to run the translation locally via command line, a license can be purchased and the command line works as follows:
$ java -cp jooq-3.11.9.jar org.jooq.ParserCLI -t ORACLE -s "SELECT substring('abcde', 2, 3)"
select substr('abcde', 2, 3) from dual;
See: https://www.jooq.org/doc/latest/manual/sql-building/sql-parser/sql-parser-cli
(Disclaimer, I work for the vendor)