I just took over management for a webservice and today i got a user report about this error. Now i'm no sql injection expert but does this error make this attack possible?
Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[MySQL][ODBC 3.51 Driver][mysqld-4.1.22-community-nt]You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '') ORDER BY TCOL_date desc' at line 1
I'm asking because for some reason i'm not given access to the code and the previous guy insists that the site is safe so i need to come with some proof or facts that it's actually vulnerable.
Thanks in advance for any help.
In short Not really... but.
While this might provide more information than you're comfortable with (version of MySQL running, drivers being used, and a little about a couple of columns), it's not going to open you up to an attack as much as showing the whole SQL line would. Someone could try to blind hack it to get more information, and the fact that it's showing any info at all is a lot worse for you from the standpoint of an attacker trying to get in than showing info only in the logs. Feedback, even a little can aid an attack[er].
If by trying to insert various bits of code into the form you can get a response that prints your own content you're inserting this would be much more beneficial to an attacker. The fact that this application breaks when you insert a ' leads me to believe that it's not as secure as the programmer claims. This might also lead an attacker to look for another avenue of attack. If they can insert javascript code into a form and have it display in a profile, or if they can inject code that's executed upon return from the server, then they could exploit the server and use it to launch their own attacks.
The problems with SQL injection come back to [code] implementation and the types of things allowed (and blindly processed) by the forms. For instance if you could escape a single quote \' in your current situation, someone could open and close the SQL statement and possibly UNION their own statement when pulling a query. If they could close the statement and append another statement, they might add delete from users where 1=1 or something of that nature. Another way might be if you can type in <marquee>Test</marquee> and it prints the word "test" scrolling when it finds no results then you can perform injections because it's not stripping out code.
This all leads back to permissions. The permissions on the server should make it so the users on the front end of the site only have access to the permission levels they need. If they're only querying the database (SELECT), they should not have access to INSERT, UPDATE, DROP TABLES, or DELETE.
Related
I scanned one of my test sites with Acunetix, and it shows that it has some SQL injection vulnerabilities due to an unclosed quotation mark.
If I enter 1'" in the form, I get back the error message.
And if I enter
"...MessageHandler.asmx/ChangePassword?PIN=1%27"&CurrentPwd=1&newPwd=1"
in the URL, I get the error message.
My question is, where do I go from here to poke around some more? I've read tutorials on injections, but I just can't seem to figure out what to do from this point. I know I have an injection vulnerability, but what now?
What would my next steps be to see what kinds of other data I can see?
In Microsoft SQL Server, SQL Injection is negated by using stored procedures. It will not execute commands sent in, even as parameters. If you replace embedded SQL with stored procedures you will eliminate the SQL injection threat. Is still good practice to sanitize your input thru GUI validation routines, but these can be easily by passed by an experienced hacker so its important to also eliminate embedded SQL.
In SQL Server 2008 R2, I would like to execute a statement that I want to be invisible to the SQL Profiler or other means of observing user queries. Is there a way to control what is displayed by SQL profiler?
I would like to execute something like:
SELECT 'MyPassword' INTO #passwordTable
I don't want to show 'MyPassword' through SQL Server Profiler or other means. Any ideas?
Essentially, no, you can't. You used to be able to do this by adding a comment like this into the batch or statement:
-- sp_password
But this no longer works. Why aren't you hashing your password?
Well, you have to be a server administrator to run the SQL Profiler, so even if you could prevent it from seeing the command, the user could just go grab the password table anyway. Ideally you would be storing hashes of the passwords rather than the passwords, making any viewing from the profiler useless.
If you really want to try and keep the profiler from seeing the statements, you could try a third party tool like this: http://www.dbdefence.com/support/dbdefence-documentation/
I have no idea if it works though, or how reputable that company is.
Denis, Aaron is correct, there is nothing like an "invisible statement", you can't tweak SQL Profiler to NOT show statements: once aboard, one can see all statements running in the DB.
You need to obfuscate this sensible data before submitting it to the DB. There are some obfuscated methods available (one-way hash, symmetric algoritms, home-made methods), you need to choose the more suitable method to your needs and implement it. Unfortunatelly, there is no free-lunch to your case...
I have seen a product called DBDefence.
It hides SQL statements from the profiler completely. I do not know how do they do it.
I use free version because I have small database.
In earlier versions of SQL Server it was possible to add a comment --sp_password
but not in SQL Server 2008 and above.
I don't see the point, really. If one is able to view a query with SQL profiler, surely he could access the database to view the actual data.
The key is to not store sensitive data (like passwords) in clear text.
Preventing people to use SQL profiler will come down to applying the proper security configuration on your SQL Server.
My server was hacked like many others yesterday by this one SQL injection attack. I have two tables that have the alien script put in.
My options are:
-Manually delete the script from thousands of database entries.
-Find copies of the tables and replace them.
How I would like to have a SQL query that finds the script beginning with the **"></title>\****<script** and ending with **</script><!--** and removing it from all the database entries that have it.
Example:
So the query would see a databse entry like "></title><script> </script><!--Aland Islands
and remove "></title><script> </script><!--
leaving just Aland Islands behind.
P.S. I post the full script I want to remove just in case. Sorry for some reason stackoverflow isnt letting post some of this info.
One option is to take the DB offline, export the tables into load scripts, then use a text editor or sed to remove the malicious text, then truncate the tables and load them back in using the load scripts.
An example:
DELETE FROM infected_table
FROM
infected_table i
WHERE
i.script_column LIKE '>%'
Please do try the LIKE clause using a SELECT before running it though or run it in a transaction checking that the result is correct before committing.
1st find all the vulnerable Links on your site then change the version of mysql you are using because the error which help to attacker to find your site is vulnerable or not is due to the error. If your web application on php there are several other error which help to attacker to find site is vulnerable or not. You can use acunetix web vulnerability scanner for find all venerability on web application.
I am using SQLite.
When I execute a query, I get error messages such as "error near select" or "error near ','". I wish it would give me a line number or statement number.
After loading a trigger and encountering an error either in syntax or at run-time, I must go back to my editor and make changes. Then I have to execute a drop trigger command before reloading the trigger.
Is there a good SQLite browser or command line tool that provides more information than the one I am using?
Setting aside the implementation differences, would it make more sense for me to switch to mySQL?
Using a different browser for SQLite wouldn't make that much of a difference since it would use the same library. Switching to MySQL in my experience is not a trade up in terms of error messaging, it's about the same or worse in my opinion. PostgreSQL, however (again in my experience), has much better error messaging, although it can at times be just as cryptic as MySQL or SQLite.
So I've created an Access Project for one of my users so he can connect to a reporting database. The .adp project connects to the DB and he can query data to his heart's content. The problem is, no queries can be saved. Whenever he opens the project, he is presented with the following error:
"This version of Microsoft Access does not support design changes with the version of Microsoft Sql Server to which your Access project is connected. See the Microsoft Office Update Web site for the latest information and downloads. Your design changes will not be saved."
Again, this is Access 2007 and Sql Server 2005. My googling efforts - which are coming on a day when I seem to be especially stupid - keep bringing up information regarding this error for Access 2002/2003 trying to connect to Sql Server 2005, which is clearly not my problem.
I'm seeing that one can connect to Sql Server with the normal Access databases (.accdb in 2007 or some such), but I'm seeing mixed information regarding whether I want to do this or not. And since I can't get a copy of Access 2007, I can't really test this (topic for another time).
Before I do down that road, I'd like to get to the bottom of this one. Anyone have any suggestions, useful links, or useful knowledge? Or an older developer who knows the answer that is no longer needed, so I can eat him and absorb his knowledge and powers?
The account being used to connect to the DB was only a db_reader. I changed it to DBO and that fixed the problem - user can now create and save queries, and sleep at night knowing that tomorrow will bring a new day with new querying possibilities.
I'm not super crazy about this though the reporting database has been set up on a separate install/server from impotant App databases. I'm not worried about the user (or anyone on his group) blowing anything up. I'd like to understand why this is, and don't (outside of the obvious - reader is read only! I didn't expect that to extend to work in Access), and will try to do so at a later time. One of the unfortunate aspects of working at a dev shop focused on internal app development is, "well, it's working, you have other things to see to".
I am not sure if I can be of help here.
But you can have a view inside Access which connects to SQL database and use that view.
Alternatively, you can go the other way. Have a DB project with SQL Server & create a linked server to MS-Access DB.
Did you try linking to the tables through an ODBC connection?
CodeSlave, I did not. The attitude from higher up is "it's working, move on". I'm not sure the boss really wanted to go down that road anyway, but it's a moot point. I should probably try granting the account dbreader and dbwriter access and see if that accomplishes the same thing, but it being dbo isn't really a huge deal. Or rather, it's not a big enough deal that The Powers That Be want me to seek an immediate change.
I was going to try linked tables until changing the SQl Server account permissions "fixed the problem" (quotes very deliberate; it feels like one of those solutions you arrive at without a proper understanding of what it worked, which vexes me).