PHP: Where to Securely Save Cookies

Legacy Dynamo
1

My websites are hosted on ServerLogistics (XFERNET, on a shared Apache server). I save and run my PHP scripts from there. The directory structure is as follows:

/home/XXX/domains/mydomain.com/public_html/

All my website files are inside /public_html/ .

I want to access another server and then save its cookies via cURL in my PHP scripts. I have accomplished that by creating a folder inside /public_html/ and giving it 777 permissions, but that would not be safe as anyone who found out that address could read/write to it.

So would it be secure for me to create a folder with 777 permissions inside /home/XXX/? Since that level of the directory hierarchy is above /public_html/ no one should be able to access it, correct?

Note that /home/XXX/ is the root level of what I can access on my web server via FTP. Within /XXX/ I see folders named etc, var, usr, sbin, lib64, domains, and so on.

Thanks.

dynamo mailing list
email@hidden
Update your subscriptions at:

2

On 23 Jul 2015, at 06:57, JDW wrote:

My websites are hosted on ServerLogistics (XFERNET, on a shared Apache server). I save and run my PHP scripts from there. The directory structure is as follows:

/home/XXX/domains/mydomain.com/public_html/

All my website files are inside /public_html/ .

I want to access another server and then save its cookies via cURL in my PHP scripts. I have accomplished that by creating a folder inside /public_html/ and giving it 777 permissions, but that would not be safe as anyone who found out that address could read/write to it.

So would it be secure for me to create a folder with 777 permissions inside /home/XXX/? Since that level of the directory hierarchy is above /public_html/ no one should be able to access it, correct?

Note that /home/XXX/ is the root level of what I can access on my web server via FTP. Within /XXX/ I see folders named etc, var, usr, sbin, lib64, domains, and so on.

The problem is that the webserver will run as some other user. On shared servers that user won’t be you (the user you ftp as). If the webserver user can write to the cookie file, so can anyone else who is logged into the server unless the server machine is well set up - and you can’t be sure of that.

Set up the cookie directory as 777 and get the webserver to write to it. The written file will be created by the webserver and so owned by it. You will then know the username and group that the webserver runs as. I you don’t share a group with the server you’re stuck. If you do, set up the owner and group of the cookie directory as owned by the webserver with a group you are in and mode 770. (You may need ISP help to do this). Other people sharing the server will then only be able get into that directory by writing code that will be run by the webserver. In pure permissions terms it should just work the other way round (owner=you; group=yours; mode=770), but as you’re having problems there must be other checking going on.

As to where to put it, above or next to public_html is probably better as only those you share the server with could possibly see it. It should be safe within public_html as long as it doesn’t have an extension that says the server should serve it.

David - retired Unix sys-admin

dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

3

Thank you, David.

By the way, the “XXX” in the path mentioned in my opening post is where the name of my user account goes. Meaning:

/home/XXX/domains/mydomain.com/public_html/

So that implies that other users who access their web space on the same shared server via FTP would see something like this:

/home/YYY/domains/mydomain.com/public_html/

/home/ZZZ/domains/mydomain.com/public_html/

and so on.

So wouldn’t that imply that my shared host is “setup right” in terms of security?

By the way, the following directory on my shared web host has 777 permissions (not created by me):

/home/XXX/domains/tmp/

I can use PHP to write cookie and header files into /tmp/, but when I use my FTP client (Transmit), despite the 777 permissions, I cannot delete files from it. The only way I can delete the files from /tmp/ is if I use “unlink(‘filename’)” in a PHP script. I cannot change the permissions on /tmp/ with Transmit either. But I can create a new folder in the /XXX/ directory and use Transmit to change permissions to whatever I want.

By the way, when I Get Info on a folder on my shared server via Transmit, it shows me Owner and Group info, but both show “ftp” rather than the true Owner and Group.

dynamo mailing list
email@hidden
Update your subscriptions at:

4

This is impossible to say from our perspective out here. My personal opinion is that your server is set up correctly for a shared server, and I have a lot of trust in the guy who runs Server Logistics – I’ve corresponded with him since the very early days of the Mac OS X Server mailing list, and he has always struck me as very bright and careful. That said, when it’s a shared server, it is possible that every other user is accessing the Web server at the same level of privilege as you.

The Apache server starts as root, and then calves off N number of workers, each of which run as a very unprivileged user, only able to see the site directory and nothing else. PHP throws another angle of configuration into the mix, as it can be run as a CGI (from the root-level command-line PHP process) or an in-band Apache extension, which inherits the user level of the current Apache worker process.

There is a way to partition a server so that everyone gets their own (virtual) Web server process, so that my worker processes can only see and act on my corner of the Web server space, not yours. But this is not the usual way these things are set up, so you can’t just look at the server and know one way or another. Aaron could tell you directly whether he has “chroot jailed” the individual shared account web processes or not.

Walter

On Jul 23, 2015, at 3:05 AM, JDW email@hidden wrote:

So wouldn’t that imply that my shared host is “setup right” in terms of security?

dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

5

On 23 Jul 2015, at 08:05, JDW wrote:

Thank you, David.

By the way, the “XXX” in the path mentioned in my opening post is where the name of my user account goes. Meaning:

/home/XXX/domains/mydomain.com/public_html/

So that implies that other users who access their web space on the same shared server via FTP would see something like this:

/home/YYY/domains/mydomain.com/public_html/

/home/ZZZ/domains/mydomain.com/public_html/

For their own areas, yes.

and so on.

So wouldn’t that imply that my shared host is “setup right” in terms of security?

As mentioned by Walter, it depends on whether users are limited to seeing only inside their own tree (chroot). From the fact that you can see the /home/YYY/domains part I would guess not, unless that is artificially stuffed back into the listing as a replacement string for the chrooted leading ‘/’. Your, and all other users, should see the top of their area (mydomain.com) as the root of their tree. That is, if you refer to ‘/’ you are really referring to /home/YYY/domains/mydomain.com but the upper part is invisible and inaccessible. The webserver however will not be running as you and therefore will be able to see the entire tree.

By the way, the following directory on my shared web host has 777 permissions (not created by me):

/home/XXX/domains/tmp/

I can use PHP to write cookie and header files into /tmp/, but when I use my FTP client (Transmit), despite the 777 permissions, I cannot delete files from it. The only way I can delete the files from /tmp/ is if I use “unlink(‘filename’)” in a PHP script. I cannot change the permissions on /tmp/ with Transmit either. But I can create a new folder in the /XXX/ directory and use Transmit to change permissions to whatever I want.

By the way, when I Get Info on a folder on my shared server via Transmit, it shows me Owner and Group info, but both show “ftp” rather than the true Owner and Group.

The owner and group that Transmit shows toy will be correct unless they use a modified ftp server that lies. But ‘ftp’ is only a name corresponding to a numeric ID, and there can be more that one name to an ID - the first returned on a lookup being the one displayed. (Multiple names for an ID is often discouraged, but only to avoid human confusion. Some database based name ↔ ID schemes my prevent it, but that’s contrary to Unix). There’s no technical reason why the webserver shouldn’t run as a user or group that gets called ‘ftp’.

David

dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

6

Walter, I received a reply from SL. To summarize what I was told…

[code]
It’s possible to setup Apache to run separate processes under
different user ID’s to enhance security, but our servers are not
configured in that manner now because doing so adds a level of
complexity and possible performance problems in a shared
environment. We are using a standard Unix permissions scheme to
protect user content. It offers some protection, but a crafty
user could probably find ways around it. We therefore recommend
that customers requiring enhanced security not use a shared
environment and instead go with a cloud or dedicated server to
ensure that they will be the only user on that system. But a new
folder created in /tmp/ with a long obfuscated name and 777
permissions might be reasonably secure against folder name guessing.

[code]

Which means that any cookies or headers I save in home/XXX/tmp/ would be invisible to other SL users if they access their webspace via FTP client, however if they used PHP or other means, it is possible they could guess names of hidden folders or files to access such content. But since no plain text passwords are saved in the cookie or header files that would be temporarily saved, this should not be a major issue, I wouldn’t think. Would you agree?

dynamo mailing list
email@hidden
Update your subscriptions at:

7

A hundred years ago, when I ran the Softpress site (hosted in Florida on a Mac OS X server) we were hacked because another user had set a folder to 777 and a cracker exploited it and uploaded a very compact Perl script that simply recursed through the entire server listing every directory and modifying every file. Because it was a standard Unix permissions server, this was not even a difficult thing to pull off. The names of the folders had no bearing in the matter. Every page in the Softpress site was defaced by that script, and our host put up a new server for us, we uploaded everything from scratch, and they burned the old one to the ground, because there was no other way to be sure that it wouldn’t happen again.

.Walter

On Jul 30, 2015, at 8:59 PM, JDW email@hidden wrote:

Walter, I received a reply from SL. To summarize what I was told…

[code]
It’s possible to setup Apache to run separate processes under
different user ID’s to enhance security, but our servers are not
configured in that manner now because doing so adds a level of
complexity and possible performance problems in a shared
environment. We are using a standard Unix permissions scheme to
protect user content. It offers some protection, but a crafty
user could probably find ways around it. We therefore recommend
that customers requiring enhanced security not use a shared
environment and instead go with a cloud or dedicated server to
ensure that they will be the only user on that system. But a new
folder created in /tmp/ with a long obfuscated name and 777
permissions might be reasonably secure against folder name guessing.

[code]

Which means that any cookies or headers I save in home/XXX/tmp/ would be invisible to other SL users if they access their webspace via FTP client, however if they used PHP or other means, it is possible they could guess names of hidden folders or files to access such content. But since no plain text passwords are saved in the cookie or header files that would be temporarily saved, this should not be a major issue, I wouldn’t think. Would you agree?

dynamo mailing list
email@hidden
Update your subscriptions at:
Information for existing FreewayTalk / Groups.io users - Site Feedback - Softpress Talk

dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

8

{ Grunt }

Well, in that case I wouldn’t want to be the guy responsible for the 777 security hole in our shared server.

Not that any of this matters right now. I’m still dead in the water on achieving my primary aim…

{ sigh }

dynamo mailing list
email@hidden
Update your subscriptions at:

9

On 31 Jul 2015, at 02:57, Walter Lee Davis wrote:

A hundred years ago, when I ran the Softpress site (hosted in Florida on a Mac OS X server) we were hacked because another user had set a folder to 777 and a cracker exploited it and uploaded a very compact Perl script that simply recursed through the entire server listing every directory and modifying every file. Because it was a standard Unix permissions server, this was not even a difficult thing to pull off. The names of the folders had no bearing in the matter. Every page in the Softpress site was defaced by that script, and our host put up a new server for us, we uploaded everything from scratch, and they burned the old one to the ground, because there was no other way to be sure that it wouldn’t happen again.

.Walter

There must have been more going on than that. It would require root access or all clients to share a uid. It’s quite normal for users to have 777 directories in their trees without risk except to vulnerable stuff below that 777 directory. Only files that were writable by the webserver as group or world could be changed.

/tmp should be 777 and under pure Unix with a basic Unix filesystem any user should be able to add or delete anything directly in it, but if the filesystem allows ACLs (Access Control Lists) then that can be changed.

James’s /home/XXX/domains/tmp/ is a local addition that the admin has decided to add, but it too may have an ACL.

A solution, using either tmp directory (or some directory you create yourself) is to keep your files in a directory (say) tmp/mydata owned by you with a group of the webserver group and a mode of 730. That will allow you full r/w, the webserver the ability to write to it (add files to it), enter it, but not read it (required for listing). That way the webserver can access any files within tmp/mydata provided it knows the name, but cannot see what names are present.

By careful use of groups and directory hierarchies with modes you can create some quite complex protections. Certainly sufficient for that most vulnerable system - the college one with CLI access to students.

David

dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

10

Thank you for the tips, David.

In the case of my server (ServerLogistics shared server), /tmp/ is indeed 777. And I can use an FTP client to create a new folder within it and assign any permissions I like to my new folder. But when I use 730 permissions on my folder inside /tmp/ and then try to save cookies into that folder via PHP, nothing is saved. But when I change permissions on my folder to 777, then PHP can save the cookies in my folder.

By the way, if I save cookies directly into /tmp/ I cannot delete or move them with an FTP client. I can only do those manipulations with PHP. But cookies saved by PHP inside my folder ( /tmp/myfolder/ ) can be deleted easily with an FTP client.

James Wages

dynamo mailing list
email@hidden
Update your subscriptions at:

11

On 31 Jul 2015, at 08:57, JDW wrote:

Thank you for the tips, David.

In the case of my server (ServerLogistics shared server), /tmp/ is indeed 777. And I can use an FTP client to create a new folder within it and assign any permissions I like to my new folder. But when I use 730 permissions on my folder inside /tmp/ and then try to save cookies into that folder via PHP, nothing is saved. But when I change permissions on my folder to 777, then PHP can save the cookies in my folder.

By the way, if I save cookies directly into /tmp/ I cannot delete or move them with an FTP client. I can only do those manipulations with PHP. But cookies saved by PHP inside my folder ( /tmp/myfolder/ ) can be deleted easily with an FTP client.

James Wages

And the group of /tmp/myfolder is the same as the group of the file that is created by PHP (when /tmp/myfolder is 777)?

David

dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

12

Yes. At least, that is what my FTP client Transmit tells me when I GetInfo on /tmp/ & /tmp/myfolder/ & /tmp/myfolder/cookie. Owner and Group at the same for all. But in an earlier post you said that could be a fake Owner/Group name if my web host (ServerLogistics) uses a “modified ftp server that lies.” If it lies, there would be no way for me to confirm the real names, right?

I also see that the cookie saved into /myfolder by PHP has 644 permissions.

James

dynamo mailing list
email@hidden
Update your subscriptions at:

13

On 31 Jul 2015, at 09:14, JDW wrote:

Yes. At least, that is what my FTP client Transmit tells me when I GetInfo on /tmp/ & /tmp/myfolder/ & /tmp/myfolder/cookie. Owner and Group at the same for all. But in an earlier post you said that could be a fake Owner/Group name if my web host (ServerLogistics) uses a “modified ftp server that lies.” If it lies, there would be no way for me to confirm the real names, right?

I also see that the cookie saved into /myfolder by PHP has 644 permissions.

James

Something odd is going on. I think you need to ask ServerLogistics why. It’s not normal behaviour. Give them the full details you’ve given in previous emails and tell them what you want to do and why.

David

dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

14

Here is what SL told me, David:

The 777 vs 730 permissions issues stem from the fact that you are
probably creating the folder via SSH or FTP using your system
username. The folder is then owned by your UID and your GID. The
apache server runs as the user and group apache, and therefore 730
permissions would not provide write access for the apache user.
You would need to change group ownership to the apache group
and provide write permissions for group on that folder.

The 644 permissions are based on the standard umask, which is the
unix way of defining what the default permissions would be of a file
created by a specific user.

The FTP user that you see is due to the FTP server model if privilege
separation. The files would be owned by your actual user ID, but the
FTP server displays them as "ftp".

Does that make sense to you?

James

dynamo mailing list
email@hidden
Update your subscriptions at:

15

On 4 Aug 2015, at 00:53, JDW wrote:

Here is what SL told me, David:

The 777 vs 730 permissions issues stem from the fact that you are
> probably creating the folder via SSH or FTP using your system
> username. The folder is then owned by your UID and your GID. The
> apache server runs as the user and group apache, and therefore 730
> permissions would not provide write access for the apache user.
> You would need to change group ownership to the apache group
> and provide write permissions for group on that folder.
> 
> The 644 permissions are based on the standard umask, which is the
> unix way of defining what the default permissions would be of a file
> created by a specific user.
> 
> The FTP user that you see is due to the FTP server model if privilege
> separation. The files would be owned by your actual user ID, but the
> FTP server displays them as "ftp".

Does that make sense to you?

James

They’re using ‘security by obscurity’ which isn’t very helpful. The last paragraph shows that they are using an ftp server that lies. The second paragraph, while true, is irrelevant.

“FTP server model if privilege separation”. It is doing no “privilege separation” at all - other than what’s normal. It’s merely hiding what’s happening and making the problem more difficult for you to solve.

The first paragraph does tell you something useful. You do need to change the group of the 730 directory to ‘apache’. You may or may not be able to do this yourself. It depends on your ftp client, the ftp server, and how they interact.

If you were to use the Terminal ftp command (which doesn’t suffer from some GUI designer not implementing all the options), ‘help’ would list over 100 sub-commands (many of which are synonyms - for similarity with the various local command line commands on the various OSs that implement ftp). But many require co-operation from the server, and not all servers implement or allow all of the sub-commands. So you can only use some of the help-listed sub-commands. ‘chgrp’ isn’t listed as a sub-command, but with some servers it can be done.

As this is all hidden from you, unless you can di it yourself I would now suggest that you ask SL to change the group of your mode 730 directory for you. I would ask them to change the group ownership of your directory such that the web server can read and write its contents. (Ask for the result you want rather than ask them to perform certain actions. Then they can’t ‘misunderstand’ you). Tell them that your ftp client doesn’t give you an option to do it yourself.

David

dynamo mailing list
email@hidden
Update your subscriptions at:
https://freewaytalk.softpress.com/person/options

16

David,

Thank you for your detailed reply.

My OS X FTP client, Transmit, offers the ability to alter the Owner and Group, along with Permissions. But when I try to change the Group to Apache (/tmp/myfolder), I get the following error:

Could not change owner of “myfolder”.
Server said: ‘SITE CHOWN’ not understood

So I guess that means I have not been given sufficient permission to alter the Group.

I will therefore follow your advice and ask them to alter the Group to Apache and permissions to 730 on “myfolder”.

Many thanks for your excellent advice.

dynamo mailing list
email@hidden
Update your subscriptions at:

17

David,

SL replied to tell me that:

The issue you were running into is that you cannot change group
 ownership to a group that you are not a member of.

Using my FTP client Transmit, I verified permissions are set to 730. Transmit still shows me that both Owner and Group are “ftp”, but I verified that I can now use PHP to write cookies into that folder, giving evidence that SL did indeed change Group to “apache”.

Anyway, many thanks for your kind help and support. It is greatly appreciated. It’s also been a learning experience for me.

James

dynamo mailing list
email@hidden
Update your subscriptions at: