Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We have an employee whose last name is Null. He kills our employee lookup (2012)

stackoverflow.com

Post reply on HN
Print view View original

161–170 of 245 posts

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#161

Post by neilk »

jerf wrote: post #77
sehrope wrote: post #54

Earlier quoted context omitted.

In our app we neither validate nor escape user strings for any free form text (eg. "names" and descriptions)[1]. We only validate the max length. If text is truly free form then you don't need to validate or white list anything. Just make sure it's valid UTF-8 (or whatever encoding you're using) and escape it when you display it . That combined with using prepared statements with bind variables (aka named parameters)…

"Just make sure it's valid UTF-8 (or whatever encoding you're using) and escape it when you display it." I've lately been coming around to the belief that anyone who uses the term "sanitize" in this domain, as in, "sanitize user input" really doesn't know what they are talking about (at least on average). The approach you describe is the generally correct approach; you need to ensure that the proper levels of escapin…

If you're going to accept all characters by default, be prepared to sanitize the outputs for every use, not just your website.

Maybe you will output a data dump for someone else to print mailouts. Or you'll share the user database with a vendor's web forum. Or payment processing. Or any SaaS.

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#162

Post by lostlogin »

bigiain wrote: post #159
lostlogin wrote: post #156

Earlier quoted context omitted.

The data base has errors and faulty assumptions, yes. I have some too, but I do not allow names entered into a big medical system to be anything other than the persons name, minimum of first name and last name, but I go over every record that passes through our scanners and enter middle names too. We have an AKA field where the patient can be called what ever the want, characters and numbers allowed. This is not stuc…

"minimum of first name and last name" Bzzzzt! Sorry… http://www.kalzumeus.com/2010/06/17/falsehoods-programmers-b... https://en.wikipedia.org/wiki/Mononymous_person

Wow, that first one is great, thanks. I'm saving that for future reference. Japan seems a hotbed for hard database problems. There is no way any of our systems could handle some of that, and its mostly not our fault - trying getting access to change stuff on medical database software or imaging equipment. It isn't possible.

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#163

Post by alex_young »

jjindev wrote: post #6

Reminds me of a story a police reservist told me. Guy got a license plate caled "none," and instantly had thousands of outstanding warrants. (The cop thought "none" was trying a fast one, and so deserved it.)

Similar to the Florida plate, A55 RGY

http://www.thesmokinggun.com/documents/florida/assorgy-story

For some reason Florida plates use 2 oranges now...

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#164

Post by derleth »

pmelendez wrote: post #51
speeder wrote: post #42

Earlier quoted context omitted.

My name fail to register surprisingly often, even here in Brazil. It is Hélder Maurício Gomes Ferreira Filho Common reasons for failure is being too long and having non ASCII characters, but sometimes it fails for other reasons, for example do not allow me to register without a middle name ( I don't haven't one actually... ), me confused and not knowing how to register Filho ( it is not a family name, neither a surna…

> "having non ASCII characters" Accented vowels are ASCII characters but in the extended set which people sometimes don't take account.

Extended ASCII is not ASCII. There is ASCII, which has no accented characters, and there are other character encodings based on ASCII, which often do. Those other character encodings are not ASCII.

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#165

Post by dublinben »

njharman wrote: post #148
jonlucc wrote: post #132

Earlier quoted context omitted.

Are you implying that two people (you and your father) can't have identical names in the US?

No I'm stating that Jr. is an official part of Norman John Harman Jr., my name. It is on my birth certificate, filled out on my tax return, etc. In any case were I'm required to use my real name if I used Norman John Harman Sr. I would be committing fraud. Likewise fraud if I left off the Jr. in an attempt to confuse with or impersonate my father.

When your father dies, and you've named your son Norman John Harman as well, don't you become senior? It's can't be an immutable part of your name if your junior/senior status changes.

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#167

Post by kevinpet »

njharman wrote: post #148
jonlucc wrote: post #132

Earlier quoted context omitted.

Are you implying that two people (you and your father) can't have identical names in the US?

No I'm stating that Jr. is an official part of Norman John Harman Jr., my name. It is on my birth certificate, filled out on my tax return, etc. In any case were I'm required to use my real name if I used Norman John Harman Sr. I would be committing fraud. Likewise fraud if I left off the Jr. in an attempt to confuse with or impersonate my father.

"Norman John Harman Sr."

By your reasoning, there is no such person. If there can be a "Norman John Harman Sr." then there can also be a "Norman John Harman Jr." who does not have it listed on official documents.

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#168

Post by jarek »

neilk wrote: post #161
jerf wrote: post #77

Earlier quoted context omitted.

"Just make sure it's valid UTF-8 (or whatever encoding you're using) and escape it when you display it." I've lately been coming around to the belief that anyone who uses the term "sanitize" in this domain, as in, "sanitize user input" really doesn't know what they are talking about (at least on average). The approach you describe is the generally correct approach; you need to ensure that the proper levels of escapin…

If you're going to accept all characters by default, be prepared to sanitize the outputs for every use, not just your website. Maybe you will output a data dump for someone else to print mailouts. Or you'll share the user database with a vendor's web forum. Or payment processing. Or any SaaS.

Somewhat related example anecdote: For several years, Vimeo was sending me newsletter emails addressed to "Dear Jarek_Piórkowski" (previously "Hi Jarek Pi??rkowski"). The ó that should be there shows up fine on the Vimeo website and I even cleared and re-input the name into my profile to give them a chance to re-encode it. Still continued.

I unsubscribed from the newsletter eventually.

And ó isn't even a difficult character, it's in ISO 8859-1 for crying out loud.

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#169

Post by jerf »

neilk wrote: post #161
jerf wrote: post #77

Earlier quoted context omitted.

"Just make sure it's valid UTF-8 (or whatever encoding you're using) and escape it when you display it." I've lately been coming around to the belief that anyone who uses the term "sanitize" in this domain, as in, "sanitize user input" really doesn't know what they are talking about (at least on average). The approach you describe is the generally correct approach; you need to ensure that the proper levels of escapin…

If you're going to accept all characters by default, be prepared to sanitize the outputs for every use, not just your website. Maybe you will output a data dump for someone else to print mailouts. Or you'll share the user database with a vendor's web forum. Or payment processing. Or any SaaS.

No. That completely doesn't work. This is really important: You CAN'T "sanitize" for every possible use. You can not correctly figure out in advance how to represent an input, because the different possibilities are numerous and actively self-contradictory.

To "sanitize" for "every possible use" is pretty much to remove everything that isn't an ASCII letter. Even unexpected spaces can cause crazy behavior. Commas can cause CSV-injections. And you might still have length problems even so. Oh, and you still can't guarantee something won't screw up even so! https://news.ycombinator.com/item?id=6140631

You can not, at the time input comes in to a system, even pretend to know where all the data might end up, someday, given the whims of who knows whom, and who knows when. The only thing that works is for each system to correctly encode its output as needed, and if you output the correct thing and a subsequent system blows it up, it's the subsequent system's fault. You can't prevent it. You only think you can, but you're wrong.

To be clear, if you could defend against those systems messing up, I'd be willing to consider it. But you can't. It's impossible, both in theory and in practice.

There's no easy answer to writing secure code. (Though it would help a lot of people used type systems to better effect in this problem.) Filtering out certain "dirty" characters isn't an easy answer either, on the grounds that it isn't even an answer. (It turns out to often become not easy, too, because as you gradually and inevitably learn exactly how it isn't working for you, the subsequent frantically flailing addition of heuristics becomes very not easy itself. It is easier in the long run to do it correctly.)

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#170

Post by kevin_p »

seanmcdirmid wrote: post #160
patio11 wrote: post #53

A Japanese company once made the decision that they needed "virtual" employees in a particular system, for example to support e.g. adding a job to the org chart before that position had been filled (and another dozen use cases), so they had the clever idea "Hey, if we need to do this, we'll just input their 'name in Japanese' as one of a dozen status flags, like XX_JOB_REQUEST or XX_INCOMING_TRANSFER." One developer…

Many systems in China depend on your Chinese name and identification number. Suffice it to say, foreigners who work in China don't have either of these: a made up Chinese name is not meaningful or legal (China also lacks any kind of kana), a passport number is not a "valid" ID number and changes every 10 years anyways. I don't get to use many online services accordingly, and every year there is some problem with how…

It's meaningful in some contexts. I had a different Chinese name on my work permit and marriage certificate (in both cases transliterated without my input), and it caused me no end of hassle when I was applying for a mortgage - we got refused the first time and had to get the work permit changed to make them the same.
Post reply on HN