Xislaben

Basically I'm looking for a noobie's guide to proper input handling with asp.net 4.0 in vs2010.

I'm looking into creating a new asp.net 4 website that stores user supplied data in ms sql, and allows users search/add/edit/delete this data.

I can create parametrized statements in asp.net that call stored procedures in ms sql to deal with user supplied data, effectively inserting exactly what the user entered into the database, but what about writing this data back to the aspx pages?

What is the standard way to deal with sanitizing data accepted from users, and also returned from the database?

I've looked at the antixss library, and the built in server.encode, but I'm not entirely sure what to use when.

Thanks for any elucidation.

lamy

to prevent SQL injections and the likes it will depend on how you use your data, as much as possible avoid query string, use session for sensitive data even with a webservice if you consume one within the site

handling this at client-side is not enough, there are so many ways to bypass those, you should do every input handling at server-side, to keep it safe do a validation in your code and in your stored procedure as a fail-safe

everything that needs to be computed at client-side should be re-computed at server-side, do not pass computed values from client-side to your sql statements

make sure you understand how and what sql injection does so you'll know how to prevent it, as i recall from my CEH training you basically need to validate each parameter as it is intended, any integer should be integer, any boolean should be boolean, etc... if you disallow certain characters in a string then check for its existence, you can also use regular expressions

as for cross-site-scripting read this
http://msdn.microsoft.com/en-us/library/ff649310.aspx

also, this might be of interest
https://www.owasp.org/index.php/.Net

mmcginty

If all user input values are passed to SQL as parameters you are safe from SQL injection. No matter what the value of any parameter, as long as *ALL* user input is passed in parameters, it is not possible to launch a successful SQL injection attack, because SQL does not execute the contents of parameters.

Validating input to make sure the data type is correct is needed only to prevent db errors when inserting or updating, therefore client side validation is adequate for this purpose [only] -- who cares if someone constructs a request that ultimately throws a type mismatch error? It's a no op. If you're performing multiple SQL statements from a single submit, run them in a transaction and roll it back if any errors occur, that's the only way to guarantee data validity across multiple statements, no matter how well (nor how many times) you validate input. (I do agree that client-side validation is unsafe to enforce anything that is of consequence, but merely validating data type doesn't qualify.)

Your main worry would be HTML and/or script tags embedded in user input. If you HTML-encode the values before outputting them to the response (via any method) you'll be safe, though how your users use the content might be another matter. You could also replace the angle brackets with another character, or reject the input altogether if certain characters occur in it -- it all depends on what you rationally expect to be in the user input.

I once case-insensitively replaced 'script' with 'scr1pt' unconditionally, and ' on' with ' 0n' if it occurred within a tag. It had very little visual impact and was 100% effective at preventing the execution of user-entered script within the content. There are 1000's of ways, it all depends on content.

Regardless, try to avoid repetively performing the same task without a valid and logical reason, if you know for sure the input was validated before passing in parameters, validating it again in T-SQL is rather pointless, isn't it? Strong typing of parameters automatically validates type, don't pass everything as a varchar and convert in SQL, make the parameter types appropriate for the data and attempt to coerse in server-side code when assigning parameter values.

Remember, good server side code must scale well, and code that wastes CPU cycles does not tend to do that. When you're processing thousands of requeste per minute, every cycle counts and every byte counts.