I came across a document which said "In order to use all these tools, you have to change the chmod of wp-content folder to 777".
I very rarely do this and it's usually unnecessary. It's analogous to unlocking all the doors so that your friend can use one of them. I normally prefer to unlock only the necessary door ("That's just perfectly normal paranoia" -- Slarty Bartfast). If you're being lazy and writing a doc you might just ask the user to 777 a directory since you probably don't want to write long notes like this one explaining the different types of doors and the conditions in which you should unlock different ones. 777 will always work, especially if the user installing the software doesn't have root. If you do have root, then you should just chown or chgrp to the user or group which needs to write to the directory. This is normally apache and this is what I recommend.
However, this doesn't mean problem solved and everything is secure. It means the back door is open and you could be at risk if the person you've asked to watch it for you is incompetent. Since WordPress is a popular and active project with a lot of developers I'm going to err on the side of trusting them and endorse letting apache write to said part of the file system. You should then put a noexec .htaccess in that directory so that if something bad is uploaded it can't be run.
Let me explain more about what I mean by not asking some incompetent person (or script) to watch the back door. Some web applications need to be able to write to the file system for them to be of use. E.g. WordPress probably wouldn't be too handy without this feature. By the bug:feature ratio law we will also open ourselves to plenty of exploits. It all depends on an arms race between developers and crackers. If you are installing some dead project like "Jim's PHP-weekend photo gallery" and he hasn't put too much work into thinking about possible exploits or updating his code you are putting the server at risk. Someone could drop in some code to use your box as a spam relay or they might even upload PHP shell and try to root the box. I've seen it happen.
For web servers where many users have shell accounts allowing them to make the call on whether a project is secure enough to be hosted with the apache write option is not a good idea. You basically need to support apache reads only. Your best bet if they want to do writes is to force it though a database like MySQL. This works well for text (the majority of cases) but is not a good idea for attachments. If a good open source project had a generalized attachment solution which focused on security and provided an API and then other projects adapted it, I think admins and users would be happier.
Wednesday, January 2, 2008
don't chmod 777
I came across a document which said "In order to use all these tools, you have to change the chmod of wp-content folder to 777".
I very rarely do this and it's usually unnecessary. It's analogous to unlocking all the doors so that your friend can use one of them. I normally prefer to unlock only the necessary door ("That's just perfectly normal paranoia" -- Slarty Bartfast). If you're being lazy and writing a doc you might just ask the user to 777 a directory since you probably don't want to write long notes like this one explaining the different types of doors and the conditions in which you should unlock different ones. 777 will always work, especially if the user installing the software doesn't have root. If you do have root, then you should just chown or chgrp to the user or group which needs to write to the directory. This is normally apache and this is what I recommend.
However, this doesn't mean problem solved and everything is secure. It means the back door is open and you could be at risk if the person you've asked to watch it for you is incompetent. Since WordPress is a popular and active project with a lot of developers I'm going to err on the side of trusting them and endorse letting apache write to said part of the file system. You should then put a noexec .htaccess in that directory so that if something bad is uploaded it can't be run.
Let me explain more about what I mean by not asking some incompetent person (or script) to watch the back door. Some web applications need to be able to write to the file system for them to be of use. E.g. WordPress probably wouldn't be too handy without this feature. By the bug:feature ratio law we will also open ourselves to plenty of exploits. It all depends on an arms race between developers and crackers. If you are installing some dead project like "Jim's PHP-weekend photo gallery" and he hasn't put too much work into thinking about possible exploits or updating his code you are putting the server at risk. Someone could drop in some code to use your box as a spam relay or they might even upload PHP shell and try to root the box. I've seen it happen.
For web servers where many users have shell accounts allowing them to make the call on whether a project is secure enough to be hosted with the apache write option is not a good idea. You basically need to support apache reads only. Your best bet if they want to do writes is to force it though a database like MySQL. This works well for text (the majority of cases) but is not a good idea for attachments. If a good open source project had a generalized attachment solution which focused on security and provided an API and then other projects adapted it, I think admins and users would be happier.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment