Re: Use placeholders. For SECURITY!

Of course, I agree.

I understand why you were bothered by that node I wrote, but I'd appreciate it if you would re-examine the context in which I said it. It wasn't a node about database programming. It wasn't a node about CGI. It wasn't a node about security.

It was, in essence, a node about pacing your growth as a programmer.

In that node, I suggested that learning fundamentals was ever so much more important than learning details. The fundamental issue, in this case, is the security implication of untrusted input.

You wrote, "Escaping things yourself is better than nothing, but by and large the ones who know how to do it right also know enough reasons to use placeholders that they do that instead." And I agree. But then again, I'd rather employ someone who knows how to do right and uses placeholders than someone who uses placeholders because they saw an article on a website that told them they should "for security." The former's understanding would be far more valuable than the latter's best practices.

It's all too easy to focus on one or two small details and miss the forest for the trees. Yes, use placeholders. Yes, use tainting. Yes, have your DBA lock down the database to the best of his ability. Yes, use encryption. Yes, take every precaution you can and buy insurance (because you have to assume you're not secure anyway.)

The one thing I don't agree with in this article is the order that you put your 5 points. Number 4 ("Submit your code to code reviews.") should be number 1. You can't write secure code in a vacuum. If you neglect all of the other points, don't neglect this one. That way, someone can tell you that you are neglecting the others.

In further defense of my aforementioned node, I must note that I was addressing it to someone whose description of himself implied that he was a novice or maybe intermediate programmer. I could be wrong, but I didn't get the impression that he was writing ecommerce frameworks for a living. Yes, security is important, especially on the wild wild web; and it is paramount when you are handling other people's private data. But most people aren't.

Ecommerce is sexy and gets all the press but most programmers are probably writing code for relatively mundane, in-house, non-mission-critical tasks. Of course, this is a very good thing because most programmers don't know everything there is to know about security, and projects like these give them a way to gain experience and earn a living without jeopardizing your Visa account.

Finally, although I agree that the responsibility for security rests on the developers, it doesn't rest on the developers alone. For instance, that responsibility also lies with the people who hire the developers. Perhaps it should be suggested that they always ask interviewees to explain why using placeholders is so important. It seems, to me anyway, that addressing the meta-problem might actually be more effective.

-sauoq
"My two cents aren't worth a dime.";

Comment on Re: Use placeholders. For SECURITY!

Replies are listed 'Best First'.
Re: Re: Use placeholders. For SECURITY! by tilly (Archbishop) on Nov 14, 2003 at 05:36 UTC
Replying out of order, let me start with the order I put my bullets in. I arranged those from easiest for a programmer to make happen to hardest. Trying to get co-workers who don't want to to do code reviews is definitely an uphill battle, which is why I focussed first on things that you can do which won't hit such political resistance. On how critical the data that people work with is, I can't speak for most programmers. Speaking for myself, I have never had a programming job where I didn't wind up learning very sensitive things about people. My sense is that this is pretty typical. People stick information in a database, I have access to the database. People want to improve workflow, I get access to whatever data is in that workflow. People want financial reports run, I get to see the financial data. I generally don't care about the data I have access to, but I get that access, and the fact that it is worth hiring me to work with the data means that someone thinks that it is worth a lot. On your node, here is a fuller response. The attitude that, "Whatever you know and are getting by with is OK" is one that I highly dislike. Because what you don't know, will bite you. But you generally won't see that it is biting you because you don't know that you can do better. Furthermore far too many people for my taste have the attitude that they know how to program perfectly well and have no desire or need to learn more. I don't like encouraging that. See my response in the thread starting at Life beyond CGI and DBI to see an extreme example. On fundamentals, I fully agree. And I agree enough that I wouldn't want to filter a person on whether a certain fact was known unless knowledge of that fact was indicative of basic background for the job that they need to do. I can let not knowing placeholders pass if you have the concept of not trusting user input down - you can learn placeholders pretty easily. Perhaps you don't know them because you used Class::DBI and never needed to look under the hood. But if you are thinking of using them and need a push, I definitely think that the push is worthwhile!	[reply]
Re: Re: Re: Use placeholders. For SECURITY! by nevyn (Monk) on Nov 14, 2003 at 11:46 UTC
On how critical the data that people work with is, I can't speak for most programmers. Speaking for myself, I have never had a programming job where I didn't wind up learning very sensitive things about people. My sense is that this is pretty typical. People stick information in a database, I have access to the database. People want to improve workflow, I get access to whatever data is in that workflow. People want financial reports run, I get to see the financial data. I generally don't care about the data I have access to, but I get that access, and the fact that it is worth hiring me to work with the data means that someone thinks that it is worth a lot. Well there's also the threat. If you are writing something that sells CDs on the internet, then anyone can access it and anyone can/will attack it. A web front end for some mid level managers though (passwd protected so only they can get to it) has a much lower chance of being attacked, so from that point of view while it might be sensitive screwing up and allowing XSS etc. isn't as bad as if it'd happened on amazon.com etc. For instance I've worked at places (I managed to leave quickly though :) where people mostly used telnet and had numerous machines where people had root access ... and one place where everyone used one machine for shell access, and gave the root password to it out. Hell one place I contracted at had single letter root passwords everywhere and they dealt with medical information. And while that is completely insane, IMO. The employees while having easy access to the gasoline and lighter, didn't burn the place down on a daily basis. Admittedly if they were knowledgeable enough and wanted to they wouldn't be seen ... but generally the people either weren't knowledgeable or didn't want to. But maybe I'm being somewhat too optimistic about the entire race :). -- James Antill	[reply]
Re: Re: Re: Use placeholders. For SECURITY! by sauoq (Abbot) on Nov 14, 2003 at 19:26 UTC
On your node, here is a fuller response. The attitude that, "Whatever you know and are getting by with is OK" is one that I highly dislike. I think that's a poor interpretation of what I wrote. It certainly wasn't my intended message. I hope it didn't sound that way to many others and I suspect it didn't because it seems to have been a relatively well liked node. I think (and hope) an attitude as you describe would attract more downvotes. The message I meant to convey was: what you know now is okay and you have to learn at your own pace and in your own way so don't get hung up on what you don't know, especially not details; concentrate on fundamentals and you will improve. I think that is appropriate advice to give to a novice-to-intermediate level programmer. -sauoq "My two cents aren't worth a dime.";	[reply]
Re: Re: Use placeholders. For SECURITY! by nevyn (Monk) on Nov 14, 2003 at 11:24 UTC
But then again, I'd rather employ someone who knows how to do right and uses placeholders than someone who uses placeholders because they saw an article on a website that told them they should "for security." The former's understanding would be far more valuable than the latter's best practices. This seems like a simplification gone too far, personally for either PostGres or Oracle I wouldn't know the entire set that needs to be escaped (or I least I wouldn't trust myself to get it perfect -- which it would need to be). I wouldn't even trust myself to do it perfectly for bourne shell etc., which I use more often, without looking it up. I know the reasons behind why you would do it though, and I could write a non-perfect escaping mechanism (read less than useless). However I doubt there are many people who are cargo culting the use of placeholders ... it's just not that hard a concept. It's probably much more likely that those people are just passing data straight from the web form to the DB. Also, personally, if someone said they could escape the SQL properly without using placeholders ... I'd have visions of the thousands of C programers who said they could write buffer overflow free code without using an API that made it impossible not to ... so I might well not prefer them based on that. -- James Antill	[reply]
Re: Re: Use placeholders. For SECURITY! by hardburn (Abbot) on Nov 14, 2003 at 16:01 UTC
I'd rather employ someone who knows how to do right and uses placeholders than someone who uses placeholders because they saw an article on a website that told them they should "for security." The former's understanding would be far more valuable than the latter's best practices. I think it's more common that programmers think they know how to do it right, and will probably even be able to fool an interviewer into thinking they know how to do it right, but will often miss an edge case. Or perhaps they know how to do it right for MySQL, but the same code doesn't catch a potential problem for PostgreSQL. I understand enough to know that I don't understand, which might sound self-detrimental, but it actually puts me way ahead of programmers who think they know what they're doing but actually get it wrong. Admiting the fact that I don't understand the complete problem set, I use placeholders because someone who does understand already did the work for me. If that person actually didn't understand (i.e., there's a bug in a DBD's placeholder mechanisim), it's a lot easier to change the DBD module then to fix a lot of programs in production. That's not even touching on the other benifits of placeholders, like efficiency of cached statements (especially in a mod_perl environment). ---- I wanted to explore how Perl's closures can be manipulated, and ended up creating an object system by accident. -- Schemer `: () { :\|:& };:` Note: All code is untested, unless otherwise stated	[reply] [d/l]
Re: Re: Re: Use placeholders. For SECURITY! by mpeppler (Vicar) on Nov 14, 2003 at 16:43 UTC
I understand enough to know that I don't understand... Indeed. This is probably similar to what my Dad (an ex-air force pilot) used to say about pilots: beginners are very careful, and experienced pilots are careful. It's the intermediates that are really dangerous, because they think they know everything, but they don't know enough to know that they don't. Michael PS - I hope that last sentence makes sense :-)	[reply]
Re: Re: Re: Use placeholders. For SECURITY! by sauoq (Abbot) on Nov 14, 2003 at 18:47 UTC
I think it's more common that programmers think they know how to do it right Sure, but I think you missed my point. I'd rather hire someone who understands the issues and uses best practices than someone that just uses best practices without really knowing why they are "best". I understand enough to know that I don't understand, which might sound self-detrimental That sounds both honest and like you have a realistic perspective on what you'd need to learn. Those are two other good qualities that one might look for in an interview. Regarding how one might fool an interviewer, that's quite true. It depends on the skill of the interviewer as well as his proficiency in the technical material being covered. (Assuming it's a technical interview.) -sauoq "My two cents aren't worth a dime.";	[reply]


Perl-Sensitive Sunglasses
	PerlMonks