views:

183

answers:

+4 Q:

Should I allow underscores in first and last name?

We have a form that has fields for first and last name. I was asked to allow underscores. I don't know of any sql injection that uses underscores, but I also don't know of anyone with an underscore in their name. Is there a good reason to allow or not allow underscores in names?

EDIT: I'm using parameters and server side validation. This is for client side validation via the jQuery validation plugin.

EDIT 2: I didn't mean for this to become a discussion on whether or not I should do any validation...I just wanted to know know if there was any compelling reason to accept underscores, like I should accept Irish people or hyphens. Based on that, I'm accepting Oren's answer.

+12 A:

DO NOT PREVENT SQL INJECTION USING WHITELISTS!

Have you come across an O'Neill yet?

Instead, use parameters.

_{I will admit, though, that whitelists will work better than blacklists}

Re: EDIT:
You should not do such validation at all.
If your server-side code can handle it, there's nothing wrong with the name --'!@--_.
If your server-side code cannot handle it, it should.

SLaks 2010-07-23 14:20:32

+1, but needs to be bigger

Tim Robinson 2010-07-23 14:21:43

I am using parameters and server side validation. This is just for the client side validation.

Chad 2010-07-23 14:21:58

+1 stop shouting at me :)

Fosco 2010-07-23 14:22:02

@Tim: Unfortunately, it's not possible to make the text any bigger. (Unless you use an image, which is cheating)

SLaks 2010-07-23 14:22:10

@Chad: You shouldn't have whitelists at all.

SLaks 2010-07-23 14:22:40

+1, but could be more clear/explicit for beginners. If someone is asking this kind of question, they probably need a bit more guidance.

Matt 2010-07-23 14:24:48

@Matt: You can't give much more guidance without knowing what language he's using.

SLaks 2010-07-23 14:27:06

@SLaks: He is using .NET.

Sarfraz 2010-07-23 14:27:34

@SLaks: can you make it blink? or maybe put it on a marquee with some Christmas lights around it.

Lèse majesté 2010-07-23 14:28:50

@sAc: He added that after I gave my answer. Before adding that, he said that he's already using parameters.

SLaks 2010-07-23 14:28:58

@SLaks: Sorry i didn't spot that, i already have my +1 to you :)

Sarfraz 2010-07-23 14:30:42

@SLaks - so I shouldn't do any kind of validation on the client side? I should let people think they can enter --?

Chad 2010-07-23 14:34:17

@SLaks, http://www.figlet.org/

Tim Robinson 2010-07-23 14:36:41

@Chad: Only validate on the client what you're already validating on the server. You should not be doing validation so strictly at all.

SLaks 2010-07-23 14:38:18

JustinP8 2010-07-23 14:39:20

@Justin: In what context?

SLaks 2010-07-23 14:40:47

@SLaks: Preventing SQL injection. I was just curious since you say all characters should be allowed, and I've never heard that before. I've only heard about "preventing" the usage of characters that cause SQL issues.

JustinP8 2010-07-23 14:45:02

@JustinP8: the point is that you can avoid the entire issue of SQL injections by simply using params (prepared statements). Using blacklists/whitelists is worse than manually escaping user input, which itself is a pretty bad practice. And if all the books you've read suggest using whitelists/blacklists to protect against SQL injections, then you need to start reading better books.

Lèse majesté 2010-07-23 14:50:09

@Slaks - maybe I'm misunderstanding you, but you're saying I shouldn't do any validation as long as I'm using parameters? that can't be right. You should never trust user input, and you should use validation in conjunction with parameters.

Chad 2010-07-23 15:03:55

@SLaks - FYI, this is from MSDN. "Note When constraining input, it is a good practice to create a list of acceptable characters and use regular expressions to reject any characters that are not on the list. The potential risk associated with using a list of unacceptable characters is that it is always possible to overlook an unacceptable character when defining the list; also, an unacceptable character can be represented in an alternate format to pass validation." http://msdn.microsoft.com/en-us/library/ff648339.aspx

Chad 2010-07-23 15:16:14

@Chad: What are you validating for and why?

SLaks 2010-07-23 15:16:23

@Chad: They're wrong. Validation is rarely enough to prevent SQL injection in free-text fields (as opposed to SSN or phone number)

SLaks 2010-07-23 15:25:07

@SLaks: MSDN is wrong? I'm not saying I shouldn't use parameters. I'm saying validation should be used as part of the process.

Chad 2010-07-23 15:28:54

@Chad: It happens. If you're already using parameter, validation will not do any good. Note that that article is five years old.

SLaks 2010-07-23 15:31:11

@Chad: Reading the article more carefully, it's presenting a list of three alternative choices. It's not saying to use both parameters and validation; it's saying to use one of the two.

SLaks 2010-07-23 15:38:46

@SLacks: I don't see where it's an either or. It says if you can't use stored procedures =to use dynamic sql q/ parameters. But I don't see an either/or for parameters and input validation."To protect your application from SQL injection, perform the following steps:Step 1. Constrain input.Step 2. Use parameters with stored procedures.Step 3. Use parameters with dynamic SQL."

Chad 2010-07-23 15:49:23

@Chad: Any validation you do is going to reject somebody's name sometime. This may or may not matter in any individual case, but you should try to be as liberal as possible and know what and why you reject.

David Thornley 2010-07-23 15:55:17

Is there any reason to accept characters are in the range 0..31? Newlines in a person's name may not cause trouble in the database, but they're apt to wreak havoc in some reporting applications. Null bytes are also apt to cause difficulties in various places.

supercat 2010-07-23 16:00:11

@Lèse majesté I'd love to read better books. Maybe you could point me to your favs, or an SO question you think has better books?

JustinP8 2010-07-23 16:05:05

Also, should an application accept a name like "jOHN sMITH" without asking the operator to confirm that's really what's desired? What about names containing odd characters that happen to frequently occur more often as a result of improperly-configured code pages than as actual characters in names?

supercat 2010-07-23 16:06:02

@Supercat: That should give a warning, not an error.

SLaks 2010-07-23 16:11:06

@JustinP8: It's hard to make recommendations without knowing what languages you code in or what RDBMS you use. But a good mostly language-agnostic book would be _SQL Antipatterns_ by Bill Karwin, which talks about how to _properly_ use prepared statements and whitelist maps (for dynamic queries, not for data).

Lèse majesté 2010-07-23 16:57:14

@Lèse majesté: Thanks, I'll have to check that out. I use ASP.NET btw.

JustinP8 2010-07-23 18:44:20

@SLaks: I have to agree with supercat: while regexp validation is not a cure for SQL injection, it's a perfectly reasonable part of the business logic. I'm absolutely certain that none of my customers have names with characters in the 0-31 range, so it's fine to reject or filter these out.

Steven Sudit 2010-07-23 20:29:50

+3 A:

You're doing your validation wrong. When preventing sql injection, just use placeholders or your database library's escape function to escape the data. What characters you use in the name doesn't matter then.

DGM 2010-07-23 14:21:41

+1 A:

Ideally, you should be able to allow any characters and not have a problem with SQL injection because you are using parameterized queries etc.

Do you disallow '? How do you think Mr O'Reilly likes that?

Blorgbeard 2010-07-23 14:21:56

we allowed Irish people.

Chad 2010-07-23 14:26:39

--depends on whether it's Tim or William.

Lèse majesté 2010-07-23 15:49:28

+2 A:

You'll need to allow apostrophes and hyphens (O'Reilly, Double-Barrel). Never heard of an underscore in a name though.

bcmcfc 2010-07-23 14:22:13

+14 A:

You should be as liberal as possible in what you allow as a name. There is no good reason to disallow an underscore, so why do it? There are many horror stories of people who try to utilize software that disallows their actual name. Have a look at Falsehoods Programmers Believe About Names for assumptions you should not make.

Oren 2010-07-23 14:23:00

+1 You got there before I did!

Pontus Gagge 2010-07-23 14:24:28

That blog post is fairly useless. It doesn't give any advice for how to actually handle names in your system.

Zachary 2010-07-23 14:31:34

It doesn't? I thought it offered quite a bit of advice on _not using whitelists to unnecessarily restrict name input_ in your applications.

Lèse majesté 2010-07-23 14:58:26

@Oren - thanks, I didn't know if there was a compelling reason to not allow underscore. There doesn't seem to be from what I can tell.

Chad 2010-07-23 15:10:40

@Zachary: That blog post is useful. It gives a list of assumptions you might make that will fail for at least some people. It's useful to be aware of your assumptions you are actually relying on.

David Thornley 2010-07-23 15:50:12

@Oren: In a comment to SLaks' answer, supercat offers a compelling example of name illegality.

Steven Sudit 2010-07-23 20:30:50

That blog post is fairly useless. The only way to avoid all those assumptions is to use a signature capture pad and save a bitmap. Or just throw out the name field and assign GUIDs.

Blorgbeard 2010-07-23 21:54:22

For #40 in that falsehood list: Yes, what if Prince wanted to enter his symbol? Got to account for that! j/k

dotjoe 2010-08-10 16:41:42

+1 A:

If you prevent underscores with the assumption that we are not aware of names with underscores, would you do the same for the other dozens (hundreds) of other "special characters"?

Unless there is some reason to block underscores, I would leave it up to the user to be able to enter their name as they want.

NinjaCat 2010-07-23 15:47:45

ansaurus

tags:

views:

answers:

Should I allow underscores in first and last name?

DO NOT PREVENT SQL INJECTION USING WHITELISTS!

related questions