Help on SQL Injection...

Hi All:
I can't seem to get this thing work... When I type this in a textbox :'; exec master.dbo.sp_addsrvrolemember 'redice','sysadmin' -- , there's no respond, I mean, I check redice's role, but the System Administrators is not checked.
Any idea about this?
Thanks in advance.
Can you post your button click code or the code that executes the TextBox string?

|||Hi azamsharp:
This is my code:

Dim userNameAsString = txtUserName.Text

Dim pwdAsString = txtPwd.Text

Dim strSQLAsString = "select * from testing where userName = '" & userName & "' and pwd = '" & pwd & "'"

Dim comAsNew SqlCommand(strSQL, con)

Dim readerAs SqlDataReader

If pwd = ""Or userName = ""Then

lblMsg.Text = "Please enter user name and password."

Else

Try

con.Open()

reader = com.ExecuteReader

If reader.HasRowsThen

lblMsg.Text = "welcome"

Else

lblMsg.Text = "You are not authorized to enter this page."

EndIf

con.Close()

Catch exAs SqlException

lblMsg.Text = ex.Message

EndTry

EndIf
Thanks.

|||Guys, are you aware of how dangerous this can be? You are executing commands from web applications and that might cause you a lot of problems. I recommend you use parameters in your code while trying to access the SQL Server, this way everything entered in the textboxes would be treated as strings.
check this article please:UPDATE: Please, please, please, learn about injection attacks!
ergards
Regards|||First of all I have to agree with Bilal about SQL Injections. Don't runquery based on the parameters comming from the TextBoxes. Second yourcode looks fine to me, does it throw any exceptions. Are you authorizedto even run the select command on "testing" table. You can right clickthe table and give the users permission to run appropriate commands.Second It seems that all this code is written under "Button Click"event. If that is the case please keep all data access code in aseparate class library. Having code in Button Click means that you aremixing BLL with Presentation Layer.
Try to use stored procedures they are much faster than those queriesthat you are writing. Also check out the article below this may belittle advance for you but its always good to adopt good practices fromstart.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/CustEntCls.asp
|||

azamsharp wrote:

Try to use stored procedures they are much faster than those queries that you are writing.

I can prove that you are wrong over here. Stored procedures are just as fast in comparision to parameterized queries. There is, however, an exception to this finding under very certain circumstances but it is very rare that a stored procedure will outperform a parameterized SQL query by at least 5%. I'm just going to save me the time of what Frans Boumahas already done.

azamsharp wrote:

Don't run query based on the parameters comming from the TextBoxes.

You should parameterize anything that goes to your database. Instead of doing the bare minimum to protect from user input, you should do the full monty of parameterizing anything and everything you can. The reason is simply that you have not covered the full path of the exploit - you assume the most likely and yet are unable to cover the least expected. The truth of the matter is that is how exploits are found -- through the least expected resource.
If you trust drop down lists as being "secure," you better think twice. There is nothing stopping me from writing a HTTP request with a well crafted response of where your drop down lists is supposed to look like becoming my "text boxes." Another possible exploit is through querystrings. May I continue?
However, if you read the initial post clearly, it is not asking how to prevent SQL injections. It is merely trying to understand how SQL injections occur so value can be placed on how easy the exploit is. So it is not a matter of writing a well tiered application; it is just a demo to try understand the exploint.|||

redice wrote:

Hi All:
I can't seem to get this thing work... When I type this in a textbox :'; exec master.dbo.sp_addsrvrolemember 'redice','sysadmin' -- , there's no respond, I mean, I check redice's role, but the System Administrators is not checked.

To just put a simple example, here is some code:
command.CommandText = "select * from products where id = " + this.Page.QueryString["Id"];
As you guessed it, the above just gets the product out of the database based upon the ID passed in the querystring. Now the normal SQL that will yield for a URL like "View.aspx?Id=1" should be as follows:
select * from products where id = 1
Now let's assume we using the following URL:
View.aspx?Id=2; drop table products
Our favourite browser, Internet Explorer will automactially encode the URL for a proper URL request. The "SQL statement" that will be yielded is:
Select * from products where id = 2; drop table products
Which is actually two SQL statements! One being the "read" and the second part being the dropping of the table. Now is seems like that this was an easy attack. Let's try another ad-hoc SQL statement.
command.CommandText = "select * from products where productname = '%" + this.Page.Request.Querystring["SearchFor"] + "' order by price";
The first part of the SQL injection will be to insert the following into the builder:
'; select * from sysobjects where xtype = 'U
Now that will select all user objects from the database. And if you happen to display the exception information to the world, you just make the exploiters' lives easier because of obvious reasons. There may be other things that the exploiters' may use to find out more about your database... but if I tell you, I would have to kill you. However, there is your simple demo on how the SQL injections can occur.|||Hi all:
Okay, I know I should've said this. I was asked to do some experiments of how an attacker can use SQL Injection to attack the application. I KNOW how dangerous SQL Injection is. My bad, I guess, I should've mentioned to all of you that the purpose of this post is to find out how an attacker can attack... I was supposed to do a demo to my boss... Man~~~~ my bad, my bad...
Well, the user 'redice' has no permission at all, thus, this attacker (redice) is trying to grant himself a permissionsysadmin.
Anyone, please help.
Thanks.|||

redice wrote:

I should've mentioned to all of you that the purpose of this post is to find out how an attacker can attack... I was supposed to do a demo to my boss...

It is very good that you are cognisant of the risk of SQL injection attacks, and that you are trying to guard against them. You and your boss can pat each other on the back for your proactivity.
However, the above statement is a very risky approach to security. You should never presume to know how someone might attack your website. Unless you yourself are a very advanced hacker, then there is simplyno way to know how someone might attack your website. SQL injection attacks are only one type attack.

As Justin intimated, a hacker will not attack your website through your nicely crafted webpage. A hacker can use a spoofing program that allows him to create a complete HTTP request, adding any malicious form values, querystring values, and cookie values that he cares to add.If he's clever enough, and you haven't guarded against it, he can tamper with viewstate values to trigger a TextChanged event. [EDIT: By default, ViewState is tamper-proof.] The point is that you cannot "find out how an attacker can attack." You can learn some of the ways, and that's good, but it is the wrong approach to security in general.
What you need to do is assume that you simply don't know anything about how attackers do their thing, and instead follow well-documented best practices when designing your website. That is, you focus on your own defense, not on the attacker's offense.
Recently I conducted an audit of a website. I typed "goat's beard" into the search textbox, because that is the name of a flower, and is thus a legitimate search term. The apostrophe generated a server-side error that was echoed back onto the website. Sensing a vulnerability, I contacted a white-hat hacker. She quickly showed that the site was very vulnerable to SQL injection attacks.
I contacted the website's developer. Having been given this "demo"--precisely the type that you are creating for your boss--the website developer then updated his code to reject any search terms with an apostrophe. I pointed out that not only was that worthless, it means my dear old grandma cannot search for her favourite flower. In response, rather than reject such terms, he stripped out apostrophes from any query that went to the database. That too was worthless. This went on for a long time, as after fixing this single search textbox, he then had to do the same thing with the contact form's textboxes. The querystrings then proved to be vulnerable too.He was coding towards a demo of specific attacks, rather than coding a generalised defense.
This white-hat hacker was actually able to craft a querystring that permanently corrected a spelling mistake on the website. Had she been a black-hat hacker, who knows what she might have done.
The point of this story is that if you have a "demo", there is a real risk that you will code toknown attack types, updating your code until the demo suggests that your website is secure. The proper approach is to assume, quite correctly, that you simply cannot know all risks and all types of attack. This approach properly moves the focus to the defense, and not to the attacks.
Sheesh, another long reply. Perhaps my MVP award should read, "Most Verbose Person."

|||Hello fellows experts:
First of all, I wanna thank all of you for your inputs. It sure helps me to understand more bout SQL Injection. Ummm haha and after the miscommunication, SomeNewKid comes to my rescue. Thanks a lot. You've explained to me so detailed and yeah, you are so right about focusing the defense than the attack. Hope my demo will do fine.
Thank you to haidar_bilal, azamsharp, master4eva, and lastly, SomeNewKid! Thanks for sharing your thoughts.
CHEERS!
|||

Question to "Most Verbose Person",
Is it possible to have some sort of a Blog entry or even an article, things that developers should take care of while developing website against attacks? For example, one of those threats are SQL Injection, Cross-Page scripting and others too. Explain each attack, and what is the proposed solution.
And comment on the ' stuff, parametrizing queries, doesn't overcome that problem of using ' ? just a question.
Regards

|||

haidar_bilal wrote:

Is it possible to have some sort of a Blog entry or even an article, things that developers should take care of while developing website against attacks?

The problem here is that there is not a single determinable setup that is entirely secure. As much as we may wish it were this simple, there cannot be some sort of checklist of attack types, and the defenses against them.
One of the greatest weaknesses in security is a developer whothinks his website is secure. A developer might follow an article of the type you suggest, implement its recommendations, and then consider the job is done. Hackers find new ways of attacking targets, and not all attacks are through software. There are social and physical aspects to hacking, too.
Even more telling, not all vulnerabilities are the domain of attackers. We developers can do dumb things and corrupt our own websites. Website owners or content providers may misuse their tools and inadvertently cause damage. Even Google has corrupted websites! (This occurs when the option to "delete this item" is a hyperlink rather than a true button, and Google happily follows that link as it indexes the site.)
All of this is compounded by the fact that websites grow and evolve, and so too do the technologies on which websites operate.
There are of course resources that talk about security. A pertinent one isBuilding Secure ASP.NET Applications: Authentication, Authorization, and Secure Communication. This is a 600 page document of whichonly 3 pages deal with SQL injection attacks! You will see then that security is a mammoth topic that could never be covered in an article or a blog.
The point of my rambling is that security is such a huge topic that we must choose what it is that we focus on. The wrong thing to focus on is trying to learn all types of attacks and, one by one, address them. (Who'd have listed Google as an attacker?) The right thing to do is focus on the integrity of your code and the environment in which it executes.