Controversial Article? PHP Security
Moderator: General Moderators
Controversial Article? PHP Security
Hey, my friend sent me this link. It had me all <span style='color:blue' title='I'm naughty, are you naughty?'>smurf</span> and upset. http://www.theregister.co.uk/2006/12/21 ... rutinised/. Take a look and give me your opinion. Should security issues be soley the responsibility of the programmer or the language itself? I'm kind of on the fence with this one. I'd be interested to know where other people stand.
-
impulse()
- Forum Regular
- Posts: 748
- Joined: Wed Aug 09, 2006 8:36 am
- Location: Staffordshire, UK
- Contact:
I believe it should be up to the developer to secure their code. Language writers can't iron the language to suit everbodys requirements.
I don't think security measures are pushed enough on learning developers. I've been self teaching myself PHP for just over 4 months now and tutorials I've read and watched only seem to cover well know security issues such as SQL injection. I'm reading through the security section of the PHP manual as I post and it's covering flaws I've never heard about before.
I don't think security measures are pushed enough on learning developers. I've been self teaching myself PHP for just over 4 months now and tutorials I've read and watched only seem to cover well know security issues such as SQL injection. I'm reading through the security section of the PHP manual as I post and it's covering flaws I've never heard about before.
- seodevhead
- Forum Regular
- Posts: 705
- Joined: Sat Oct 08, 2005 8:18 pm
- Location: Windermere, FL
The burden of security definitely falls upon the script's developer... not the language as a whole. Reason being, it is the responsibility of the developer to know the limitations of the language he/she is working in, and also be fully aware that it may or may not be the best choice for each particular application. There is no language that is secure. Security is not a finite aspect of development, nor is security ever truly achievable. The closest you can get is by subscribing to the notion of "defense in depth". The more layers of preventative measures taken to thwart malicious attempts, the more piece of mind one can attain.
Completely agree.seodevhead wrote:The burden of security definitely falls upon the script's developer... not the language as a whole. Reason being, it is the responsibility of the developer to know the limitations of the language he/she is working in, and also be fully aware that it may or may not be the best choice for each particular application. There is no language that is secure. Security is not a finite aspect of development, nor is security ever truly achievable. The closest you can get is by subscribing to the notion of "defense in depth". The more layers of preventative measures taken to thwart malicious attempts, the more piece of mind one can attain.
It's too easy to blame the language itself. We want to be able to write, update and delete data to a database from our PHP apps, don't we? We want to be able to send mail, isn't it? With all those tools in our hands comes a responsibility. And because PHP is used by a lot people of which many are amateurs at best, it's not surprising that a lot of them don't have the means to write secure scripts.
But it's not (only) their fault.
The one thing that surprises me again and again is how many articles and "tutorials" just skip the whole "security thing". For example, in just a few pages an explanation is given how to write a complete forum, guestbook, cms, etc. Without mentioning one thing about security measures. Without any trace of htmlentities or mysql_real_escape_string!
(to give an example, of course it's more then just those 2 functions)
And when you point that out to the author, you get a) no response b) a defensive reply c) weak excuse. ("it's only an example").
Imho the problem with PHP is that it gives beginners the impression that they can get started very easily.. Unfortunately, the opposite is true since you have to be aware of all the potential dangers that exist for each 'external system' ( = html output, sql dbms, shell, ... ) you're going to communicate with.. (And no, you only become aware of this when it bites you...)
But i think we've just had that discussion a couple of weeks ago (started because of a slashdot writing...)
But i think we've just had that discussion a couple of weeks ago (started because of a slashdot writing...)
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
impulse() wrote:I believe it should be up to the developer to secure their code. Language writers can't iron the language to suit everbodys requirements.
I don't think security measures are pushed enough on learning developers. I've been self teaching myself PHP for just over 4 months now and tutorials I've read and watched only seem to cover well know security issues such as SQL injection. I'm reading through the security section of the PHP manual as I post and it's covering flaws I've never heard about before.
I like these statements. And I agree with them. Any language, if incorrectly applied or insecurely used, will have security issues. Even HTML can be written in a way that results in malicious execution of code. Developers should be responsible for their code, and not just in the area of security but in all areas (optimization, clarity, portability, extensibility, etc).seodevhead wrote:The burden of security definitely falls upon the script's developer... not the language as a whole. Reason being, it is the responsibility of the developer to know the limitations of the language he/she is working in, and also be fully aware that it may or may not be the best choice for each particular application. There is no language that is secure. Security is not a finite aspect of development, nor is security ever truly achievable. The closest you can get is by subscribing to the notion of "defense in depth". The more layers of preventative measures taken to thwart malicious attempts, the more piece of mind one can attain.
PHP, as a language, has it's greatest strength and greatest weakness in the same aspect of the language: it's ease of production of scripts that perform wanted tasks. Brand new developers can literally copy a snippet of code from a tutorial, paste it into their text editor, save it as a PHP file, put it onto their web server and in no time flat have a working script. Unfortunately this can lead to all sorts of problems since a lot of code that newbies use hasn't been properly validated, sanitized or protected against malice. But a newbie doesn't know that. They know that what the tutorial said would happen, happens. And for a lot of new developers, that is all that matters. Which is something I would consider a weakness of the language. Of course, because it is so easy to learn and use, PHP has developed a huge following of coders, guru's and evangelists. Which I would consider a strength of the language.
But in any event, when it comes to accountability for programs, that should lay squarely on the hands of the developer of the program. In my opinion.
It makes sense that the most popular scripting language would account for the most security issues... that's a no-brainer...The article wrote:PHP likely account for 43 per cent of the security issues found so far in 2006
http://www.nexen.net/images/stories/php ... bal.en.png
- RobertGonzalez
- Site Administrator
- Posts: 14293
- Joined: Tue Sep 09, 2003 6:04 pm
- Location: Fremont, CA, USA
Those points stand out the most to me. It kinda says that PHP is not the issue, but amateur developer are more of the issue.That article wrote:... the need for better security in PHP-based web applications.
... web applications written in PHP likely account for 43 per cent of the security issues found so far in 2006, up from 29 per cent in 2005. While flaws in the language itself account for a very small percentage the total, the problems with PHP underscore the difficulty that developers - many of them amateurs - have in locking down applications written in the language...
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
On this topic (and many others
) I agree with timvw. It would be fine to say "it's the programmers problem" if the "problem" had not been dealt with already, quite nicely, by almost every other system than PHP. The fact is that the design (or non-existence of) input filtering/validation and output escaping in PHP is due to a lack of understanding by the language developers. They have tried to solve the problem several ways: magic quotes, super globals. The problem is that the solutions -- compared to what other languages have done -- are simply not very good. They allow the inexperienced to easily write insecure code while at the same time being inelegant for experienced developers. The current input filter extension and the FilterInput classes in the Zend Framework indicate that we are probably still another major iteration from them understanding how to implement a good solution.
In case anyone is listening -- hint -- Request and Response classes with plugin Filters
In case anyone is listening -- hint -- Request and Response classes with plugin Filters
(#10850)
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
As examples, Java's java.io package, Ruby's CGI, and C#'s System.IO all provide filtering and escaping in a straightforward way. Python is more like C/C++ but provides libraries. Realize that print()/echo() is still the standard way shown to newbies to output and that raw data in superglobals is still the standard for input. Yikes! There has been a long time to add and encourage the use of safer alternatives.shiznatix wrote:how have other languages solved this problem?
(#10850)
Can't really argue with that... until this forum, I'd never heard of escaping/filtering input/output.arborint wrote:As examples, Java's java.io package, Ruby's CGI, and C#'s System.IO all provide filtering and escaping in a straightforward way. Python is more like C/C++ but provides libraries. Realize that print()/echo() is still the standard way shown to newbies to output and that raw data in superglobals is still the standard for input. Yikes! There has been a long time to add and encourage the use of safer alternatives.
- shiznatix
- DevNet Master
- Posts: 2745
- Joined: Tue Dec 28, 2004 5:57 pm
- Location: Tallinn, Estonia
- Contact:
So maybe if PHP offered a function say print_safe() for output that was auto escaped and whatnot and for input they would throw an E_NOTICE or E_WARNING error if they tried to use a superglobal without first running some standard function on it? Like for the superglobal stuff:
That way if they where a newbie they would be like 'whoa, php says that this is unsafe so i best just do it real quick' and thus would do what other languages did but offer the more advanced users the ability to deal with the raw input the way that they see fit to do.
Ya?
Code: Select all
echo $_POST['Thing']; //Throws an error
$Thing = $_GET['Thing']; //Throws an error
$Thing = standard_escape($_GET['Thing']); //no errors!
//OR (pretend this is now a new page)
show_escape_errors(false);
$Thing = $_GET['Thing']; //NO ERROR! back to standard php behaviourYa?
- Christopher
- Site Administrator
- Posts: 13596
- Joined: Wed Aug 25, 2004 7:54 pm
- Location: New York, NY, US
Well there is now filter_input(source, name, filters), so how about a escape_output(string, filters) as its opposite. Encourage their use and discourage $_GET/$_POST and echo/print. You don't need to remove the old stuff or break anything, just start a campaign make sure the old way is considered crap and people will change.
(#10850)