I have just noticed that Sql Profiler 2008 is not hiding trace outputs that include sp params called password. In 2005 it used to give me a message saying "The text has been replaced with this comment for security reasons".
Has they removed this security feature?
There is a difference between trapping the string "password" and genuine security holes.
Try this:
CREATE LOGIN foo WITH PASSWORD = 'bar'
In SQL 2005 profiler:
--*CREATE LOGIN-----------------------
Security is maintained.
Now, if you're sending dynamic SQL to a password columns...
But if you pass your passwords as parameters, it should display it. The solution should be storing passwords encrypted at database. By this solution you'll need to pass your passwords encrypted.
Yes, it did use to automatically filter out "password" in Profiler, I believe this was a feature added in maybe in SQL Server 2000 SP4 but I've seen a number of people wanting to switch this off as it was filtering out instances that they actually wanted to see. So whether MS have removed it/made that functionality switchable I'm not sure - can't seem to find anything on it for 2008 atm.
Edit: I can't find any information on this regarding 2008. Everything I can find relates to people wanting to do the opposite - in sql 2000/2005, switch that "feature" off, for which the solution has been to replace use of "password" parameter with an alternative name like "pwd".
Related
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...
I'm changing the security for a SQL Server 2005 database, so I need to identify every place/ db-object which use the function sUser_sName() (SQL function to retrieve the current username connected to the server).
So, is there any way to run a query or something else and retrieve every object which use the function sUser_sName()?
If you need to find database objects (e.g. tables, columns, triggers) by name - have a look at the FREE Red-Gate tool called SQL Search which does this - it searches your entire database for any kind of string(s).
It's a great must-have tool for any DBA or database developer - did I already mention it's absolutely FREE to use for any kind of use??
Using SQL Server Management Studio go to your DB->Programmability->Functions->[Your Function Type] then right click on the function then "View Dependencies"
EDIT2: Found a fix! I used the number of the desired schema instead of the name. Should've thought of that before, really! And i think the error messages could've been a bit better aswell. Thanks for all your time!
How can i get the names of all tables inside a database through sql inside asp classic?
The server is running windows 2008, iis7.5 and microsoft jet. I've tried all the querys i could find on the internet (and here) but none have worked.
If i add a ; to the query to run a set of querys at the same time it gives me an error because the statement isn't over at the semicolon.
The master.mdf database cannot be accessed because it's of unknown format.
The sysobjects variable apparently doesn't exist.
I am using mssql 2000 format. (.mdf)
The connection is made through classic asp with the Microsoft.Jet.OLEDB.4.0 provider and ADODB connection/recordset.
How do I get list of all tables in a database using TSQL?
Query to get the names of all tables in SQL Server 2008 Database
EDIT:
I've found two folders containing databases. One is in C:\program files\Microsoft SQL Server\MSSQL10_50.SQLEXPRESS\mssql\binn\templates and contains master.mdf, mastlog.ldf, model.mdf, modellog.ldf, msdbdata.mdf and msdblog.ldf. The other one is also in the \binn\template data directory and contains master.mdf, mastlog.ldf, model.mdf, modellog.ldf, MSDBData.mdf, MSDBLog.ldf, mssqlsystemresource.ldf, mssqlsystemresource.mdf, tempdb.mdf and templog.ldf. Maybe these is of some interest?
How can i tell if i have permission? Does it give a permission denied error?
Please help! No, don't. Read the 2nd edit at the top.
USE YOUR_DATABASE
GO
SELECT *
FROM sys.Tables
GO
Have you tried the example from:
http://www.kamath.com/codelibrary/cl002_listtables.asp
I almost always use the INFORMATION_SCHEMA views:
SELECT * FROM INFORMATION_SCHEMA.TABLES
If this isn't working for you, the SQL user your site is running under may not have access to the system objects. This is actually a good thing, as giving your site access to the underlying database schema can leave you vulnerable to SQL injection.
So if you do go this route, proceed with caution.
The mdf by itself is useless: you need a database engine (a.k.a. a SQL Server instance) to "run" it. As I understand the question, this is your problem.
Then you can use sysobjects in your database: unless you have added your tables to the master database
There is no practical way to use an mdf directly: if nothing else download MSDE
I've developed my website using EF4 and SQL Server 2005, but when moving to the staging site it turns out that they use SQL Server 2000.
Now I'm getting this error, which I believe is related to SQL Server 2000:
Incorrect syntax near '('. 'row_number' is not a recognized function name.
Is there a way of fixing this?
Thanks
EF v4 does not support SQL Server 2000. More details here:
https://connect.microsoft.com/VisualStudio/feedback/details/499186/entity-framework-v2-doesn-t-support-sql-2000
I came across the exact same problem and as per the comments/responses on StackOverflow I had almost given up and flicked it to client to upgrade their database to > 2000 version. Unfortunately that wasn't possible for them due to many other issues. I had to go around googling for a solution and from somewhere I found a work-around.
This is what I did.
Right clicked the ModelName.EDMX file -> Open With
Selected XML (Text) Editor
Found ProviderManifestToken="2005" and replaced it with
ProviderManifestToken="2000"
Published the changes and voila!
Now the reason I'm saying it's a work-around (not a solution) is because
If you update your model from database again and your development
machine database is >= 2000 (which is likely to be a case as SQL
2000 connection is not supported at all by MS according to this
article) this value in the XML will change automatically
Also, the queries generated by EF after this change have worked in
my situation but I cannot guarantee that all the queries ever
generated by your application would work without any problems
Row_Number() returns the sequential number for a each row returned. Are you calling Row_number(), or is the entity framework?
Either way, you may be able to write a user-defined function that re-implements ROW_NUMBER. Stackoverflow post on this here:
ROW_NUMBER Alternative for SQL Server 2000
Not sure this is going to do any good in the long run; you're likely to find that you get around this problem only to encounter the next reason that EF doesn't work on SQL 2000. But, it might be worth the few minutes to try.
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.