[geeklog-devel] Re: [geeklog-devtalk] Variable best practices
tony at tonybibbs.com
Wed Mar 3 14:38:58 EST 2004
> I don't disagree and using $_REQUEST would remove the need to check both GET
> and POST.
> I wonder though, if it is not still more secure to check for $_POST before
> $_GET. I know a hacker can just as easily fake a POST request so maybe it
> does not matter. As long as we are filtering out any potentially hostile
Right, see injections can happen, in theory any time you go to the
database (via a select, update, etc it doesn't matter). So those fields
should be filtered. How you do that doesn't matter and my hunch is just
going after the data in $_REQUEST is good enough as it handles everything.
Now, in Geeklog 2 we are using PEAR and thus I am using prepared SQL
$prepStmt = $_DB->prepare('SELECT * FROM USERS WHERE uid = ?');
$result = $_DB->execute($prepStmt,$_REQUEST['uid']);
To handle injection attempts I plan on creating a method called
DB_execute() that mirrors the PEAR execute method above except I will
pass all arguments through the filter which should provide a convenient
way of filtering stuff without having to have to explicitly do it every
Anyway, just wanted to clue you in on how I have been thinking through
all this. For 1.3.x your function is good and the only drawback is you
have to call it explicitly but I don't see a way around it.
> I suspect our issues are mostly with users that host their sites.
Yeah, and again, most sane hosts should be on 4.1 or better already.
> It also has a mode to address the need for Register_Globals on.
There is a lot that would need to be done to 1.3.x to get rid of this
but if you move forward assuming 4.1. or better at least we can mark
each page as a to-do in terms of getting rid of that dependency. Then
again, maybe this should be somthing similar to when I introduced HTML
templates where we plan on freezing the code and working on nothing but
register_globals issues and releasing that under 1.4.x.
That is something for Dirk to ponder but I'd be willing to help knock
out a few pages. With three of us we might actually get a beta version
of this out within a couple of weeks.
More information about the geeklog-devel