views:

33

answers:

2

hi,

I'm about to launch a forms auth membership site that will include forms that both international and American users can use to update their profile info and submit requests for info on products (but no actual e-commerce). I'm using asp.net validation controls on the text inputs and I had it pretty tightly filtered for chars using regex detection. Getting some push-back from marketing to open that up some (a lot), so I was looking for some advice on what chars are highest priority to filter in an asp.net form page from a security stance?

Thanks for any tips on this!

A: 

The main thing is to make sure you aren't exposing yourself to SQL injection. Easiest(?) way to handle that in .net/MSSQL is to make sure you are using either stored procedures or parameterized queries.

Depending on how the content being entered on these forms will later be displayed, you'll also want to check for client-side vulnerabilities (like people trying to enter iframe markup or javascript)

DA
+1  A: 

When you say submit requests for info on products I'm envisioning a free-text field where a user can enter anything they want, right? In that case you shouldn't be filtering anything. If it's as tight as I think it is then I bet this very answer would be considered bad, which would frustrate your users. =)

We ran into something similar recently where the security folks wanted a whole bunch of special characters locked down. Turns out users can't use periods or apostrophes or hyphens or slashes in their comments - woops! Also turns out that it wasn't required because the ORM being used was already generating parameterized SQL statements that were safe to execute against the DB.

If you're using a modern-day ORM or manually executing parameterized queries against your database I wouldn't worry much at all about enforcing special character restrictions on profile fields.

zincorp
Agreed; the best solution is to accept inputs freely and then be very careful about what you do with them. Learn the rules and techniques for escaping sensitive characters in HTML, in URLs, in SQL commands etc. It'll be a lot of work, but done right it turns out to be both very secure and very user-friendly.
vincebowdren
So, sounds like that if I'm using parameterized queries and have the default validateRequest flag set to true, I'm probably good to go w/o the additional filtering. Thanks!
kim r