I developed a web site for a client where they will post images of their merchandise online. The url is www.domiainname.com/item-details.cfm?sku=125. Someone tried browsing to www.domiainname.com/item-details.cfm?sku=125%20and%203=3 which produced and error in which I'm notified.
I've also received error reports of:
item-details.cfm?sku=1291+or+1=##version--
item-details.cfm?sku=1291'+or+1=##version
item-details.cfm?sku=1291+or+1=##version
The last three examples are definitely of someone trying to get into the system, right?
If we converted this to be stored procedures, would that reduce or eliminate the risk of insertion attacks?
Yes, it appears that someone is being malicious.
Using cfqueryparam will prevent SQL-injection attacks. When in doubt (and it's CF), ask Ben:
SQL Injection Attacks, Easy To Prevent, But Apparently Still Ignored
Example:
<cfquery ...>
SELECT *
FROM Products
WHERE SKU=<cfqueryparam value="#URL.SKU#" cfsqltype="CF_SQL_INTEGER">
</cfquery>
Use cfqueryparam and forget about any sql-injection ;)
Yep, someone attempted SQL injection. If you check the sku variable correctly in your code, this will not do any harm.
Related
I have a task to prevent SQL Injection in an ASP.Net Web App. There is a comments textbox that the testers have flagged as possible location for SQL Injection. The Submit button event which inserts the text into the database already uses an Oracle parameterized SQLCommand. But when testing I was able to insert "select 'duff' from dual;" as a comment. So I'm curious as to how to prevent a sql injection when all I can find is people saying use parameters. All advise is appreciated. Thank you. Below are the lines that call the stored proc.
dbCommand = db.GetStoredProcCommand("ABC.Insert_My_Comment");
db.AddInParameter(dbCommand, "in_comments", DbType.String, obj.Comments);
db.ExecuteNonQuery(dbCommand);
SQL Injection
As long as you are using parameters and stored procedures, your system is reasonably protected from SQL injection.
If your penetration testers are still giving you a hard time about it, tell them you implemented a mitigation consistent with OWASP guidance, specifically option 2. If they keep giving you a hard time, ask them which specific injection test failed, what is the specific failure mode or criticality,
and/or if they have been able to trigger any malicious or unwanted system behavior. If they cannot provide a specific case of expected behavior differing from actual behavior, it is not an actionable defect, and you should close it as FAD.
Other types of injection
Just because you're safe from SQL injection doesn't mean you're not safe from all types of injection, e.g. someone could inject HTML into that field in possible support of a reflected XSS attack. If there are any pages in your site that spit that comment field back out onto a page, make sure you are HTML-encoding the content properly and make sure nobody can coerce your site into rendering Script tags in the middle of your page.
As long as you're putting the comment in a parameter, it cant be used for injection.
The problem arises when you generate a dynamic query string like;
"INSERT INTO COMMENTS Comment = '" + userComment + "'"
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.
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.
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.