>
Agreed.
> 1) extract($this->handler_vars). While this does make it nicer/easier
> to code, it can be dangerous.
It's very dangerous, and even harder to tell where data came from.
Don't use it.
> 2) validate, validate, validate.
> If your method expects an object of type
> FooBar cast it to a FooBar object (same for int, array) etc...
Better yet, use type hinting when possible:
function baz(FooBar $f, array $x) { ... }
> then validate some more. If a string can only be 255 utf-8 chars long,
> validate that it is no more that 255 uft-8 chars. If the string is a
> URI/Email addy, validate that it only contains valid characters for
> that scheme. If an int can only be of certain values, ensure that it
> is. etc..
Email is almost impossible to validate. I agree that it's good to
validate for the right characters, but which ones are the right one?
There's a lot of bad validation being done on the 'net. See Mastering
Regular Expressions for an example of how complicated email validation
can get. We might want to supply a set of optional "trusted"
validators in core, or in a plugin (once we have dependencies).
> 3) **** ALL (non-trusted) user supplied data that is sent to the DB,
> MUST be filtered with InputFilter. This includes data from 3rdparty
> services not just human users; twitter, delicious, etc..
With PDO, we can easily push this out to the DB layer for almost all
queries. Using prepared statements, most data doesn't even need to be
properly escaped before being passed over to the driver (though
everyone SHOULD still validate validate).
> .4) ALL (non-trusted) user supplied data assigned to a theme, MUST be
> sanitized.
Agreed.
> 5) WSSE in the admin provides another layer of validation to ensure
> the request to admin is a valid request.
Is this the CSRF token?
> 6) the fact that AdminHandler separates GET and POST requests, is
> ignored on some admin pages. We should ensure that GET requests ONLY
> display data, and POST requests ONLY change data. This is part of
> validating the data came from the proper location, mentioned above.
This isn't actually a security concern beyond some "trip wire" type
stuff, but the W3C mandates that you use GET for read and POST for
read or write.
>
FWIW, I've run our internal security tools (possibly improperly, I'm
not an expert on them yet) on the public side of my local install and
it didn't find anything (though it did find the now-patched username
XSS before I updated).
I'm going to run it on the admin side stuff... once I figure out how
to make it log in (-:
S
--~--~---------~--~----~------------~-------~--~----~
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/habari-dev
-~----------~----~----~----~------~----~------~--~---
