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)
Re:mysql_escape_string, mysql_real_escape_string, (Score:4, Interesting)
mysql_escape_string and mysql_real_escape_string should both work (assuming you're using MySQL, anyway), but the former is deprecated as PHP 4.3.0 in favor of the latter; it also does not respect the current character set setting.
If you looked at the documentation for addslashes [php.net], though, it will tell you nice things like An example use of addslashes() is when you're entering data into a database even though there are special characters that it does not escape that can be used for SQL injection.
My beef with PHP is that it's full of junky functions like mysql_escape_foo() in the core distribution, main namespace, which don't even have a hint of data verification in 'em. I hear there's a neat database abstraction layer in PEAR, it even has prepared statements. But I'll wager there are plenty of PHP developers who haven't even heard of PEAR. Somehow, though, Perl seems to have managed to put together a decent standard distribution without this sort of mess...
Re: (Score:3, Insightful)
Re: (Score:2)
So the argument that the developers of PHP could do more does seem valid! And the point that the previous poster made about lots of poorly coded functions, also seems valid.
Re: (Score:2)
I've only recently got into using PHP myself. I am an experienced programmer, but it is surprisingly difficult to find a good solid way to properly escape MySQL statements. And before anyone asks, I'd write a function myself (like I've previously done with ASP/SQL server), but MySQL itself seems to allow.... lets say, at lot of "flexibility" in the encoding that can be used, and similarly, I couldn't easily find a complete description of this.
And sadly, googling for answers tends to pull u
Re: (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
Re: (Score:2)
Re:mysql_escape_string, mysql_real_escape_string, (Score:3, Informative)
None of the above, use bind variables instead.
Re:mysql_escape_string, mysql_real_escape_string, (Score:4, Interesting)
I dont mind prepared statements for when they are usefull, but they dont always work properly. And actually there are many cases where using them you actually lose power. Lets start with a simple example of the LIKE clause :
SELECT * FROM titles WHERE notes LIKE ?
For the unfamiliar, like clause allows me to do partial searches over strings (char/varchar in the sql world). The LIKE clause search string syntax is something of a simplified regular expression. This means that characters that usually have one meaning gain another one. For example the percentage sign becomes a wildcard (think dos/bash filename matching with '*', or regexp with '.*'). For example, all string starting with 'word' we would just search for 'word%'. Great, but how does prepare/binded statement know if the given percentage is to be escaped or not. It doesnt. So you end up doing own user parsing. You are back to square one. You need to still parse user input, so whats the point of binded/prepared statement? Another example is using power provided through fulltext index. Generally, string searching is slow. In SQL world we do an index, a cache to speed up looking. Strings have indexes, but that only speeds up searching for string that start with something (like in above example LIKE 'word%') but what if we want to search for something purely inside the string ?? then we could do LIKE '%word%' but thats slow, on the other hand, we could speed this up by various smart caching and indexing of the contents of the string. This smart indexing we call 'full text'. For example to see if a column contains some word or phrase we could just do
SELECT * FROM myData WHERE CONTAINS (column, ?)
all ok, right? NOPE, because it also could be :
SELECT * FROM myData WHERE CONTAINS (column, 'FORMSOF (INFLECTIONAL, ?)')
To explain slightly, the second examples tries to find words that are not exact, but very close. So for word 'good' another word 'best' could be used as an alternative (with a lower relevancy ranking). Great power?? Yes, but the first time the sql expects the query in the form CONTAINS ( notes , ' "word" ') notice single and double quotes while later its CONTAINS(notes, 'FORMSOF (INFLECTIONAL, word)') notice, no quotes allowed...
and dont even get me started with the
SELECT * FROM myData WHERE column IN ( ? )
The IN clause is a speed over a series of OR statements. I could write WHERE column = 1 OR column = 2 OR column =3 or I could just do it with WHERE column IN ( 1,2,3) . And now the question for the binding gurus. How do I do it with prepared statements ?? Do I create a loop and both generate the SQL and fill a flat array with the right amount of paramenters WHERE column IN ( ? , ? , ? , ? ) , or do I just send arrays within arrays.
SECOND : parameter binding through naming :
cant wait for when parameter binding can be done in a templated fashion, so that no longer order of the columns matters, currently the way you fill prepared statement with data matters by order of the data. It all should be done with associative arrays.
$sth = $__db->prepare ( "select * from myData where cond1 = ? and cond2 = ? " ) ;
$res =& $__db->execute ( $sth , array ( $userInput1 , $userInput2 ) ) ;
it should be done more like
$sth = $__db->prepare ( "select * from myData where cond1 = ?userInput1 and cond2 = ?userInput1 " ) ;
$res =& $__db->execute ( $sth , array ( "userInput1" => $userInput1 , "userInput2" => $userInput2 ) ) ;
There is no special need to input more -- if you want, use the first method just pass non associative array, and library should know to handle param binding in old way -- but for any larger querry, with dozens of parameters, this will be a big boon in readab
Re: (Score:3, Informative)
When you're using like statements, you will have to pre-process things, yes. Most notably, escaping % and _ plus any other rules you want to implement (* to %, ? to _, explode on spaces with multiple LIKE statements to search on keywords, etc...).
Parameters are intended for user input. I certainly hoping you aren't allowing users to type functions in directly...
As for IN, I build up the placeholders using something
Re: (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
Trick question! (Score:2)
Tool safety (Score:3, Interesting)
Re: (Score:3, Funny)
Re:Tool safety (Score:5, Interesting)
Re: (Score:2)
As a student pilot (I should have my license by Feb/March) I've read quite a number of crash analysis reports, as well as a large number of articles reporting "near misses", all in General Aviation. (lightweight, personal planes)
It's just amazing to me how many of these incidents are caused by things like the pilot shu
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: (Score:2)
The engine catches fire ? Not that that justifies putting the switch where it's easy to hit it by accident, not putting any kind of safety device (a button you need to push to move it, or something like that) on it, and not coloring it yellow with black stripes and a text with large red letters right next to it saying: "DANG
Interesting... (Score:2)
You might learn something.
Re: (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 proba
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: (Score:2)
People who use shared hosting systems have one of three problems:
1. The errors are shown for everyone to see. (display_error on)
2. The errors are hidden in the syslog or error_log where they can't see them. (display_error off, log_error on)
3. The errors are thrown away completely. (display_error off, log_error off)
The other catch is that packaging syste
Re: (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: (Score:2)
I would almost agree with you because this would be a perfect time for me to wave my Perl is Better flag. But there is a point to this story but there's also a nasty history to PHP as a language.
There are many choices to which language you want to make a website/webpage in and there is a pretty reasonable opportunity in any of them to horribly insecure things. Given the best language, an idiot can make it insecure. As a corallary even the worse language can be made secure. Even BASH can be done securly
Re: (Score:3, Funny)
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.
Re:The problem is .... (Score:4, Informative)
Re: (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.
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: (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.
"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 t
Re: (Score:2)
So basically you're admitting that it is PHP's fault, and that other languages don't have nearly as severe a problem with insecurity-by-default. I'll agree.
In a perfect language, a security hole should always be an error of commission, never an error of omission. No language is perfect, but in that respect, most are a damn sight closer than PHP.
Re: (Score:2)
I wrote my first DB abstraction in PHP/FI in 1997. I've never ever used PHP for anything other than web development as it's not explicitly designed for anything else. The previous quote is from someone doing what any professional PHP programmer knows not to do. Trying to program non-web applications in PHP (forgive me if you mean you arent experienced enough to m
Correctness is not being taught to neophytes (Score:2)
A few years back (circa 2002), I whipped up a rapid application prototype with PHP while working off from some on-line tutorials and using Beginning Php 4 (Programmer [amazon.com]
This is easy to test empirically (Score:5, Interesting)
I have to agree.. (Score:2)
SQL escaping considered evil... (Score:5, Informative)
SQL Escaping is evil.
Why?
Because no user input should ever be executed. EVEN if it is escaped. The problem is that the escaping can be invalid and buggy and thus, insecure.
People should use parametric SQL statements. No excuses. In this manner, no escaping is ever necessary.
A separate issue is what to do about displaying user input. Here, things are more problematic, especially in the world of HTML. What would be nice is if we all got together and redesigned "the web" so that user input could be handled in a manner similar to parameters in SQL.
Obviously, there's a difference between data in tables and data in a formatted page. But I'm sure something could be done.
Re: (Score:2)
(snip)
People should use parametric SQL statements. No excuses.
Agreed, however:
In this manner, no escaping is ever necessary.
You're still going to have problems in languages like Javascript that have methods like "eval()". I don't know if PHP has one (I'm just starting to look at it this week, I'm not a fan of web development in general), but if it does, all the SQL escaping in the world won't necessarily matter. You can't escape for multiple different languages
Re: (Score:2)
Re: (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 thos
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You can also install your app on another server of the same os and be almost guarenteed of the same functionality, as opposed to installing the latest cpan module on a server you just configur
Re:I have to agree.. (Score:5, Informative)
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
$sth = $dbh->prepare("SELECT foo, bar FROM table WHERE baz=?"); $sth->execute( $baz );
PHP 5.2 ships with PDO [php.net] (PHP Data Objects) extension which can run with your example code provided you load the extension in your php.ini (yes, I know its a setting that is not done by default, but that argument doesn't hold water with PHP 5 anymore). PDO also supports the prepared statements [php.net] and parameter bindings [php.net] of which you speak, and along similar lines, you can also do transactions [php.net]. You should be clear about which version of PHP your referring to as PHP 4.4 is no longer considered the main release and also has not been updated since August while PHP 5 was last updated in November.
Though I can still agree that not all the choices made in the development were the best. AFAIK, every language has human developers and humans are not perfect, but we do do the best we can and have to continually aim to improve ourselves and the work we create.
Re: (Score:2)
Re: (Score:2)
Hasn't been around long enough. It takes longer than a year (+ 1 month 17 days since PHP 5.1.0) to change your stripes. PHP 4 is still the standard that you need to write your code to if you want to be sure Average Joe can run it at his mom-and-pop web host without funky settings. PHP 4 is still the language of dozens of tutorials on the 'Net. PHP 4 is still running dozens of production sites th
Re: (Score:2)
The people who give PHP its bad rap don't know about those things, or why they should use them, and they outnumber me 10:1. Unfortunately, when they go to http://us2.php.net/mysql_query [php.net] to look up what is quite possibly the only PHP function they actually know, there's nothing except some gibberish in a comment halfway down the page with a poorly-written DIY solution and no link to the resources the clued folks know ab
Re:I have to agree.. well... not really. (Score:2)
As far as SQL injection, every RDMBS access method that I know of allows the developer to execute arbitrary queries. The trick isn't to have automatic SQL escaping (again, the language/framework isn't smart enough to dif
what's the purpose of a language, anyway? (Score:3, Informative)
I mean, why can't we all just write our code in assembly language and get it over with?
The fact of the matter is, that a programming language is a productivity tool. It is supposed to enable the programmer to more simply express complex actions rather than having to deal with all of the low-level particulars.
PHP advertises itself thus:
So, should the language be "idiot proof"? No, not necessarily, but it should certainly make secure programming hard not to do.
A good example of this approach is that taken by the OpenBSD project when it redesigned some of the low-level C library string manipulation functions to make them "more secure" in that they eliminated the programmer's ability to make certain, common, mistakes.
I don't look at this as a "stupid" versus "smart" issue. It's a "does my programming language help me do X or not?" issue.
So, stop blaming the programmer and find ways to make their already busy lives easy.
Re:what's the purpose of a language, anyway? (Score:4, Interesting)
Re: (Score:2, Interesting)
And people should take responsibility for the cars they drive and the pollution they create.
Of course, it would seem to me like a lot of people believe that there's a certain social value in asking the producers of cars and heavy equipment to improve the quality of their products.
As with anything, one should select the right tool for the job they are trying to do. If you need to write a complex site, pick a tool that allows you
Re: (Score:2)
Agreed: developers should absolutely take responsibility for the code the write
Yep, this includes the developers of the PHP language itself. :)
My personal opinion is that PHP should come out-of-the-installer with *all* its security features turned on. Safe_mode, register_globals, syscall restrictions, open_basedir set to the home directory even. Then, all the new PHP devs to the language will more likely work with these features. Of course, they can still be turned off if necessary, but I hope less people will do that.
Re: (Score:2)
Same thing here with PHP. Yeah, its fun and
Re: (Score:2)
Also, error_reporting(E_ALL); will make PHP throw warnings (but not die) when it runs in to undefined variables.
Re: (Score:2)
Yes, it really is. Perl has had "taint mode" forever. This forces the programmer to validate all input before passing it to things like database queries or open(), system(), etc. Instead of a coding error causing you to lose all your data and take out your web server, the program will just exit. Having the compiler double-check your work is always easier than wondering if you got everything.
Adding to that is the fact that PHP has never had a sane
Re: (Score:2)
The problem with PHP is that insecure code doesn't look like insecure code
If the "include" primitive was renamed to "includehostilecode", it would still be useful, but its shar
Re: (Score:3, Insightful)
Re: (Score:2)
If this is how published security experts write PHP, I pray to god that I never have to look at any entry-level
Re: (Score:2)
An entire class of common web-programming bugs, Cross Site Scripting, could be eliminated if people would use DOM.
Currently, common practice for dynamic web applications is to build your output HTML document piece by piece, string-wise, splicing variables left and right to get the desired result. Unless you're extremely diligent in properly encoding plaintext to HTML (meaning changing <, >, &, and sometimes " and ' into HTML character entity references), you will slip up and people will find wa
Re: (Score:3, Insightful)
PHP gives us the flexibility to deliver,
Re: (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.
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: (Score:2)
Reminds me of Spock in Star Trek IV.
Speak for yourself (Score:2)
I do it differently, I move away from languages such as C *only* when necessary. Safety measures are indispensable, but there is such a thing as overdoing it. Motorcycle drivers should use helmets, but not truck drivers. Car seats should have safety belts, but not bar stools. And so on.
When I do a web page that will get input from the outside world I take care to use parameterized queries, but when I do a quick developme
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: (Score:2, Insightful)
Looking at your list, I see complaints about:
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: (Score:2)
What? PHP has even worse syntax. Everything requires parentheses @print(foo(@$bar[$this->baz()->something(array(1,2 ))->else()])). At that point, you might as well be using LISP. Not to mention that 90% of PHP's syntax is completely useless and has no reason for existing. (Why bother with dollar-signs in front of $variables when EVERYTHING IS THE SAME TYPE? Why bother with an OO model that uses interfaces when THERE
Re: (Score:2)
See http://tnx.nl/php [tnx.nl] for a great comparison.
Re: (Score:2)
register_globals is off by default, and has been that way for a long time. Anyone who turns it back on deserves what they get. It's a dead issue. magic_quotes is headed for the same fate in PHP 6. They seemed like good ideas at the time the web as young; they turned out not to be.
They'll be dead issues when they are removed completely from PHP. Too many tutorials and existing PHP applications turn them on if they aren't by default. As for "good ideas", they never were.
Configurable logging and reporti
Re:Who's fault? Zend's (Score:5, Informative)
From your post: "magic_quotes: This adds slashes to all input so that you don't have to sanitize it before it gets inserted into SQL."
BUT that is so totally the WRONG thing to do and a MISFEATURE, and the fact that the PHP developers made it a big feature of PHP shows why they and PHP suck. Think I'm being harsh? Read on.
This is what any sane programmer should do:
Each input source for YOUR application should be _individually filtered and escaped so that _YOUR_ application can handle the inputs correctly.
Each output destination for your application should be _individually_ filtered and escaped[1] so that the RECEIVING programs/entities can handle your app outputs correctly.
Example:
Say some data is http posted to a PHP web app, and the PHP app then sends the resulting data to a MySQL database, an Oracle database, syslog, and in some cases also emails some of that data to an email address, or redisplays the data in an HTML form on a web browser (required field left out).
magic_quotes would add slashes to the data when it enteres the web app, and that CORRUPTS the data. The resulting munged data _might_ still work for MySQL, but as is be incorrect for Oracle and SMTP (<lf>.<lf> needs to become <lf>..<lf>), data to syslog should have ctrl chars removed or escaped _appropriately_ and to be safe kept < 1024 bytes in length, and data to an HTML form shouldn't have the added slashes, but instead be appropriately quoted for HTML.
My proposal would have the web app filtering/escaping the data so the webapp can handle it, and then escape/filter stuff appropriately for MySQL, Oracle, SMTP, syslog and HTML. It seems like more work, but it is the correct way. It is less work in the long run especially if you make/use the appropriate libraries.
Once you understand the above, you should see why magic_quotes is so TERRIBLE, and why I have a low opinion of PHP and Zend.
And magic_quotes is not the only PHP misfeature that makes PHP PHP. You have named a few already.
Basically PHP makes doing the wrong thing easy, but the right things hard[2].
[1] by escaping/filtering I also include use of "SQL prepared/parameterized statements".
[2] After all these years it's still not clear what DB abstraction layer/library to use for PHP - there's the PDO vs PEAR DB thing, and PHP users are still resorting to crap like addslashes and magic_quotes. If each PHP coder writes their own DB library, anyone else taking over has to learn it. PHP should have learnt from the other languages mistakes.
For perl you use DBI, for Java you use JDBC.
All this crappiness has to be blamed on the developers who made PHP.
there's plenty of blame to go around (Score:2)
almost every php book or tutorial I've seen does incredibly dumb and insecure things... creating sql queries by concatenating strings without escaping input data, not using htmlentities, using global variables... that's an sql inection or xss problem waiting to happen.
PHP makes it easy to do dumb things and harder to do the correct thing. There's a low barrier to entry, so many php "programmers" don't know what they're doing. (this also applies to javascript...).
PHP is no worse than C. (Score:4, Funny)
PHP gives you lego bricks. Most PHP users, for some inexplicable reason, try to eat them and choke.
Re: (Score:2)
Pretty damning statement. (Score:2, Insightful)
Developer's Fault (Score:2)
This doesn't seem to change when the language changes, either.
There are simple fundamentals that good programmers follow that the bad ones do not; Correct error handling and reporting, data validation, etc., etc.
If it was the language's fault, or the fault of the tools, companies like Yahoo and Google wo
Re: (Score:2)
Companies like Yahoo and Google use it for non-critical applications because they can easily hire as many minimum wage code monkeys as they need. When you're a big company, that hiring liquidity can often outweigh the fact that developing code is probably more expensive in PHP than sane languages. There's a reason why Google uses C++, Python, and Java for most things.
Speaking as a PHP Framework Developer (Score:5, Interesting)
PHP- making wrong things easy & right things h (Score:2)
Just using the infamous (mis)features that make PHP PHP, automatically make your code bad. e.g. magic_quotes, register_globals, addslashes etc.
PHP - making the wrong things easy, and the right things hard.
[1] http://ask.slashdot.org/comments.pl?sid=216482&cid =17570018 [slashdot.org]
Re: (Score:2)
Like ruining screwheads with the wrong bit? (Score:2)
Re: (Score:2)
If that's the only bit that comes in the set, yes. PHP could have deprecated its old single-string DB APIs. It didn't. People still use them, and sometimes they even take your credit card data with them.
You have to know a tool's limitations (Score:2)
The greatest flaw to PHP is that it opens up more power than many of its users can handle. When you had to compile CGI binaries, it placed explicit limits on who could work on web apps. Now? The power that was once reserved for a handful of good programmers is opened up to all sorts of non-programmers and novice programmers.
What is needed is better education. An up-front warning to the non-programmers about what exactly it is they are getting themselves, their clients and their clients' customers int
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 hea
Crowd Psychology (Score:2)
Re: (Score:2)
What all of the "PHP is insecure" claims refuse to recognise is that virtually all of the vulnerabilities reported would be no different had the application been written in some other language.
Most complaints seem to revolve around PHP's SQL handling and PHP.ini inconsistencies. Can you name another programming language where the language semantics can be altered via a global ini file? How many other languages advocate using insecure functions in the official manual? To quote the PHP manual on addslashes:
Returns a string with backslashes before characters that need to be quoted in database queries etc.
And:
An example use of addslashes() is when you're entering data into a database.
This would rather suggest to those unfamiliar with the language that addslashes should be used to database input, rather than using the quoting function provided by the database libra
Both (Score:2)
Having said that, the language certainly has an influence on what (security) bugs can be made or are likely to be made. As I've ex
Security is about education (Score:3, Informative)
And this isn't just the fault of the developer. Unfortunately there's too many resources and options available, all of which have differing and conflicting methods for accomplishing something. Letting an uneducated developer decide which option to pick, I would agree, is not desirable.
But let's be clear on something: I design, build, and deploy enterprise-grade PHP applications for multi-million dollar projects. If there's a security problem discovered, it is my or my team's fault that we didn't protect against it. It's my responsibility to be educated enough to diagnose and prevent security threats in an application. I cannot say to the client, "PHP is inherently insecure", and expect that reason to fly and absolve myself of all responsibility.
I clearly do not understand why this excuse is the predominant argument here. "PHP is inherently insecure" is simply not true. PHP certainly doesn't encourage proper programming practices from the beginning, but by the same token, I can't recall a programming manual that doubled as an education tool in design and security practices that, combined, allowed me to write bulletproof code from the very beginning.
Easy: Hackers are to blame. (Score:2)
Apart from that it is, of course, my responsibility to keep my website safe, n
Re: (Score:3, Informative)
Re: (Score:2)
You are making the troubling assumption that ONLY developers are going to need to upload files to their sites.
How else are authorized end users going to be able to upload files for your script to process? To risk overusing a cliche, this is Web 2.0 here! The majority of users don't care about what FTP is, nor do they want to learn something new just to post a file to a website!
An upload script is perfectly fine as well as the security behind it stops people from posting or touching files they shouldn'
Re: (Score:3, Interesting)
The absolute worse thing ever in PHP is how until recently, SQL injec
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
See thats the point. The reason we use higher level languages in the first place is partly so that we have a safety net. Its not just a matter of developer competence. Nobody is perfect. Everyone makes mistakes. Ideally the language should be able to catch them sooner rather than later. Why would I want to use PHP if one mistake could hose my security?
Noones saying the developer is bl
Re: (Score:2)
If your PHP security policy is full of stuff like "remove semi-colons", then it highlights your ineptitude - unless PHP doesn't offer a better way of escaping user input other than getting the user to do it on a case by case basis, in which case that highlights the ineptitude of the PHP developers. In a framework designed with security as a primary concern, features like prepared statements and database specific escaping built into the driver are essential. This is how Perl's DBI works, and also how Java's
Re: (Score:2)
Re: (Score:2)
No, SQL injection works because PHP forces you to do validation. Hardly any other language than C forces you to do that. Perl, Python and the others have sane database interfaces that BY DEFAULT let you get away with no validation or escaping. Leaving it up to every single developer to properly handle this on their own is madness.
Re: (Score:2)
The thing is, the vast majority of PHP users don't even understand that there is a problem. PHP is a language used mainly by beginners, and actively aimed at beginners, but it is not designed to be used by beginners. It's a landmine-filled sandbox.
Thus, the internet is full of SQL injection vulnerabilities.
Blaming every PHP programmer for not being a security expert is idiotic. Most programmers aren't, and they wouldn't need to be, if the language was designed proper
Re:PHP == fucked (Score:4, Informative)
How many times has this been said, and how many times do people need to point to examples like Wikipedia [wikipedia.org], YouTube (partially), Yahoo, Google, Facebook, and much more for proof of scalability?
And if you mean PHP doesn't scale architecturally, then you've demonstrated that you've never worked in an environment that did effectively scale PHP, or you simply failed at it. I'm going to guess both.