|
|
Posted by Edward Vermillion on 07/08/05 19:20
On Jul 8, 2005, at 4:21 AM, <nick.telford@ntlworld.com> 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@doggydoo.net
Navigation:
[Reply to this message]
|