PHP Application Insecurity - PHP or Devs Fault? 200
somersault asks: "There have recently been a lot of people making jokes at the expense of PHP, but how many common security flaws in PHP are the fault of the language, and how many the fault of the developer? A recent Security Focus article (via the Register) has a brief discussion which suggests that PHP is no less secure than any other scripting language, and that it is the users of the language themselves who need to be educated. The other side of the story is that the developers of PHP should work on tightening up the language to make it more 'idiot proof' by default. Should the team developing PHP take a more active role in controlling the use of their language? What will it take to ensure that users of the language learn to use it securely, short of defacing every vulnerable website out there?"
mysql_escape_string, mysql_real_escape_string, etc (Score:2, Insightful)
The problem is .... (Score:5, Insightful)
The same can be said about any other language. Take for instance, C. Very easy to create working code that's vulnerable as hell. Is this the original author's fault? Of course not. I'm sorry that whoever chose to write a webapp in PHP is ignorant of basic security principals, but it's not up to the coders of PHP to protect us from ourselves.
A bit of both, I'd say. (Score:1, Insightful)
Possible options for SQL injection attacks, for example, include Perl's "tainting" mechanism. Where does this string come from? The outside world? Right, it's considered tainted. Any manipulation that puts the string (or even just a part of it) into another causes that string to be tainted as well. No tainted string can be sent as an SQL command to a database, although it can be sent as a parameter. If you absolutely have to include it in an SQL command, there could be a function that de-taints the string: so that quotes and similar are escaped, to remove the ambiguity, for example.
For example, instead of constructing a string 'SELECT * from FOO where BAR="(string from the outside world)"', you'd construct a string 'SELECT * from FOO where BAR=:parameter1'. You'd then construct a set, saying parameter1 = '(string from the outside world)', much like Python's dictionaries. Then you'd call the database: execute this SQL command, and these are the parameters to go with it.
Last time I looked, you could do the latter part (but not the former part) with Oracle databases under PHP, but nowhere else. Why not? This is a very basic way to avoid 99% of the SQL injection cases out there
Re:what's the purpose of a language, anyway? (Score:2, Insightful)
I mean, you could make the same degenerate argument about Windows and OS's, but something tells me it would sound just as lame.
Re:I have to agree.. (Score:1, Insightful)
Re:I have to agree.. (Score:3, Insightful)
PHP pretty much invites you to be insecure with MySQL. They ship with this tempting mysql_query() that takes as an argument... a single string. (well, and a connection ID). To get something in there, you need to do something like mysql_query("select * from foo where whatever = '$var'") -- and remember to have $var properly escaped. PHP does not give you a pretty library with prepared statements, parameter binding, and such. There's a nice DB and MDB2 package available on PEAR, but PHP doesn't ship with those. It ships with the compile option --with-mysql.
Perl ships with a fair amount of stuff. It ships with a package named DBI. You can do things like $rv = $sth->execute(@bind_values);. The documentation on it starts off with a convenient set of good examples which go like
You can write code in PHP that's perfectly secure, you can do just about anything in PHP you could do in Perl (props for being Turing-complete, I guess), and yes, it ultimately is the developers' responsibility to secure their applications, not PHP's. That doesn't change the fact that PHP is an ugly mash-up of a language with Bad Choices just lying around in a scrap heap on the ground begging to be used. It's just about as organized as a scrap heap, too... (insert generic rant about naming conventions, parameter ordering, and such).
Re:The problem is .... (Score:3, Insightful)
It all comes down to knowing what you're doing in the language you're coding in. If you're not good enough to sanitize, error check, bounds check, mem check, fault check, and whatever the hell else could go wrong, you have no business coding.
It's YOUR problem, not anyone else's. Don't pass the buck. If you don't like that, choose another language.
Yes (Score:4, Insightful)
Fact of the matter is, real security comes from having many layers. Having a programming language that directs you to safe practices and actively prevents you from creating unsafe code is the first line of defense. Yes, the programmer needs to educate him or herself on how to write secure code, but given that people are not perfect, the language should have a safety net.
There's a reason that we've moved away from languages such as C, except when necessary.
And from what I've seen, PHP has really encouraged bad programming practices. Preferring escaping SQL strings instead of proper parameterized queries, register globals, etc.
Re:Tool safety (Score:2, Insightful)
Wow. If that's your actual, honest opinion, you scare me. It looks like "personal responsibility" is all but nostalgia for people. You know, I can make a chainsaw that I can guarantee almost 100% won't cut you, but it probably won't cut any wood either. In fact, while we're at it, we should make chefs use plastic cutlery, because gosh darn it, they might hurt themselves with those big, sharp, metal blades.
Tools are tools. While tools can certainly be poorly designed, they should never be crippled just because people might "hurt themselves." This applies for real tools and it applies for software.
Who's fault? Zend's (Score:5, Insightful)
It's always the developer assuming something about PHP or the PHP environment but getting it wrong; you can argue that the developer should know, but there are so many gotchas in PHP, you have to be an expert to be aware of them all. (I've listed some in a previous post [slashdot.org] on
This isn't right for any language, but a language which web applications run on?! The most hostile environment to develop for is not the place for a language that makes it so easy to trip up!
The fault, for the vast majority of PHP security problems, is completely Zend's. Zend needs to give security priority over backwards compatibility, and get rid of all of their problems that developers repeatedly trip up on.
Re:what's the purpose of a language, anyway? (Score:3, Insightful)
Re:The problem is .... (Score:5, Insightful)
I think the point is that we're all human and we all make occasional mistakes even with the best of intentions. There's plenty of code out there written by very experienced C programmers that still has buffer overflows and other glitches. That means that having a language that has the facility to make such errors easier to catch and correct early is a good thing. That means that having a language that pushes you toward secure practice by not having sloppy easy ways to do things is a good. Yes, we could all, in theory, write perfectly secure error free code in C or PHP or whatever, but in practice we don't - no one does. Languages that encourage best practice by default and provide the tools to catch errors earlier (with, say, design by contract) are a good thing if security is important. We're all human, and can use all the help we can get.
Re:Tool safety (Score:5, Insightful)
Have you ever used PHP? If not, take a look at the following features:
- addslashes() [php.net] function - Most references say to use this to quote data before putting it into a database. Not only is it The Wrong Way To Do It (twwtdi) according to the SQL standard, but different vendors' databases need different values escaped.
- Magic Quotes [php.net] ini settings. magic_quotes_gpc is the most important one. When enabled, it runs addslashes() on all GET, POST, and cookie input. It is on by default in php.ini-dist, off by default in php.ini-recommended. Which brings up my next point...
- The programming environment is not consistent. An INI file [php.net] controls the programming environment. Turning on things like Safe mode [php.net] and open_basedir can cause previously working code to suddenly fail. Of course, php.ini-dist has display errors [php.net] turned on by default, so anyone visiting that page will see the location of your file, the line that has the error, and which error it is... Which brings up the next point:
- Security is secondary to convenience. See Using remote files [php.net], which is enabled in both ini files by default. See also Magic Quotes as described earlier. Reading up on the deprecated Register Globals [php.net] is informative, as it was on by default up until PHP 4.2.0. I've also mentioned display_errors, which is on in php.ini-dist.
To summarize: The PHP team has made a number of questionable decisions over the years that makes it much easier to write a security hole than it should be.Here's a disturbing fact: php.ini-dist is the more ocmmonly used of the two inis, at least for shared hosting. I'll let you consider the implications of that while I summarize things.
Re:Who's fault? Zend's (Score:2, Insightful)
Looking at your list, I see complaints about:
It's easier to trip up badly in C (by commiting some memory buffer error) or Perl (by writing line noise code that you can't understand a week later) than PHP. But it's no longer fashionable to bash those languages.
Apparently what you see as "problems", others see as features.
Re:The problem is .... (Score:3, Insightful)
"Sanitized" is a generous way of saying "not binary-safe", which also means "not internationalized" and "doesn't work in edge cases". Most of the time, if you have to \"sanitize\" input, instead of accepting and properly encoding <em>any</em> possible input, you\'re doing something wrong.
As for error checking, bounds checking, "mem checking" (what is that? avoiding memory leaks?), "fault checking" (how is that different from error checking?), etc, those are tasks that a computer can do much more reliably than any person. If, realizing that, you still can't see how hopelessly stupid your argument is, then I suspect you're the one who has no business coding.
You would totally fail at investigating plane crashes.
Re:Who's fault? Zend's (Score:5, Insightful)
Same goes for register_globals; and it's hardly a non-issue as it's enabled just about everywhere in the name of backwards compatibility. In the article I wrote the site that got exploited had a vulnerability exposed by register_globals.
You bet it's a bug when only critical errors are reported by default. Errors in code aren't shown, and users don't realize that there's a problem in their code until it's being exploited.
I don't think you can blame the developer for this. If they develop with magic_quotes on, or register_globals off, or error reporting >E_WARNING, they may not realize the variable in the include string is writeable, and they probably wouldn't realize you can include remote documents anyway.
What about add_slashes() not escaping everything that mysql_escape() does? Or mysql_escape() not escaping everything that mysql_real_escape() does? What about 5 == "5 OR 1=1"? What about the ability to input arrays (and errors which should be shown when dealing with unexpected arrays aren't printed because of the default error reporting level)? These are bad ideas which make sanitizing input difficult. I wouldn't use C for the web either, and Perl can be very clear. I agree that PHP gets a worse rep than it deserves; I like PHP, and understand that if bash or C was the language of the web they'd be just as bad, but they're not and PHP is.
PHP would be so much better if they fixed the security holes; one of the reasons it gets such a bad rep is because it lets newcomers make mistakes so easily, I'd like PHP to be recognized as the excellent language it is but these security problems aren't helping.
Some see pointers and no bounds checking as useful features, but that doesn't mean they're a good idea for security.
Re:mysql_escape_string, mysql_real_escape_string, (Score:2, Insightful)
For one of the servers I worked on this was the syntax for full text search. you would do CONTAINS ( column , param ) . The argument param was a string that contained additional properties for the full text search engine. One could add things like weights associated with words and phrases (hence double quotes), or ask to search for word variation (search for 'good' also matches 'best', since they are related). Ofcourse, this was all happening in one string, that param, so you had to, yet again, format your own string.
I am not advocating against using parametered sql calls, actually they are great, but I fear that on some level they are not much better than the magic_quotes=on, I fear as if they were an escape for lazy developers : use always, and your code will be unhackable. That was the premise of magic_quotes, it made developers feel safe, as if magically their code was unbreakable.
Now, for stored procedure calls, especially with parameters that double as both input and ouput, the parameter binding is the only way to go.
Cheers
neither and both (Score:3, Insightful)
PHP is secure as in it has the functionality to make secure sites.
PHP is insecure in that some of this is not implemented from the get go.
PHP is flexible as it does not force security on you - if for any reason you are running in an isolated environ or implementing something different attached to PHP.
By not being as strict in variable typing, etc. there are some things that can be done more directly in PHP then in other languages. Though it could cause hidden errors in good code as well.
There is stuff that can be fixed, Zend should get some of the hard housecleaning done (magic quotes, register globals, etc.) in a version # release (those who can't stick with 4 or 5 etc.) Though you then need to get the ISPs to upgrade and all the legacy scripts...
ASP, Java, Perl and Ruby people would like to see more stuff in their languages than in PHP (and will FUD PHP to promote thier cause good or bad).
I chose PHP because:
- it is on most webhosts and distro installers
- a lot of great code and/or projects are readily available in PHP.
- the language does everything I require and then some
- the syntax is VERY easy to read and understand - this includes my own code as well as learning from others.
- it is platform agnostic (no lock-in)
- it is not limited by licensing (if open source, which is ok for me) or vendor-control code restraints
- it works with many platform agnostic DBs also
- even the security issues are well documented and understandable and does teache you a lot more about web security than languages that just do it for you (or that you assume are secure).
So for me I know the drawbacks and I see the benefits, and the benefits are worth the extra effort.
In summary I see that it has worthy merits and also "warning labels", (such as this slashdot post illustrates) the devs will make up thier own mind on using it, get over it.
Every Scripting Language Has Problems (Score:2, Insightful)
I very quickly made a whole series of small web applications to access our internal data - something that I later found out was called an "intranet".
Then, one day, when I was testing a form, I heavy fingered the single quote ' and the enter key on an input box and got some surprising results! The SQL statement got completely destroyed by including the quote in the input box. I actually thought this was fun, and typed in additional SQL to see if I could change the query. It was easy! I made the query do all kinds of weird things. This got me toying with forms that actually did inserts and adding random stuff to the query string and I realized how trivially easy it was to completely subvert all the smallish applications I had written. Thank the Lords of Kobol it was an internal site!
At any rate, I learned, in my safe sandbox, that securing a web application is not trivial nad is something you have to think about from the moment you sit down to code. I developed a bunch of functions to verify the existence of, escape, and validate every single piece of data that is ever passed from the UI to the database. You just have to do it, it's that simple.
Since those early days, I've done sites in Cold Fusion, ASP, JSP, PHP, Perl, WebCatalog and a couple of other oddballs, and I've always started by translating those functions to the new language, using the built-ins of the language when I could. You know what? All web scripting languages that are easy and powerful wind up being insecure in the hands of an inexperienced developer.
And let's be honest, if there was a secure and easy to use web scripting language, we'd all hate it because it tied our hands too much and made us do things a certain way. We, serious developers, love languages that let us do things the way we want to do them. Assembly developers feel confined by C, C++ developers feel confined by Java; HTML hand coders feel confined using Dreamweaver. So honestly, if they came out with SecurePHP, largely not backwards compatible for one thing, would anyone use it?
I know I'd WANT to, in theory, but would I? Would you?
Re:mysql_escape_string, mysql_real_escape_string, (Score:3, Insightful)
Re:Tool safety (Score:5, Insightful)
Why do general aviation planes usually have extremely simplistic, 4-stroke big block engines with carbureators? Because they generally work. They do fail, but their failure modes are very well known, very obvious, and usually easy to fix. Those are important qualities, and I'm willing to bet that you underrate them. If you replaced the aircraft's engine with a modern fuel injected digitally controlled model, what happens if an injector clogs, or the computer goes insane? No one knows, and they're not eager to find out. If your carb ices, you can fix that. In-air, no less. It may be a less reliable design overall, but the failure modes are usually pretty tame. And that's worth a lot to an aircraft designer.
Taking one of your examples regarding the stall indicator/yoke... do you really want to take a piece of equipment which in correct operation is almost *never* going to get used, and hook it up to your primary controls? That's just *asking* for trouble. If the stall indicator ever gets jammed open (it is just a little metal flap after all, it's unlikely but possible), your "safety" measure may well crash the plane on its own.
It's not as easy as it looks. These people are not idiots, they simply have a lot of variables to consider and weigh. And they have a pretty solid track record behind them, too.
Re:Tool safety (Score:2, Insightful)
PHP is much more powerfull and versatile then everybody seems to think.
The only problem is that it seems so easy to master.
Re:mysql_escape_string, mysql_real_escape_string, (Score:3, Insightful)
Does anyone else not see a problem with this? Oh first we had addslashes but a lot of people complained, then we added mysql_escape_string but we decided it didn't work (for whatever reason) so now we have mysql_real_escape_string so people should be happy now. Oh and we have a magic_quotes variable you can set to automatically do this for you, but it might not be enabled on every instance of php.
And then we have:
PEAR::DB is a nice database abstraction (somewhat like perl DBI). Although it's been superceded by PEAR::MDB2. PHP 5 has native PDO, which is also like DBI or DB, or MDB2, but each one has a slightly different syntax.
<sarcasm>Wow, these PHP developers really make it easy to do something simple like query a database! </sarcasm>
First I have a problem with lack of namespaces. Yes, you've heard it before but the above illustrates why it's a problem. If I instead had two libraries, mysql_escape and mysql_escape2 (bad names but bear with me), I could now have them use the same function names so I don't need to have mysql_escape_string and mysql_real_escape_string. To upgrade, I just change what library I include and I'm done. Having all these functions always accessible creates an inconsistent naming of functions.
I currently program in PHP as my real job.... I rarely use it in my personal web based projects preferring python or Perl (Possibly looking into Ruby at some point) because I've come to really dislike the language. However I also don't think it's as bad as some people make it out to be.
Re:what's the purpose of a language, anyway? (Score:3, Insightful)
PHP gives us the flexibility to deliver, while being "lazy", since doing it the "right way" would be overkill, and over costly for the intended purpose / environemnt.
On the other hand at night I still do a great deal of side work. You better believe that the code going on the Internet isin a lot better state than most of my regular work.
Is it better code? No, it is different with a differnet purpose. PHP gives me the ability to choose.
Pretty damning statement. (Score:2, Insightful)