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 + "'"
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.
A question for which I already know there is no pretty answer.
I have a third party application that I cannot change. The application's database has been converted from MS Access to SQL Server 2012. The program connects with ODBC and does not care about the backend. It sends pretty straight-forward SQL that seems to work on SQL Server nicely as well.
There is however a problem with one table that has the name "PLAN" which I already know is a SQL Server keyword.
I know that you would normally access such a table with square brackets, but since I'm not able to change the SQL I was wondering if there is any "ugly" hack that can either override a keyword or transform SQL on the fly.
You could try to edit the third party application with a hex editor. If you find the strings PLAN, edit this to something like PPAN and then rename the table, views etc. If you catch all, it could work. But, of course it is an ugly thing.
I think you are screwed I am afraid. The only other approaches I could suggest are
Intercepting the network packets before it hits the SQL Server which is clearly quite complicated. See https://reverseengineering.stackexchange.com/questions/1617/server-side-query-interception-with-ms-sql-server and in particular answer https://reverseengineering.stackexchange.com/a/1816
Decompiling the program in order to change it if it's a Java or .Net app for instance.
I suspect you're hosed. You could
Wire up the 3rd party app to a shim MS Access database that uses linked tables, where the Access table is nothing but a pass-through to the underlying SQL Server table. What you want to do is:
Change the offending column names in the SQL Server schema.
Create the linked tables in Access
Create a set of view/query in access that has the same schema that the 3rd party app expects.
Having done that, the 3rd party app should be able to speak "Access SQL" like it always has. Access takes care of the "translation" to T-SQL. Life is good. I suspect you'll take something of a performance hit, since you're proxying everything through Access, but I don't think it'll be huge.
That would be my preferred solution.
The other option would be to write a "shim" DLL that implements the ODBC API and simply wraps the actual calls to the true ODBC driver. Then capture the requests and improve them as necessary prior to invoking the wrapped DLL method. The tricky part is that your 3rd party app might be going after columns by ordinal position or might be going after them by column name. Or a mix. That means that you might need to transform the columns names on the way back, which might be more difficult than it seems.
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.
I was reading an article about Sql injection in the article the author mentioned that if an sql injection attack has been performed the attacker can transfer an entire database over port 80 my question is how can you transfer your database over the http port is there any software to do it ? how can i protect myself over hijacking my database
http://msdn.microsoft.com/en-us/magazine/hh580736.aspx
Transfer an entire database over port 80
An SQL injection means you have a weakness in your code - usually your web code which explains the port 80 - that allows a third party to run any SQL commands they want on your database. If you have left yourself open to this then you can't prevent them from doing whatever they want.
The ways to avoid it depend on the specific language you are programming in (Python, Ruby, Java, etc) but the two main points are you want to properly "sanitize your inputs - that is make sure characters are properly escaped so someone can't throw in a semicolon and wreak havoc, for example - and parameterize your queries. This means when you write your SQL queries you use parameters for user defined input and then safely fill those parameters. In Perl you would use:
$sth = $dbh->prepare("SELECT * FROM TABLE WHERE id = ?");
$sth->execute($id);
Think of them as place holders.
Again the exact method for this depends on your language of choice.
When you understand this you are on your way: http://xkcd.com/327/
There is absolutely no point in taking such measures.
This is just one out of billions possible exploits allowed by one vulnerability. So, it'll be like filling holes in a sieve - a toilsome and quite useless work as if you leave only one exploit open - it will be used.
Instead of that just secure your site against SQL injection.
My guess is that if you got somewhere can be injected, then they can probably make it via following steps:
Backup the DB in SQL or script out all data into a file
Using some DBMS function copy that file to web server so that expose to internet, like xp_cmdshell in SQL Server
Download it via your web server
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.