[Love Calm Quiet]

I originally learned my PHP/MySQL from Larry Ullman's Visual QuickStart vol. In it he strongly recommends going beyond the security of having your connect ( including user & pw info) in a .php file to:
Put CONNECT info in a separate, included file *outside your main directory folder*.

But he never explain how to ftp to such inaccessible directory. I use DreamWeaver to ftp (though not for much designing), and as "root" a folder as one sees is the SITE folder (where the root index.html / index.php file will be).

1) How does one even *access* a folder "above" that folder?
2) How much more security does that really offer? (Apache / Unix)
2a) How can his concern of what happens if "server goes down" apply? If it's "down" - might it start serving up raw code (have some settings damaged to permit that)?
3) Under what circumstances can a user not having the root password access any raw code in a .php file through a web browser?

Thanks! If you've got a link to low-geekishness-quotient info on such php/mysql issues, I'd like to grasp the basic concepts better!

[moodymonster]

I haven't done it but try http://cyberduck.ch/

I just tried making a new directory in the directory one up from my http files and it let me, I guess you'd refer to it via ../folder_name or similar.

[registered_user]

Your host may not give you access to the server above the web root, in which case, you'll have to store your connect info in a public directory.

Many a CPanel driven host gets you one level above web root, when you ftp in, there's a directory called "public_html" or "www" or something. Dreamhost lets you specify your own web root. The point is that it varies by the host.

So put your connect info into file.php and place that where you can. Should you gain access to a more private directory, you can then update your scripts to use the file in its new location.

It's not the end of the world if you store the file in a public directory, and it's generally safe to do so, but it's not a best practice because like you know, if there should be a simple server error of sorts, your database access could be exposed more easily than it could be in a private directory.

[SirCastor]

You asked if a user can read a raw PHP file through a browser. The answer is they can't. This is because it's always parsed by the time it gets to the user. An easy example, save this page right now. You'll be able to read through it, but there is no PHP in the code. It's all been parsed.

I think an easier solution than trying to get a directory outside your public dir (which, as has been mentioned, is hard with a provider sometimes.) is just to make a directory that is publicly forbidden. chmod 750 I think would do it. I use it a lot for files I need to write to a server, but I don't want anyone but the owner to see. If there's a server error, nothing is going to be working.

[Love Calm Quiet]

Thanks, SirCastor,
I like the sounds of a locked directory. But then, will it not be locked when I try to ftp? and not locked to the INCLUDE statement?

Also, "chmod 750" sounds like a line-command. Haven't done much of that (except a little in Terminal). Wouldn't know how to begin sending such commands to my hosting service's server. Where would I have to go to climb the learning curve for that?

(or can ftp via DW or cyberduck enable that?)

[moodymonster]

with cyberduck you just get info on the file/folder and check the boxes, dunno 'bout DW

[SirCastor]

Originally Posted by Love Calm Quiet

Thanks, SirCastor,
I like the sounds of a locked directory. But then, will it not be locked when I try to ftp? and not locked to the INCLUDE statement?

Also, "chmod 750" sounds like a line-command. Haven't done much of that (except a little in Terminal). Wouldn't know how to begin sending such commands to my hosting service's server. Where would I have to go to climb the learning curve for that?

(or can ftp via DW or cyberduck enable that?)

This is (one of) the brilliance(s) of Modern OS's, the permissions system I mean. In Unix, a directory or file has 3 permissions set for 3 users.

The permissions are Read, Write and Execute. The users are Owner, Group, and public.
So you set a directory to be R,W,X for The Owner and the WWW group (depending on the system, the group that is the web server: httpd will vary. On OS X, it's called www.)

that means that both the owner of the directory and the group are allowed to read that dir, write to it, and execute things in it. Now lets say you set the directory to have only write access for the 'public'. This means that the public user can write to it, but won't be able to see it, or execute files from it.

Make sense? So this is where it gets cool. You write into your PHP file to access the file and include it into your page. This is possible because the user accessing it (www) has read access, but if someone from the public group (ie: anyone accessing the site) tries to go into the directory they get an error 403: Forbidden.


Okay, now that I've bored you with the details, most any FTP program does this easily. Cyberduck is dang good too. It'll provide you with not only the permissions in plain english, but also the number code. When you're logged in, select the file or directory you want to lock, and get info on it. At the bottom of the info window there's a set of check boxes (as described above) Cyberduck will also show the numerical code of the permissions based on what's checked.

The quick of the numbers is:
Read - 4
Write - 2
Execute - 1

So if the user has all rights, he has 7. (4 + 2+ 1)
If a user has only read rights, he has 4 (4 + 0 + 0)
if a user has write and execute, he has 3(0 + 2 + 1)

here's an image of Cyberduck's info window. This particular window is actually a directory that I've given access so apache (and subsequently PHP) can write to, but cannot read. So it can place a file in there, but can't pull it back out. Note the list of the owner and the group. Of course the third, public is not listed. That never changes.



make sense?
Lemme know if you got lost anywhere in there.

PS. if you're interested, the commandline is really easy too.
Chmod --- somedirectory

chmod stands for Change Mode, the numbers are explained above, and then the directory.
You do have to have permission to do that already, but since it's your directory, that's expected.

[mania]

so the so called security experts say to put these in apache environmental variables - but dont let anyone use phpinfo()...

once again you probably dont have access to this on a shared host. the best bet is to not have anything important in the db - especially never store cc info. i have come up with a way to do it if you have to...

[Love Calm Quiet]

Excellent, SirCastor. I'll have to sit down w/CyberDuck and dabble some evening. Not having walked through the paces yet, that seems like a very thorough presentation of what would be rather arcane tidbits. (I always like to understand those foundational concepts.)

Mania... Yes, I hear to be sure NOT to have a phpinfo command store inside your site (just in case).

I *am* working toward e-commerce once I have a better feel for security issues, and that's the one time (CC#s) where I understand one *may* need to store secure info (for ease of repeat purchases). [Of course one could just receive and send off the CC info without storage... but way less convenient for user eventually.]
I'm wondering if steps are taken such as storing a pairing of userid# & CC# together in some more remote Table... or DB... something to make ONE table of info less useful. (& another DB with CC exp. date? etc?) Anybody know how the BIG boys do it. (Amazon coming to mind)

[Of course *some* of the ~supposedly~ big boys have done some awful careless things with CC info :/]

[Love Calm Quiet]

PS: mania...
VERY nicely done site at Bitcastle.

[SirCastor]

Originally Posted by Love Calm Quiet

Excellent, SirCastor. I'll have to sit down w/CyberDuck and dabble some evening. Not having walked through the paces yet, that seems like a very thorough presentation of what would be rather arcane tidbits. (I always like to understand those foundational concepts.)

Mania... Yes, I hear to be sure NOT to have a phpinfo command store inside your site (just in case).

I *am* working toward e-commerce once I have a better feel for security issues, and that's the one time (CC#s) where I understand one *may* need to store secure info (for ease of repeat purchases). [Of course one could just receive and send off the CC info without storage... but way less convenient for user eventually.]
I'm wondering if steps are taken such as storing a pairing of userid# & CC# together in some more remote Table... or DB... something to make ONE table of info less useful. (& another DB with CC exp. date? etc?) Anybody know how the BIG boys do it. (Amazon coming to mind)

[Of course *some* of the ~supposedly~ big boys have done some awful careless things with CC info :/]

I can tell you that the big boys don't use MySQL. MySQL is very flexible, and extremely scalable, but Amazon uses a different DB system. Not even Oracle. This isn't to suggest that mySQL isn't capable of handling the information. Just that Amazon (for instance is using something more high-end) I don't remember what it is, one of my professors mentioned it to us though.

I also doubt they use PHP. Likely they are utilizing their own parser. That way they control it, and only people within the company are familiar with it. That's what I would do, but as you mentioned, they haven't been managing their data perfectly either.

[Love Calm Quiet]

Yes, I've never seen a .php at the end of huge commercial sites. I hadn't thought about the advantage of using proprietary systems to give hackers more challenges - makes sense.

Of course, they also *physically* own, monitor, !guard! their own servers as a part of the whole process. (no hosting of them by DH, I'm sure ). With a third-party host I guess it'd make sense at least to have a dedicated server once an online business got hoppin.

Maybe Mania (who serves off his own machines if I'm reading his site right) would like to chime in about at what stage of development of a commercial venture one might want to jump to another level of hosting security...

[mania]

well, i was thinking about this (the repeat charge problem). normally you would just use ssl to connect to authorize.net or some such and be done with it (no storing cc). this happens all the time and authorizenet even gives you a php w/ curl script to do it. (curl is used to post and get a response all within one script).

for the repeat charge problem, one could obtain a 'random' encryption key from a completely different host/server that you have an account with (again with ssl/curl). then encrypt the cc# and throw away the key. the key is stored on the other host/server.

when you need to run it - a human logs in to the other server and authenticates to get the key and decrypt the card (all in one script so its never stored in a session or passed to another page - and all via ssl/curl). in the same script get a new key and reencrypt the cc# and throw it away again. the human would never even have to see the card#. the human is needed so the authentication to get the key is never stored (once per month). you could use a loop to do all the cards at once that need to run.

so keys and encrypted card numbers are never on the same database, server or even the same network. a cracker would have to break into two different systems to get keys and card numbers to decrypt. unfortunately if a cracker breaks into your billing site he might just phish for new card numbers and not worry about decrypting existing card numbers.

nothing is perfect but this is probably reasonably secure (moreso than handing your card to a waiter to pay your bill). so who wants to sign up for random encryption key service?

[mania]

Originally Posted by Love Calm Quiet

PS: mania...
VERY nicely done site at Bitcastle.

many thanks for your kind words.

[SirCastor]

I like your mode of thinking mania. It's a little over the top though (of course, there's no such thing as too good security.) Kind of a cool idea...