Blip on the PHP blogosphere

Discussions of secure PHP coding. Security in software is important, so don't be afraid to ask. And when answering: be anal. Nitpick. No security vulnerability is too small.

Moderator: General Moderators

User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Jenk wrote:My personal opinion is that none of this "blame" should be on PHP at all.. hell, would it be PHP's fault if I hosted a script like the following on the public domain?

Code: Select all

<?php

eval ($_GET['v']);

?>
no, it certainly would not. :)
Nobody is talking about "blame" because we are talking about living project. I hope you are not saying that there should be no discussion of ways that people think PHP can be improved. PHP has become what it is today, in part, because of these types of public discussions.
Jenk wrote:I think we are looking at this the wrong way completely (when I say we, I mean everyone) If there is a fault with the Zend engine itself that can be exploited, then yes - that is a PHP fault, otherwise it is all down to the developer.
Again, it's not anybody's fault. The discussion is about how difficult it should be to shoot yourself in the foot. It is my opinion that currently you need to know too much to write secure apps. PHP has a steady history of fixing these problems -- but the problem space has been expanding much faster than the solution space in recent years.
Jenk wrote:I actually disagree with the "built in filtering" idea.. what happens if someone learns a few bits on PHP, it works "safely" then they go onto other languages and find a whole manner of holes in their logic..
That's really the other language's problem and not PHP's. Because PHP is so widely use and used by so many newbies, I think it has different needs that, say, assembly language regarding security.
Jenk wrote:I'm also a power freak, I want the code to do what *I* want it to do (within reason.. I'm not about to go and start entering 1's and 0's :P). Nothing more, nothing less. I very much dislike the dumbing down of application development when the kid gloves are put on. :)
I'm not saying that you should not be able to get to the raw value for $_GET['v'], but I think the basic usage should be more secure. There are thousands of lines of code in the PHP Code Forum where request variables and put directly into SQL. If it had no effect on your ability to "do what *I* want it to do" (meaning there was still a way to get direct values) then why not make that standard coding practice safer?
(#10850)
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Maugrim_The_Reaper wrote:That said there is room for some minimal security measures in PHP itself. Take the recent change to header() as an example (see http://derickrethans.nl/php_442rc2_released.php ).
I think this is a good example of what I am talking about. The header() call is common one in PHP. But the fact that there has been this arcane exploit out there means that something needs to be done. The choice was to make all PHP programmers responsible for knowing this arcane bit of knowledge or pluggin the hole -- and they did the latter. I agree that it is hard to know where to draw the line, so it is really a case by case basis.
Maugrim_The_Reaper wrote:As for whether a deeper set security level is required - well, not so certain. The bits added in earlier times didn't go all that well ;). Then again if you take the outlook of needing to do something to protect developers from themselves maybe...
That's one of the biggest problems with PHP, but also its open source nature. Open source evolves in a very messy fashion. Lots of things are tried and the bad ones are (hopefully) exposed and removed. One can argue that many things, from magic_quotes to PEAR, where good ideas but not the best implementations.

I think that even though "protect developers from themselves" is saying it in a negative way that some of that is necessary. Languages usually provide a recommended or natural way to do things. Those ways should not require more knowledge than can be reasonably expected from those how use it. And the following is too common, and too natural, to not do something about.

Code: Select all

$v = $_GET['v'];
$sql = "UPDATE t SET v='$v'";
(#10850)
User avatar
Jenk
DevNet Master
Posts: 3587
Joined: Mon Sep 19, 2005 6:24 am
Location: London

Post by Jenk »

arborint wrote:Nobody is talking about "blame" because we are talking about living project. I hope you are not saying that there should be no discussion of ways that people think PHP can be improved. PHP has become what it is today, in part, because of these types of public discussions.
That is taking what I said out of context. Improvement != Dumbing down. It is also very much the blame game. If nobody (incorrectly) criticised PHP for being so 'insecure', then where would the need for this very discussion/topic be?
arborint wrote:Again, it's not anybody's fault. The discussion is about how difficult it should be to shoot yourself in the foot. It is my opinion that currently you need to know too much to write secure apps. PHP has a steady history of fixing these problems -- but the problem space has been expanding much faster than the solution space in recent years.
Need to know too much, or just plain don't know enough? The difference may be obvious, but it's a big difference. Are we expecting too much of a language to do most of the work for us, without sacrificing too much of the power?
arborint wrote:That's really the other language's problem and not PHP's. Because PHP is so widely use and used by so many newbies, I think it has different needs that, say, assembly language regarding security.
Now who is playing the blame game? :P
Why don't these newbies use a WYSIWYG that has 'intelligent' filtering/escaping? This would be a better option imo, like riding a bike.. you stick on stabilisers until the kid is ready to ride unassisted.
arborint wrote:I'm not saying that you should not be able to get to the raw value for $_GET['v'], but I think the basic usage should be more secure. There are thousands of lines of code in the PHP Code Forum where request variables and put directly into SQL. If it had no effect on your ability to "do what *I* want it to do" (meaning there was still a way to get direct values) then why not make that standard coding practice safer?
Not having $_GET['v'] provide the raw data provides a multitude of problems. First off, which method of escaping should be used? Secondly.. having to go an extra length to get the data as-is will quite frankly aggrevate exprienced programmers who know how to handle user input properly. We already have these problems with magic_quotes, which are slated to be removed in PHP6 I hear.. would you call that a step in the wrong direction?
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

Jenk wrote:
arborint wrote:I'm not saying that you should not be able to get to the raw value for $_GET['v'], but I think the basic usage should be more secure. There are thousands of lines of code in the PHP Code Forum where request variables and put directly into SQL. If it had no effect on your ability to "do what *I* want it to do" (meaning there was still a way to get direct values) then why not make that standard coding practice safer?
Not having $_GET['v'] provide the raw data provides a multitude of problems. First off, which method of escaping should be used? Secondly.. having to go an extra length to get the data as-is will quite frankly aggrevate exprienced programmers who know how to handle user input properly. We already have these problems with magic_quotes, which are slated to be removed in PHP6 I hear.. would you call that a step in the wrong direction?
I think the bigger problem is the way we are teaching our newbies. In our haste to provide quick code examples with minimal effort, we neglect most of the security aspects in order to keep it simple. The newbie uses the code, it works, and that's the end of that until their site gets hacked. Personally, I don't think there's any satisfactory solution to this problem: it's a balance between how much time you have to help.
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

Ambush Commander wrote:I think the bigger problem is the way we are teaching our newbies. In our haste to provide quick code examples with minimal effort, we neglect most of the security aspects in order to keep it simple. The newbie uses the code, it works, and that's the end of that until their site gets hacked. Personally, I don't think there's any satisfactory solution to this problem: it's a balance between how much time you have to help.
I agree it is the problem, but the direct and natural way should be the secure way as well. I really don't think that Jenk would suffer too much if in the PHP documentation (which for newbies is the same as "hidden" ;)) it said you could do:

Code: Select all

$v = $_GET['v']->getUnfiltered();
But if newbies used the normal $_GET they would get filtered values that maybe only had printable characters or some other reasonable measures taken.
(#10850)
User avatar
Ambush Commander
DevNet Master
Posts: 3698
Joined: Mon Oct 25, 2004 9:29 pm
Location: New Jersey, US

Post by Ambush Commander »

The ignorant way is probably not the secure way.
Post Reply