On Jul 8, 2005, at 4:21 AM, <nick.telford@xxxxxxxxxxxx> wrote:
Personally, I don't think it's a bad idea at all. The best way (and
probably ONLY real way) to achieve decent security would be to limit
the subset of tags the user can post. Best way to achieve this is to
use your own tagging system (e.g. [p] instead of <p>) this will allow
you to strip_tags to protect against injections and limit the tags the
author can post (to protect against injection-through-conversion
attacks).
Use a pcre replace to replace all occurances of the allowed tags with
the HTML equivilents upon page rendering (it's usually best to sore
your tag format in the database instead of the raw HTML).
As for SSL, is it really needed? The data would, in most cases, not be
considered highly important. It would just leverage another server
requirement on the end-user. If you're writing something for public
consumption, it needs to be as flexible as possible.
Besides, SSL has very little to do with PHP and is therefore not
really worth thinking about. In order to include support for running
the Administration of the CMS through SSL, simply allow the Admin
pages to run on a different host.
Last word, IP and User Agent tracking are more useless than MAC
filtering on firewalls. In the long run, it'll simply add more
overhead to your application and produce no useful information (unless
you're using it purely for statistics).#
PS: This is going through web-mail, so there's a good chance it might
not reach the list.
Unless I'm really missing something important, for 'this' particular
part of the application, any BBCode/Tag stripping/rewriting
scheme would be useless since what they will be editing is the actual
templates that make the page, therefore all tags
would have to be allowed.
It's not the legitimate user I'm worried about doing something wrong,
it's that if it's possible for a legitimate user to do this,
then some "Bad Guy" somewhere "may" be able to do this too.
I've pretty much eliminated the possibility of someone using say cURL
or some other mechanism to post information
to the form processor directly. If they can guess two md5 hashes of two
different random numbers that may or may not
be set to allow the transaction as well as the ip/user agent associated
with one of the numbers, then nothing I do will
keep them out because they are GOD, or have a _lot_ of time on their
hands. Plus, the clients account will have more than
likely been shut down for going over their bandwidth quota from the
attempts.
[If I'm wrong in my assumptions here, someone please slap me in the
head]
What I'm worried about is someone grabbing a valid cookie id, and in
the short time-span that it _is_ valid, being able to
pull up the actual post form, which will then give them the second
number and the ip/user agent, and "legitimately"
posting malicious code. So yes, SSL is necessary at this point to try
to keep that cookie secret. If it can, which is what
I'm being paranoid about. This is a weak spot in the code "because" I
have to trust that the user is who they say they
are, all things considered. And at this point, I'm relying on SSL to be
the security "rock" that plugs up this hole.
Is SSL enough to keep the cookie safe?
Is it absolutely stupid to allow this, even if there will only ever be
one username/password combo that will be allowed
to access this part? Other parts of the admin console will be open to
other users though.
The actual web site, ie the pages created and maintained by the
application, is open to the public and there is no
SSL there, no cookies or info other than the html request/response of a
'normal' site.
Edward Vermillion
evermillion@xxxxxxxxxxxx
--
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php
