[prev in list] [next in list] [prev in thread] [next in thread] 

List:       quanta
Subject:    Re: [Quanta] Kommander news and fund raising
From:       Eric Laffoon <eric () kdewebdev ! org>
Date:       2008-02-27 0:58:37
Message-ID: 200802261658.37331.eric () kdewebdev ! org
[Download RAW message or body]

On Tuesday 26 February 2008 4:26:55 pm Andrew Lowe wrote:
> On Wed, 27 Feb 2008 10:21:05 Eric Laffoon wrote:
> > On Tuesday 26 February 2008 3:01:14 pm Andrew Lowe wrote:
> > > I would hope that you are not suggesting to upload projects to the
> > > production server via HTTP using PHP.  PHP, and therefore Apache would
> > > need write permissions to the project which would introduce a major
> > > security risk...
> >
> > Actually I'm suggesting using a password protected area and HTTPS.
> > Anything else would be nightmarish as you would be exposing yourself to
> > all kinds of evil.
>
> The problem is that the unix permissions would have to allow the webserver
> to write to any directory or file that you want to be able to replace. 
> This means that any script (php/perl/ruby,etc) would be able to write to
> these files (change/modify them).  This is usually not too bad if you are
> writing data such as photographs or word/pdf documents to the folders, as
> you tell apache that it cannot execute php/perl, etc in that folder.  I
> have had a php server exploited in the past by spammers using just this
> meathod (inject php file into a directory, then execute it to use my host
> as a spammer portal), and since make sure that all web-server writable
> folders cannot execute scripting languages.

You know, actually I'm thinking really only of using this for download, but 
doing 10 things at once. Actually any form submission on a server is a means 
of exploit, and there was a lot of it going around. I think much has been 
patched, but it's impossible to do it all. I picked up some PHP functions and 
tweaked them years ago just fo this to "remove evil tags".

function removeEvilTags($source,$allowedTags="")
 {
    $source = strip_tags($source, $allowedTags);
    return preg_replace('/<(.*?)>/ie', "'<'.removeEvilAttributes('\\1').'>'", 
$source);
 }
function removeEvilAttributes($tagSource)
 {
        $stripAttrib = "' (style|class)=\"(.*?)\"'i";
        $tagSource = stripslashes($tagSource);
        $tagSource = preg_replace($stripAttrib, '', $tagSource);
        return $tagSource;
 }
 These are to strip out tags put in submission forms.
>
> It only takes one file the user has uploaded in the server-writeable
> directory to have a security issue to be exploited and this can happen -
> wholesale replacement of the site.  The fact that the original script uses
> https and a password is required does not matter if one of the uploaded
> files is exploited.

Sure, and it's more secure just to download, which was my primary purpose, as 
Quanta already has upload facilities. However I'm not sure how many servers 
are set up like this. Actually I haven't used anything like this for a while 
so for all I know it's the default, but as i said my primary purpose was to 
augment the fact that Quanta doesn't synchronize. However cleaning cruft 
could be a pointof contention as it obviously needs write abilities.
>
> > > The other option I could see this as is a PHP script on the server
> > > listening on a specific port, again a potential security risk - unless
> > > bugs are really kept fixed regularly.
> >
> > To me it's academic as it would be up to the user to implement their
> > security features and place the file. If done right it's vastly more
> > secure than FTP and if done wrong... It seems any convenience can offer a
> > downside of disaster.
>
> Yes it is more secure then ftp, but in some ways not... there really is not
> way to secure the site from this type of exploit if you want to use this
> method of uploading php ( or other executable type ) files.  The directory
> must be webserver writable to allow any php script to upload.  The way to
> secure this would be to copy the files to somewhere not accessable via
> http, then have a script running as a user other then the web server move
> them, perhaps via cron, or other methods.  This would not be convenient to
> support as it would be as complicated as using SVN.  An exploit in Apache
> or PHP could also be used to hit this directory... and insert evil
> scripts...  This is why it is recommended that apache cannot write to web
> folders.

Actually we set up SVN on a test server because Andras swore it was easy. Of 
course easy is a relative term not wise to use in the same sentence 
with "Andras" because within a few minutes of first looking at PHP he could 
already do things I had trouble sorting out. ;-)

It seems to be a universal frustration that there is no certain way to insure 
compatibility of any program interaction with a server. 
>
> > > Using Rsync would be good option - it is what I tend to use for backups
> > > and stuff, and works over ftp, sftp, ssh, and other protocols - just
> > > using the command line.  For project synchronizing I tend to check my
> > > local project into SVN and then update/check-out from the production
> > > machine (and the opposite for those changes done on the production
> > > machine) for - works well with PHP code (no compiling) - also make sure
> > > that .svn folders are forbidden in Apache.
> >
> > I use rsync with Gentoo. I should look at it and see how suitable it
> > might be to make a plugin with.
>
> running in BASH:
> if ! rsync -q -a --delete -e "ssh -q  -i myssh.key" ${PROJECT_FOLDER}
> ${USERNAME}@${SERVER}:${PROJECT_PATH} then
> 	echo 'backup failed'
> else
> 	echo 'backup worked'
> fi
>
> seems to work for me - getting variables would be one of the harder parts -
> I think you can specify the password on the command line - but for my
> backup jobs i use keys stored in a file. (oh and watch the --delete !)

I'll take a look at this, however it would be easy enough using ssh to list 
and compare, even to use a timer and alert of changes. The paradox of a handy 
program is if you want to do other things not consistent with it's interface 
it proves to be handy in less places. ;-)
>
> > > It would be good to understand what method you are suggesting....
> >
> > Actually I'm looking for suggestions. All my preferred ways to accomplish
> > this seem not to be working and my alternate choices are currently under
> > investigation. In any case I want to come up with something that is easy
> > for me to impliment within Kommander, which I'm quite fast with, and make
> > available as a plugin.
>
> Hope these comments help...

yes they do, thanks

-- 
Eric Laffoon
Project Lead - kdewebdev module
_______________________________________________
Quanta mailing list
Quanta@mail.kde.org
https://mail.kde.org/mailman/listinfo/quanta
[prev in list] [next in list] [prev in thread] [next in thread]