Wednesday, February 9. 2005
Who's on Input
OK, so maybe Chris didn’t say “security is what happens between input and output.” But I do. The truth is that a PHP developer really only has control over these two deceptively simple components of the application. Sure, there are scads of other types of attacks—attacks relatively beyond the control of the PHP developer, involving DNS, file system permissions, and (in the case of phpBB) other applications written in totally different languages (like Perl) running on the same hardware. The PHP developer, however, has a specific responsibility to make the “black box” he codes in as airtight as possible. And the way to make that happen is to focus on two domains: input, and output.This raises another pretty interesting point: most PHP developers aren’t.
They’re systems administrators, network administrators, and sometimes CISOs for everything web-facing. Should they be? Can this go on in the enterprise? Can seasoned PHP veterans trust junior admins to do the job when it comes to setting up everything around the code they will write?
It is all too true that a secure application can be installed in an insecure way. The simplest case is, of course, with file permissions. Leave those config files read/write capable after you’re done with that fancy web-based installer, and you’re begging for trouble.
So where do we draw the line, divide up the responsibility, and make sure applications are safe end-to-end? In a well-run corporate environment, I still believe the developer should only have to focus on the security that happens between input and output. It makes a chaotic world manageable.
Frankly, I think Chris does well as one of PHP’s resident security experts. As you can see, it’s a heavy mantle to wear. One worn in lesser forms by freelance PHP developers often trying to be everything to every company. The truth is it is exhausting, and it has to stop. Time for developers to focus on secure development, and the rest of the enterprise to step up to do their part in sustaining a secure end-to-end web application.
It is all too true that a secure application can be installed in an insecure way. The simplest case is, of course, with file permissions. Leave those config files read/write capable after you’re done with that fancy web-based installer, and you’re begging for trouble.
So where do we draw the line, divide up the responsibility, and make sure applications are safe end-to-end? In a well-run corporate environment, I still believe the developer should only have to focus on the security that happens between input and output. It makes a chaotic world manageable.
Frankly, I think Chris does well as one of PHP’s resident security experts. As you can see, it’s a heavy mantle to wear. One worn in lesser forms by freelance PHP developers often trying to be everything to every company. The truth is it is exhausting, and it has to stop. Time for developers to focus on secure development, and the rest of the enterprise to step up to do their part in sustaining a secure end-to-end web application.
< Previous Entry | Next Entry >
Trackbacks
Trackback specific URI for this entry
No Trackbacks
Comments
Display comments as
(Linear | Threaded)
I believe you are mostly correct here. Still, I do think that it is up to the php developer to research their hosting environment. Request phpinfo() readouts, check with other clients currently hosted on that company to see if they maintain regular upgrades and are always on top of security vulnerabilities on a serverwide level before making a commitment. If the developer does not have control over where it is hosted they can still "scope out" their environment and voice to their clients the potential security threats involved.
Smart research will give you a better chance of finding an environment who’s admin IS on top of their game. This initial effort on the developers part can give them the freedom to be primarily concerned (always be aware of your environment!) with the security they do have control over. That’s just my two cents.
Smart research will give you a better chance of finding an environment who’s admin IS on top of their game. This initial effort on the developers part can give them the freedom to be primarily concerned (always be aware of your environment!) with the security they do have control over. That’s just my two cents.
Point well taken for freelance developers, Eric. But is it really the responsibility of the developer to scope out the hosting environment in an enterprise situation? Shouldn’t PHP "hosts", particularly full-time admins, know enough to keep the environment sane and, better yet, secure?
PHP more than any other language seems to promote the developer-come-CISO syndrome. That’s a lot of job titles. Better to have developers focus on what’s between the PHP tags and encourage admins to step up to the plate.
PHP more than any other language seems to promote the developer-come-CISO syndrome. That’s a lot of job titles. Better to have developers focus on what’s between the PHP tags and encourage admins to step up to the plate.
In enterprise situations I agree with you wholeheartedly. Everyone should be responsible for their individual roles and be able to rely on the performance of their peers. As a freelance developer I agree that it is a lot of hats to wear, but someone has to do it. I believe that teamwork and project management are what seperates enterprise projects from freelance development.
In all, I’m glad to see the change in attitude lately as more developers become concerned and aware of security. To often in the past I believe that security was viewed as a commodity instead of an approach. Those that publicly voice their opinions and bring issues like this out into the open are the ones who are helping change the way people view this language (PHP). Thanks!
In all, I’m glad to see the change in attitude lately as more developers become concerned and aware of security. To often in the past I believe that security was viewed as a commodity instead of an approach. Those that publicly voice their opinions and bring issues like this out into the open are the ones who are helping change the way people view this language (PHP). Thanks!
Thanks, Eric. Nice point about security being an approach, not a commodity.
> So where do we draw the line, divide up the responsibility, and make
> sure applications are safe end-to-end? In a well-run corporate
> environment, I still believe the developer should only have to focus on
> the security that happens between input and output. It makes a chaotic
> world manageable.
I just realized something. When I said that filtering input and escaping output doesn’t protect you from everything, I wasn’t referring to those things that are outside of a developer’s control. I was referring to things like session fixation and cross-site request forgeries (there are others) - these are application attacks. Filtering alone doesn’t protect against them, because they both "follow the rules," so to speak. You have to take other steps to protect your applications from these types of attacks.
Pretty much all of my advice is specific to a PHP developer writing code. I write and speak about application security, very rarely environment security. Even in my shared hosting recommendations (where I do talk a bit about environment security), most of my recommendations are from a developer’s perspective.
So, to summarize, I think filtering input and escaping output are the most important things a developer can do, and anything less is unacceptable. However, I don’t want my enthusiasm to mislead ayone into thinking that these steps alone protect from from all application attacks, because they don’t.
Maybe that clears things up.
> sure applications are safe end-to-end? In a well-run corporate
> environment, I still believe the developer should only have to focus on
> the security that happens between input and output. It makes a chaotic
> world manageable.
I just realized something. When I said that filtering input and escaping output doesn’t protect you from everything, I wasn’t referring to those things that are outside of a developer’s control. I was referring to things like session fixation and cross-site request forgeries (there are others) - these are application attacks. Filtering alone doesn’t protect against them, because they both "follow the rules," so to speak. You have to take other steps to protect your applications from these types of attacks.
Pretty much all of my advice is specific to a PHP developer writing code. I write and speak about application security, very rarely environment security. Even in my shared hosting recommendations (where I do talk a bit about environment security), most of my recommendations are from a developer’s perspective.
So, to summarize, I think filtering input and escaping output are the most important things a developer can do, and anything less is unacceptable. However, I don’t want my enthusiasm to mislead ayone into thinking that these steps alone protect from from all application attacks, because they don’t.
Maybe that clears things up.
I definitely think that helps clear up what you are saying. What I’m saying is that all these forms of attack come via some form of input — in the case of session fixation, it is via $_SESSION. Which is why I say it is a form of input that should not be trusted carte blanche.
The solution, however, is not necessarily filtering. But it is dealing with input with an understanding of how trustworthy that input really is. So, using secondary checks on $_SESSION data, for example, are a good way to eliminate these kinds of problems. Likewise with cross-site attacks, embedding time-specific, site-specific data that you can check (i.e. adding input you know you can trust) will help defeat this.
This whole discussion has led me to a new definition of "hacking" — it is:
"The creative manipulation of unintended input to acheive an unexpected side effect."
By "unintended" here we could mean overly-trusted.
Ultimately, however, the point I am trying to make is that the motto for secure programming in PHP is, "know thy input." Not just how to filter it — how well you can trust it, even when as Chris says it seems to "follow the rules."
I think this is an important revelation and distinction for PHP developers — focus on those points of input — to not get immired in the confusion trying to determine the scope of what they need to know to be secure.
The solution, however, is not necessarily filtering. But it is dealing with input with an understanding of how trustworthy that input really is. So, using secondary checks on $_SESSION data, for example, are a good way to eliminate these kinds of problems. Likewise with cross-site attacks, embedding time-specific, site-specific data that you can check (i.e. adding input you know you can trust) will help defeat this.
This whole discussion has led me to a new definition of "hacking" — it is:
"The creative manipulation of unintended input to acheive an unexpected side effect."
By "unintended" here we could mean overly-trusted.
Ultimately, however, the point I am trying to make is that the motto for secure programming in PHP is, "know thy input." Not just how to filter it — how well you can trust it, even when as Chris says it seems to "follow the rules."
I think this is an important revelation and distinction for PHP developers — focus on those points of input — to not get immired in the confusion trying to determine the scope of what they need to know to be secure.
That’s pretty much correct, but I just want to correct one thing that I keep seeing stated.
> What I’m saying is that all these forms of attack come via some form of input
> — in the case of session fixation, it is via $_SESSION.
and
> But it is dealing with input with an understanding of how trustworthy that
> input really is. So, using secondary checks on $_SESSION data, for
> example, are a good way to eliminate these kinds of problems.
Session data is not external data. This is a very common misconception, and while I’m not sure if it’s what you’re thinking, it’s how I think your statements are going to be interpreted. A user has no direct control over session data, e.g. data within $_SESSION.
> What I’m saying is that all these forms of attack come via some form of input
> — in the case of session fixation, it is via $_SESSION.
and
> But it is dealing with input with an understanding of how trustworthy that
> input really is. So, using secondary checks on $_SESSION data, for
> example, are a good way to eliminate these kinds of problems.
Session data is not external data. This is a very common misconception, and while I’m not sure if it’s what you’re thinking, it’s how I think your statements are going to be interpreted. A user has no direct control over session data, e.g. data within $_SESSION.
Thanks, Chris — I know it comes from a local source, but can see how others might get confused. The point is the PHPSESSID is user input, and it tells PHP what to grab for $_SESSION.
"The creative manipulation of unintended input to acheive an unexpected side effect."
Uhh, that’s the CLASSIC definition of a hack!
It just goes to prove: if you want a new idea, read an old book.
Uhh, that’s the CLASSIC definition of a hack!
It just goes to prove: if you want a new idea, read an old book.
Really?
Dictionary.com gives this:
"To use one’s skill in computer programming to gain illegal or unauthorized access to a file or network: hacked into the company’s intranet." or " To gain access to (a computer file or network) illegally or without authorization: hacked the firm’s personnel database."
And Wikipedia says:
"…a progamming exploit, or a commercial software breakin."
Could you point me to another source that gives a definition that is the same or very similar to mine?
Dictionary.com gives this:
"To use one’s skill in computer programming to gain illegal or unauthorized access to a file or network: hacked into the company’s intranet." or " To gain access to (a computer file or network) illegally or without authorization: hacked the firm’s personnel database."
And Wikipedia says:
"…a progamming exploit, or a commercial software breakin."
Could you point me to another source that gives a definition that is the same or very similar to mine?
Really.
I know that wikipedia is cool and google is godsend, but amazingly they are not always complete or accurate. To make matters worse, the meaning of "hack" has been hijacked over the years (and now is taken to mean roughly what "crack" used to mean) — so I can see why you’d think that you have stumbled on a "new" meaning for the word hack.
From: http://www.urbandictionary.com/define.php?term=hack
"1. A clever or elegant technical accomplishment, especially one with a playful or prankish bent. A clever routine in a computer program, especially one which uses tools for purposes other than those for which they were intended, might be considered a hack."
Of course, this is probably the meaning that resulted in "hack" to become what was "crack" — exploitation of an unintended result.
One intersting point that I realize from this: in the future, will people only believe that which can be linked? I’m old enough to remember the old meaning of "hack" before it had the "crack" connotation.
Alas, I’m probably just an old hack but it seems that everything old is new again, yes?
I know that wikipedia is cool and google is godsend, but amazingly they are not always complete or accurate. To make matters worse, the meaning of "hack" has been hijacked over the years (and now is taken to mean roughly what "crack" used to mean) — so I can see why you’d think that you have stumbled on a "new" meaning for the word hack.
From: http://www.urbandictionary.com/define.php?term=hack
"1. A clever or elegant technical accomplishment, especially one with a playful or prankish bent. A clever routine in a computer program, especially one which uses tools for purposes other than those for which they were intended, might be considered a hack."
Of course, this is probably the meaning that resulted in "hack" to become what was "crack" — exploitation of an unintended result.
One intersting point that I realize from this: in the future, will people only believe that which can be linked? I’m old enough to remember the old meaning of "hack" before it had the "crack" connotation.
Alas, I’m probably just an old hack but it seems that everything old is new again, yes?
I think the point I was trying to make is that whether you call it ‘clever tools’ or a ‘programming exploit’ or anything else, it comes down to input that was not expected by the programmer. I’ve seen more romantic descriptions of what hackers do, but nothing quite as distilled as this: "unexpected input, unintended side effect." Maybe not new, but certainly compact.
Maybe Norbert Mocsnick can tell you:
http://norbert.mocsnik.hu/blog/archives/119-Enterprise-PHP.html
But seriously, the enterprise is taking ahold of PHP and I know this because I have presented PHP/MySQL solutions to some very big clients here in the USA. Unfortunately, I can’t name names due to non-disclosure agreements (whether it was me or PHP they were ashamed of I’ll never know
).
In my experience, the enterprise is characterized first by sheer size and then by the need for business critical applications. The latter is nearly every eCommerce shopping cart installation out there — it has to be up, stay up, and stay secure. The enterprise is used to paying for these factors, but is also always looking to reduce the fabled total cost of ownership.
The enterprise is not some 15-year old kid’s web forum for his friends to post jokes. The enterprise is corporate, is hungry for profit, and has PHP in its crosshairs. Time to deliver.
http://norbert.mocsnik.hu/blog/archives/119-Enterprise-PHP.html
But seriously, the enterprise is taking ahold of PHP and I know this because I have presented PHP/MySQL solutions to some very big clients here in the USA. Unfortunately, I can’t name names due to non-disclosure agreements (whether it was me or PHP they were ashamed of I’ll never know
).In my experience, the enterprise is characterized first by sheer size and then by the need for business critical applications. The latter is nearly every eCommerce shopping cart installation out there — it has to be up, stay up, and stay secure. The enterprise is used to paying for these factors, but is also always looking to reduce the fabled total cost of ownership.
The enterprise is not some 15-year old kid’s web forum for his friends to post jokes. The enterprise is corporate, is hungry for profit, and has PHP in its crosshairs. Time to deliver.
