Controversial Article? PHP Security

Ye' old general discussion board. Basically, for everything that isn't covered elsewhere. Come here to shoot the breeze, shoot your mouth off, or whatever suits your fancy.
This forum is not for asking programming related questions.

Moderator: General Moderators

User avatar
Luke
The Ninja Space Mod
Posts: 6424
Joined: Fri Aug 05, 2005 1:53 pm
Location: Paradise, CA

Post by Luke »

Here's a nice little filtering and escaping cheatsheet by Davey Shafik...
http://pixelated-dreams.com/uploads/mis ... tSheet.pdf

I think I'm going to add this to useful resources thread too... :D

EDIT: Arrrgh! Maugrim The Reaper beat me to it!
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

I've once read in http://phpsecurity.org/ the suggestion to use an array that indicates for which context the data will be used... Here's an extension of that thought:

You can only communicate with a set of functions via a 'context' object... Eg: if you want to talk with the mysql_* functions you'll have to pass a MySQLContext instance as parameter...

Code: Select all

$MySQLContext = new MySQLContext();
$MySQLContext->AddVariable('username', $_POST['username']); // every time the MySQLContext is queried about the username it will return a mysql_real_escape_string('username')....
$MySQLContext->AddVariable('place', 'the place i live...', true); // an optional parameter to tell the context that the data should be used 'as is'.. Notice that this not the default behaviour

$MySQLContext->AddQuery('simple query', 'SELECT * FROM users');
$MySQLContext->AddQuery('the query', 'SELECT * FROM users WHERE username=?', array('username'));

mysql_query($MySQLContext, 'the query');
or when you're generating html....

Code: Select all

$HTMLContext = new HTMLContext();
$HTMLContext->AddVariable('title', $_SERVER['PHP_SELF']);

echo($HTMLContext, 'title'); // internaly $HTMLContext->GetVariable('title') is called and htmlspecialchars is applied...
I'm aware that this API is open for improvement ;) I'm aware that there are people that might not like the idea... But i still think it would be a good idea to have such a system... (Even if it has a different name than PHP)...

I'm aware that this more or less would force every function that communicates with something external to php core would have to know which context it's being used in... So in a worst case scenario you end up with as much contexts as there are functions...
User avatar
Luke
The Ninja Space Mod
Posts: 6424
Joined: Fri Aug 05, 2005 1:53 pm
Location: Paradise, CA

Post by Luke »

looks interesting... I'm interested... :D
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

I think prepared statements do about the same thing, and they are probably more powerful and standard.
(#10850)
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

Nothing says we shouldn't take advantage of prepared statements for SQL dbms...

Eg: mysqli_stmt_bind_param($MySQLContext, 'username', 'username');

I think you should see it more as a way to give other contexts the power of prepared statements... eg: if you're talking html output, the parameter binding would internally lead to a htmlspecialchars (unless explicitely told not to do so)... (Imho it's more or less the same than your suggestion for output_something($data, $filter)
matthijs
DevNet Master
Posts: 3360
Joined: Thu Oct 06, 2005 3:57 pm

Post by matthijs »

Tim, did you also read the article by Marco Tabini called "Doing it japanese style" about applying the poka-yoke concept to input filtering and output escaping in PHP architect issue 2 vol 5 (2006)? It seems like a similar concept as you described. A very interesting article.
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

To be honest i haven't been doing much php lately... (Too busy catching up with the .net train... planning to play with ext/filter this week though..) i'll see if i can get a copy of phparch..
User avatar
RobertGonzalez
Site Administrator
Posts: 14293
Joined: Tue Sep 09, 2003 6:04 pm
Location: Fremont, CA, USA

Post by RobertGonzalez »

matthijs wrote:Tim, did you also read the article by Marco Tabini called "Doing it japanese style" about applying the poka-yoke concept to input filtering and output escaping in PHP architect issue 2 vol 5 (2006)? It seems like a similar concept as you described. A very interesting article.
<offtopic>
poka-yoke
kaizen
genshi genbutsu
hoshin kanri

All terms I learned while working for a Toyota automotive manufacturing facility. They have a very successfully philosophy that they apply to manufacuring which can be applied to a lot of other areas.

That just brought back memories. Carry on.
</offtopic
User avatar
Maugrim_The_Reaper
DevNet Master
Posts: 2704
Joined: Tue Nov 02, 2004 5:43 am
Location: Ireland

Post by Maugrim_The_Reaper »

EDIT: Arrrgh! Maugrim The Reaper beat me to it!
Ha! ;)

While I readily agree the majority of security issues are created by developers themselves through ignorance, I also have a healthy dose of scepticism about PHP as a language being innocent. It's not. It really does need a standard approach to handling common security issues. I don't see that coming soon, and there really is no point crying over the past. Developers should get with the programme and learn from the wealth of material on the web to improve security - most of it is so regurgitated it's hard to miss :).

ext/filter is a nice step for PHP5.2, but the sad fact is its simply not being examined, promoted or pushed enough. In many cases developers are solving this sudden imparting of security wisdom by deliberately disabling it using methods that were used to workaround register_globals being off in the past. That developers are taking this approach (again) is bad news - it means folk are relegating the extension to yet another compatibility issue and NOT a potential basis for improving their security. Is it really so hard to see the worth of even limited central functions providing a common API to accessing input? Any good OOP design should be able to use them without much effort in a few parallel classes to current methods (unit tests, and research effort aside :)).

For my current project, a few of us are ditching the Zend Framework Filter_Input class where possible, and creating a similar class with an identical interface which proxies to ext/filter. This will let us use it where available, and only avoid it where it's just not present (options open). Considering this is looking very simple to setup and manage, it's something I'd recommend to anyone using a filtering object or other OOP interface which can be easily adapted to consider. Since ext/filter is standard in PHP5.2 (unless people take up Stefan Esser's call to arms and disable it) it's going to something needing consideration very soon. Would be nice if that consideration did not label it a "compatibility issue" and ignore it as an annoyance.
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:
Sounds like the taint mode some have discussed on PHP internals... We could only wish... I honestly don't see PHP changing too far in that direction, it's hard enough convincing people to migrate to PHP5, without breaking even more stuff in PHP6 - which might be one nail too many in a PHP sized coffin. Auto-escaping at least is easily implementing in a template engine - with some hacking obviously, but there are only so many methods of assigning data to a template - so it's not a hard one to implement. At the function level, it's still up the developer knowing their stuff.
timvw
DevNet Master
Posts: 4897
Joined: Mon Jan 19, 2004 11:11 pm
Location: Leuven, Belgium

Post by timvw »

I'm not sure if i like the API of filter_* though... Trying to return 3 sorts of return values is too much... Personally i'd opt for an interface like int.TryParse in .net, meaning: return a boolean indicating if the parsing succeeded... And gives access to the parsed value (if it succeeded) via a parameter reference...
Value of the requested variable on success, FALSE if the filter fails, or NULL if the variable_name variable is not set.

Code: Select all

$isgoodapi = filter_input(INPUT_GET, 'isgoodapi', FILTER_VALIDATE_BOOLEAN);
if (!is_null($isgoodapi)) {
        if ($isgoodapi === FALSE) {
                echo "the filter fails";
        } else {
                echo "value of the requested variable on success";
        }
} else {
        echo "the variable_name is not set.";
}

And now request ?isgoodapi=false...
User avatar
Christopher
Site Administrator
Posts: 13596
Joined: Wed Aug 25, 2004 7:54 pm
Location: New York, NY, US

Post by Christopher »

The conversation about ext/filter is pretty silly when you consider that straightforward Request and Response objects (SPL?) could solve this problem pretty easily, protecting newbies from foot shooting while allowing experienced programmers to do whatever they need. Even the name of the ext/filter shows how out of touch the implementors are -- using the filter_* namespace for what is really request_* or http_request_* stuff. And look at the interface to ext/filter ... you have to wonder why they are still implementing non-extensible, procedural extensions.
(#10850)
User avatar
MrPotatoes
Forum Regular
Posts: 617
Joined: Wed May 24, 2006 6:42 am

Post by MrPotatoes »

i'm going to go ahead and read this some more but i'll mention that alot of tutorials, books and mentors do not help you with security. or they'll tell you that you need to learn and finding relevant information is little and hard to come by. or completely generic.

it's sad really because i suck with security and could learn some more but there is so little in terms of decent security literature
User avatar
Luke
The Ninja Space Mod
Posts: 6424
Joined: Fri Aug 05, 2005 1:53 pm
Location: Paradise, CA

Post by Luke »

MrPotatoes wrote:there is so little in terms of decent security literature
ahem... viewforum.php?f=34 :D
User avatar
MrPotatoes
Forum Regular
Posts: 617
Joined: Wed May 24, 2006 6:42 am

Post by MrPotatoes »

;)

not the same. one question does not answer all your problems with security.

yes, i do have PHP Security as well, it's not as indepth as i would like.
Post Reply