Page 2 of 2

Posted: Fri Dec 22, 2006 3:39 pm
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!

Posted: Fri Dec 22, 2006 3:56 pm
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...

Posted: Fri Dec 22, 2006 4:00 pm
by Luke
looks interesting... I'm interested... :D

Posted: Fri Dec 22, 2006 4:04 pm
by Christopher
I think prepared statements do about the same thing, and they are probably more powerful and standard.

Posted: Fri Dec 22, 2006 4:27 pm
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)

Posted: Fri Dec 22, 2006 4:38 pm
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.

Posted: Fri Dec 22, 2006 4:41 pm
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..

Posted: Sat Dec 23, 2006 8:10 am
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

Posted: Sun Dec 24, 2006 7:13 am
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.

Posted: Sun Dec 24, 2006 8:21 am
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...

Posted: Sun Dec 24, 2006 11:29 am
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.

Posted: Tue Dec 26, 2006 10:50 am
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

Posted: Tue Dec 26, 2006 11:23 am
by Luke
MrPotatoes wrote:there is so little in terms of decent security literature
ahem... viewforum.php?f=34 :D

Posted: Tue Dec 26, 2006 12:53 pm
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.