[geeklog-devtalk] geeklog-devel digest, Vol 1 #285 - 1 msg

[geeklog-devel-request at lists.geeklog.net]

Send geeklog-devel mailing list submissions to
	geeklog-devel at lists.geeklog.net

To subscribe or unsubscribe via the World Wide Web, visit
	http://lists.geeklog.net/listinfo/geeklog-devel
or, via email, send a message with subject or body 'help' to
	geeklog-devel-request at lists.geeklog.net

You can reach the person managing the list at
	geeklog-devel-admin at lists.geeklog.net

When replying, please edit your Subject line so it is more specific
than "Re: Contents of geeklog-devel digest..."


Today's Topics:

   1. Re: Re: [geeklog-devtalk] Variable best practices (Tony Bibbs)

--__--__--

Message: 1
Date: Wed, 03 Mar 2004 13:38:58 -0600
From: Tony Bibbs <tony at tonybibbs.com>
To: geeklog-devel at lists.geeklog.net
Subject: Re: [geeklog-devel] Re: [geeklog-devtalk] Variable best practices
Reply-To: geeklog-devel at lists.geeklog.net


> Tony,

> 

> 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

> data.


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 
statements:

$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 
time.

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.

--Tony


--__--__--

_______________________________________________
geeklog-devel mailing list
geeklog-devel at lists.geeklog.net
http://lists.geeklog.net/listinfo/geeklog-devel


End of geeklog-devel Digest