[BoulderDash]

Hey all,
Do Permissions matter when putting up a website? Can't they all be set to Global Read/Write/Execute, since nobody can do anything through a browser anyway?

Can anyone point me to a good tutorial on the web as to what I should have them set to for a publicly-viewable website if Permissions do matter?

Thanks.

[Chris in Madison]

Permissions almost always matter. The problem is not so much with the inability of the browser to mess with some of the code that's on your server but with other applications' abilities to do so, such as FTP clients, telnet, remote shells, local network users, and malicious code included in things like viruses and such that could exploit an improperly protected folder or directory. Unless there is a really good reason to do so, web directories should have no more than "read" permissions if they are static HTML pages, or "read & execute" if they are CGI scripts or made with another scripting language.

Best regards,
Chris

[Raman]

Originally posted by BoulderDash:
<STRONG>Hey all,
Do Permissions matter when putting up a website? Can't they all be set to Global Read/Write/Execute, since nobody can do anything through a browser anyway?

Can anyone point me to a good tutorial on the web as to what I should have them set to for a publicly-viewable website if Permissions do matter?

Thanks.</STRONG>

What if I uploaded (write permissions) an executable that ran (execute permission) all the time and hoggedup the server's CPU? or deleted all your website files? or emailed me all your text files in hopes that you have passwords or credit card numbers in them?

In general, unless you have a specific need to, you should have all your files read only. If you want an object to read/write to the filesystem or database then create another user that is impersonated by the anonymous user. This way the anonymous user can't "accidentally" poke around your site if they got in and then mess things up.

You should spend a lot of time reading up on security.

[BoulderDash]

Hmm,
But - wouldn't you need access to the server in order to do all of that (upload, poke around, etc.)? If I never gave you an account to get into the server, how would you accomplish all of that malicious activity.

Let's say MacNN had Global Everything... it wouldn't do me any good to try and mess around since I can't get on their servers -no? I mean, isn't that the key - getting on the server? As long as I don't allow anyone to access the server, would Global Everything hurt?

In the end though, what you guys are saying is Global Read / Group Write / Owner Execute?

Thanks.

[derbs]

in a nutshell - permissions do not really matter when you just have a flat html site. Setting a flat-html file for the public to execute/write to would not achieve much because they wouldn't be able to do anything with it. For that to happen, as you say, you would need ftp access. Or be a very good hacker

However, if you need to run a CGI-executable, and the permissions are set wrong, it would result in a nice big error message =)

[dogzilla]

Boulder - are you running your own server or using someone else's?

If you're running your own server: I usually create a user and group for the server to run as (web:http) and chown *most* files in the served files directory to that (htdocs in the case of apache). Exceptions are things like .htaccess files. This gives me pretty fine-grained control.

Other people will probably have different approaches. However, I can say that after 4 years of running many different servers, I've never seen a successful hack from the web this way (although I have noted several thousand attempts in the log files over the years).

[BoulderDash]

Thanks Dog,
I am running my own server, so I suppose what you're saying is that if I do not give anyone access to the server I can set the files to Global Everything since you've never seen a successful web hack?

See ya...

[Raman]

Hahaha. Yeah, do that.. btw - where's your site?

[BoulderDash]

Raman,
You still haven't mentioned how it would be possible to do everything you mentioned before, if you don't have an account. Let's say Apple.com had Global Everything... how would you do anything with no account, just by hitting it with a web browser? I don't see how you could - you would need an account on the box in order to do anyting.

[Millennium]

Originally posted by BoulderDash:
<STRONG>Raman,
You still haven't mentioned how it would be possible to do everything you mentioned before, if you don't have an account. Let's say Apple.com had Global Everything... how would you do anything with no account, just by hitting it with a web browser? I don't see how you could - you would need an account on the box in order to do anyting.</STRONG>

Ah, but you do have an account on the box. It's whatever account the Webserver runs as. On OSX, this is the user "www" (who you don't see in the login box because you don't log in as this user normally).

Now, you want to know how a site like that can be hacked? Let's take a quick look, shall we? Let's say you're running a server at http://www.nowhere.com and you have a file called index.html with permissions 777. I have a file I want to replace index.html with, which I'll call evil-index.html on my side.

How can I hack this? I can't, with a standard Web browser. But I'm not going to use a Web browser. I'm going to use another program. Just to show off my 31337 h@x0r1nG $k1lLz, I'm going to show you how to do this with nothing but Telnet. Other programs for this purpose probably exist, though I don't know of any at just this moment.

Anyway, first I'm going to show you how to use Telnet to get some information about your server. This is just a proof-of-concept, that is, I'm just going to show you that you can use Telnet to carry out a proper HTTP session. Boldface stuff is that I type; normal type is the server's reply. Italics are just a description of what I'd type here.
----------
telnet www.nowhere.com 80
Trying [ip-address-of-server]...
Connected to www.nowhere.com.
Escape character is ^].
HEAD / HTTP/1.0

HTTP/1.1 200 OK
Date: Wed, 09 Jan 2002 05:24:00 GMT
Server: Apache/1.3.22 (Darwin) PHP/4.0.6
Last-Modified: Wed, 18 Jul 2001 23:44:21 GMT
ETag: "68120-5b0-3b561f55"
Accept-Ranges: bytes
Content-Length: 1456
Connection: close
Content-Type: text/html
Content-Language: en
----------
(note that blank line after HEAD / HTTP/1.0; I typed that, and it's important).

Look at the information I just got. Some of it's not that important. But note that I got the server name and version, the OS you're running, and even the PHP version I had installed. That's some pretty valuable information for a hacker. Looking at the Apache version, I can easily look to see if any security holes have been found in it, and then exploit away. PHP is similar in this regard. Plus, I can start researching Darwin security holes, for later on when I've cracked your server. I can't configure Apache to simply not send this header, but I can configure it to lie about its name and version (Apple doesn't set it up to do this, though). That closes up that little hole nicely. But I digress.

Now, let's take this one more step. I'm going to get a peek at your index.html file this time. Ready?
----------
telnet www.nowhere.com 80
Trying [ip-address-of-server]...
Connected to www.nowhere.com.
Escape character is ^].
[b]GET /index.html HTTP/1.0

the same information from the last example
Content-Language: en
Expires: Wed, 09 Jan 2002 05:35:02 GMT

source for the HTML page
----------
Note again the blank line that I had to put in. In any case, now we've seen that you can get Web pages with nothing but Telnet.

But guess what? I've shown you the GET command in HTTP. There's also a PUT command. Are you starting to get what I'm saying? Put a PUT command together, and aslong as I have the proper permissions, I can overwrite any file on your machine, or even create new files if I want. PUT commands tend to get long, and I've already made a long post, but I'm sure you can see where I am going.

So, are you convinced? If not, perhaps you'll change your tune when I tell you what else I can do with this very technique. It's not just for uploading pages and images, after all. If I wanted, I could put a program into your cgi-bin directory. Perhaps something outright malicious; using a CGI program I wrote, I could essentially grant myself local-like Terminal access, where I can start attacking you from the inside to try and get a better account. Or perhaps I'd use something more innocuous, like an innocent-looking but very insecure messageboard program (WWWBoard comes to mind), and get my access that way; it's harder, but you're not as likely to notice it. And that stuff, I could do with just a Webbrowser, if I made the script right. And they do exist; make no mistake about that.

Satisfied now? Or do I need to continue?

[EDIT: The code tag's syntax highlighting makes an absolute mess of URL's. I'll have to not use it, I guess...]

[ 01-09-2002: Message edited by: Millennium ]

[derbs]

interesting reading there Millenium.

However, i'm a bit confused about a couple of points.

Did you log into the server when it asked for a username/password, or did it return all the apache/etc details just by typing HEAD / HTTP/1.0?

Also, is it really that easy to PUT a document simply telnetting in without logging in and without exploiting a vulnerablilty?

[Millennium]

Did you log into the server when it asked for a username/password, or did it return all the apache/etc details just by typing HEAD / HTTP/1.0?

No logins, no passwords. Although you can configure Apache to require authentication for certain directories, it's an all-or-nothing thing: everyone will need a login/pass to get into that directory, whether they use Telnet, a browser, or otherwise.

Also, is it really that easy to PUT a document simply telnetting in without logging in and without exploiting a vulnerablilty?

OK, it's not quite that simple, but it's close. It's possible to configure Apache to deny all PUT requests in a given directory; if you don't expect to receive uploads there, this is pretty safe to do. However, POST requests can be made to do much the same thing, and this can cause problems; if you disable this, many forms will not work.

[Camelot]

Originally posted by derbs:
<STRONG>Did you log into the server when it asked for a username/password, or did it return all the apache/etc details just by typing HEAD / HTTP/1.0?
</STRONG>

By default, HTTP requests don't need a username or password (you don't enter a username or password at most sites, do you?)
As long as a file is world readable the web server will return it to a user who requests it, no questions asked.

You should understand that all a web browser really does at a network level is connect to the web server (usually on port 80) and send a GET command. At its simplest level, the server has no idea what application is connecting to it (IE, Netscape, or a user using telnet).

Technically, there's no difference between you entering http://www.apple.com/ in a web browser and you telnetting to port 80 on www.apple.com and typing "GET /". The only difference is that the web browser knows how to display the resulting page (telnet will just show you the HTML returned by the server)

(Yes, there are ways for a client to identify itself (how do you think MS makes most of microsoft.com inaccessible to non-IE browsers?), but they are not required for a basic request unless the webmaster has specifically configured his server that way.)

<STRONG>Also, is it really that easy to PUT a document simply telnetting in without logging in and without exploiting a vulnerablilty?</STRONG>

Again, if the file is world writable, the system doesn't care who changes it so there's no username or password requirement. As stated before, the format of a PUT command is a little trickier than a GET, but it's not beyond the realms of possibility, even for script kiddies.

[BoulderDash]

Wow!
You see - now that's what I call being part of a community. I just learned a ton! I create websites, but never dealt with administering them. Now that I have a Penguin Computing box that I can play around with on our network (available to the outside world since it's "colocated"), I have decided to learn a bit of this networking stuff - and this really helped.

When all is said and done, what should I set permissions to? In Apache, I have set all of my web files (HTML, PHP, JS, etc.) to be served from "htdocs" and any executables (Perl, etc.) to be run from "cgi-bin". Those two directories ("htdocs" and "cgi-bin") are at the same directory level (which I thought was good since that way cgi-bin's couldn't be accessed through a browser since they are nowhere in the "root" ("htdocs"). Does that tighten things up?

And does that mean then that anything other than Owner in "htdocs" should only be Read (744)?

And anything other than Owner in "cgi-bin" should only be Read and Execute (755)?

Thanks, thanks, thanks,
BoulderDash

[Raman]

So whats your website?

[ReggieX]

Hi Boulderdash

I set everything to 755 (Owner has all permissions, Group and Visitor have read and execute)
I've been doing Web stuff for a while, and those settings are usually the best. I've gone from static HTML to SQL/PHP driven sites, and 755 seems to create the least hassle.

More UNIX-y types may recommend other settings, but those are what I use. Hope this helps!

Reg

[dogzilla]

Originally posted by BoulderDash:
<STRONG>Thanks Dog,
I am running my own server, so I suppose what you're saying is that if I do not give anyone access to the server I can set the files to Global Everything since you've never seen a successful web hack?

See ya...</STRONG>

Sorry if I wasn't clear - I give ownership of the files and full access (rwx) to the web user. Others get read & execute access. So if my web user and group (which Apache runs as) is web:httpd, then I go to the htdocs directory and do the following:

chown -R web:httpd *
chmod -R 755 *

I've never seen a successful web hack *when using this method*. Note that this user has remote logins disabled - no telnet, no ftp, no ssh.