I'm stumped. I'm not so sure what is the answer to that question. I'll do some research in Google and get back to you if I find an useful answer. You should email the people at iPage as they probably can help you..
Thanks for the pointers..
Have a hunch that the breach itself may be related to a BBS script that someone is running (that'll teach me to offer iPage hosting to a friend). Looks like the script may have been used to upload another script which has been doing the damage..
Just love surprises like this on a monday morning!..
Accepting Sparky's comment about the problem probably being elsewhere, I don't like the idea of having to make the 'image' directory writable to the web server user, so mine isn't..
It's not good policy to have ANY files writable by the user running the web server (and you shouldn't run the web server as root !!!). All the files accessed by the web server should all be read-only. Of course this isn't always possible (if you allow uploads to your server for example)..
But for OSC, this should be and is possible. As a result of locking images/ down, you'll find you can't edit the images from within the admin tool. That's not a problem though; you just do it a different way - upload the files to the server by other means and then move them to the images/ directory using a user that DOES have write permissions (probably root, but necessarily), making sure you set the permissions of the images accordingly..
I see many many times on this board the phrase "...just set the permissions to 0777..." and it makes me cringe. What's the point of having a user / permissions mechanism in the OS if all you are going to do is set the permissions to "come and get me !" ? If your image file permissions had been more restrictive (writable only by root for example) then you wouldn't now be restoring your files..
Anyway, this is what I did and it might help you stop it happening again..
Ps - Another horrible thing are .htaccess files - get rid of them and disable them. Full stop. (unfortunately you almost certainly can't if you have a shared server because things will stop working)..
In an ideal world having no writeable files would be a must, I agree..
Most of the stores that I work on use osC because it lets me set up sites for customers who want to run their own stores without having to get technical about it. The image upload system is an important part of this and therefore a good selling point for osC..
If I removed the feature then I fear I would end up of returning to the horror of using Actinic again...
Htaccess files control how the server is accessed. I would much rather prefer htaccess over admin access with levels. also for redirection if someone tries to access some directories they are not allowed to. ie images, most sites you can to to.
And you can browse all around you want. with htaccess you can set it so that it displays not authorized to access. so if someone wants to take images, they have a lot more work to do in not being able to just click on an image and save it while in the images directory..
With products, if they want the images of the products, they have to go to each individual one, and if the right click is disabled, then they have to view the source, find the image, copy that link to their browser, and go from there..
Again, htaccess is a deterrent to help you manage your site..
So unless you know what you are doing and not worried about security, leave your htaccess files in place...
By their nature, .htaccess files adjust the permissions and security settings of your web server on the fly. If there's a possibility of anyone changing these without you knowing, or sneaking another one in where it's not expected (!), then you have an obvious security issue..
Even if you aren't worried by this, they also have a performance impact; if .htaccess files are enabled, the web server must check for their existence for each and every directory it traverses to find your files, on each and every request. Then, of course, it has to parse the file and apply the policies that it defines. Because of their dynamic nature, they can not be pre-parsed in the same way as the main httpd.conf file..
Even if you have NO .htaccess files, if you have them ENABLED, the web server will still check for them on each request..
Much better to disable them altogether and define your policy in the one place (httpd.conf). It's easier to administer and less likely to go wrong. There is nothing (absolutely nothing) that you can do in a .htaccess file that you can not do in httpd.conf..
If you read the words of any knowledgeable Apache admin (or just look round the apache web site), they will tell you the same thing; .htaccess files are basically a kludge for shared servers. If you have a dedicated server and you fully control the web server then you do not need them and you are better off without them..
I accept your point. I was just pointing out that if you don't want to do this then you don't have to; there are ways round it..
For defining in httpd.conf, the majority of the users of osCommerce do not have access to this area. I myself do not let any of my customers access to httpd.conf, if I did they could take down the particular server they are on. and that could potentially have an effect on a number of other customers..
I would like to know where you get the info on htaccess for shared servers, point me to that on apache.org and where it states you are better off without them..
In general, you should never use .htaccess files unless you don't have access to the main server configuration file. There is, for example, a prevailing misconception that user authentication should always be done in .htaccess files. This is simply not the case. You can put user authentication configurations in the main server configuration, and this is, in fact, the preferred way to do things.
This states unless you dont have access to the main server configuration files. I would venture to say 98% of the people here do not have access to those files..
This post has been edited by.
: 11 October 2004, 14:13..
Fair enough. This is exactly the kind of scenario that .htaccess was invented for. I did qualify my comment by saying that "...if you have full control of your server...".
Of course not - I wouldn't expect you to..
Here's a link to the first article I found on the Apache site. Search for the word 'avoid' in this page. It describes in much better detail than I did the issues involved :-.
Exactly. That's what I said..