How to avoid a potentially dangerous client input value?

[cesark]

Hi !

I have some doubts about this subject.

1. Now I only use javascript client side form validation. I need to use always server validation ?

2. Is it a recommended practice of using server validation with javascript code and regular expressions?

3. Is it better to maintain the javascript client side validation and to add server validation for security reasons? (Duplicate validation)

One person has recommended me that I never build the sql query as a string. I can' t use this?:

Dim citiesName As string = "Select field1, field2 From Cities Where field1 = @Param1"



Thank you,
Cesar

[hellswraith]

That is one of the worst things you can do in your web application.

NEVER trust user input. NEVER, EVER, EVER.

This is a lesson I learned when creating my forums and had people try to break it. There were so many ways to attack a site.

Three things for you..
1. HttpUtility.HtmlEncode your input strings.
2. Use stored procedures.
3. Validate on the client, but also validate on the server.

[MrNorth]

I trust that you use the validation controls...

1)Set the control to client... if its disabled server side is used...

2)I always use a regular expression validator if I can't do it with any of the others (except custom validator)... Each validator control has it's own purpose... select validator control based on what you want to validate, and ALWAYS, use custom validator as a last resont because of the added code and time needed

3)Set your control to client side... if the user has disabled javascript, server side validation is used...


How has this person recommended you to build your sql statements? Usually it's praxis to use stored procedures in your business logic to further separate the data from the business logic... and if you are working with stored procedures... why do you want to assign an entire sql statement as a parameter? It normally doesn't make much sense...

If I create my sql statements in the business logic, perhaps for a smaller app I us the stringbuilder class to build the sql...


kind regards
Henrik

[cesark]

Good, thanks a lot for both advise.

Cesar

[hellswraith]

Building SQL statements in web sites is just opening you up to sql injection attacks.

Imagine this:

You have a text box that you have a user enter their username.

The sql statement you build to execute is this:

"SELECT * FROM tblUsers WHERE UserName =" & txtUserName.Text

Ok, that seems all well and good, and works well for most people. If the hacker gets a hold of it, they will put this in the txtUserName box:

"ted; DELETE * FROM tblUsers"

Then, when you have your sql statment created as a string, you will end up with this:

"SELECT * FROM tblUsers WHERE UserName = ted; DELETE * FROM tblUsers"

What happens is, you go your command.Execute, and whether or not ted is in the database, the next statement is also executed, which will just clear out your tblUsers.

That is hacker 101 there.

Stored procedures will not allow a parameter to be executed. A hacker can put in all they want in the text box, and when you pass the textbox contents to the procedure as a parameter, sql takes that parameter literally and it won't execute it. So in our senero, no results would be found, unless you has a username in your database that actually matched 'ted; DELECT * FROM tblUsers'

[crptcblade]

http://msdn.microsoft.com/msdnmag/issues/02/09/securitytips/

A pretty good read, even if only a little bit applies to you.

[Memnoch1207]

The attacks are called SQL Injection. Do a search on google on how to protect your application from these types of attacks.

[Split]

Originally posted by hellswraith
That is hacker 101 there.

Stored procedures will not allow a parameter to be executed. A hacker can put in all they want in the text box, and when you pass the textbox contents to the procedure as a parameter, sql takes that parameter literally and it won't execute it. So in our senero, no results would be found, unless you has a username in your database that actually matched 'ted; DELECT * FROM tblUsers'

This is a very good and scary example, but you should know also the actual table name, in this case 'tblUser'.

[MrNorth]

I always use a SafeSql() method which has a bunch of String.Replace() methods which takes care of potential dangerous code...

But the best and cleanest way is to use stored procedures!
There is no reason not to use sp's in any project, it's all got to do with programmer laziness :) I know, sometimes it is quicker to just write it down some sql in the code behind...

Reminds me of the old asp classic days, wher eit was considered bad programming to write jscripts in the .asp files... all business logic should be packaged in com objects... but it was soo much faster to put a <script></script> block and write some ado code instrad of launching vb6, write an active x dll, register it ...

laziness :)

kind regards
Henrik :wave: