As far as I know, PHP applications are prone to SQL injections when they require user input on a webpage form to send to a variable like $POST or $GET or $REQUEST. Does that mean if my application/htmlpage has no user input forms, it is completely free from SQL injections?
No, ANY user input can cause SQL injections. Say, for example that you perform a SQL query with parameters from the query string. If you haven't sanitized these parameters, you are still prone to SQL injection.
The best thing you can do is to never trust user input and always sanitize
To protect against SQL injection use prepared statements and parameterized queries
see : http://php.net/manual/en/book.pdo.php
Related
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.
I have a textbox in my application in which user will enter where clause to search leads. This conditions will be concatenated to my original search query with AND logical operator in stored procedure of SQL Server 2008.
Is it possible to write DELETE or DROP sub query in that conditions?
You are fighting a losing battle.
Do not try to prevent SQL Injection by black-listing or white-listing contents of input. Instead, use parameterized queries. Then it does not matter what is entered.
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...
Can I avoid all SQL-injection attacks by using parameters?
And don't worry about any thing in SQL injection in this case?
Or are there some types of these attacks which require more care on the part of the programmer?
No, you can't avoid all SQL injection attacks by using parameters. Dynamic SQL is the real issue, and this can occur in stored procedures as well as in your application code.
E.g., this is prone to a SQL injection attack: your parameterized query passes a username to a stored procedure, and within the stored procedure the parameter is concatenated to a SQL command and then executed.
For an example of many kinds of SQL injection attacks, see this SQL Injection Cheat Sheet. You will see that simply escaping single quotes is just scratching the surface, and that there are many ways around that.
Yes and no. Yes, if all of your SQL statements are indeed static and use only parameters, then you're 100% protected from SQL injection attacks.
The problem comes when the parameters themselves are used to construct dynamic SQL statements. An example would be a stored procedure that generates a SQL statement dynamically for querying a multitude of different options, where a single monolithic statement would be impractical. While there are better solutions to this problem, this is a common one.
Yes you can avoid all SQL-injection attacks by using parameters, as long as you use parameters exclusively all the way down the call stack. For example:
Your app code calls a stored procedure or dynamic SQL in the database. That must use parameters to pass all values.
The stored procedure or dynamic SQL internally constructs a call to another stored procedure or dynamic SQL statement. That must also use parameters to pass all values.
Repeat ad-infinitum until you run out of code.
If you are programming in SQL Server, you can use sp_executesql to execute dynamic SQL, and it will let you define and pass parameterised values to the statement being executed.
If you are going to build a dynamic sql query with those parameters (passed to a stored procedure, for example) then there's a chance of sql injection if precautions are not taken.
You can always minimize the risk of SQL injection by using prepared statements, provided your database engine supports them.
Anyway, prepared statements is probably the most secure way of blocking SQL injections.
The problem is building the SQL statement dynamically.
For example, you might want to order the result based on the column the user selected. In most databases, you can't use parameters here ("ORDER BY ?" doesn't work). So you have to "ORDER BY " + column. Now, if "column" is a String, then the user of your web-application could inject code there (which is not easy, but possible).
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.