9 replies to this topic

[piskie]

I am using a Cookie to grant access to CMS after logging in.
The CMS is using SSL and therefore https.
My question is whether the HTTPonly switch will make any difference.

Am I setting it right:

setcookie(CookieName, 'Yes', time()+3600, '', "domain.co.uk", true, true);

This succesfully sets the Secure Flag, but I am not sure about the HTTPonly bit.

My questions are:
Is the HTTPonly element valid when using https ??
Am I setting it correctly ??
Is this method of Logged in tracking Secure enough for the CMS on a Non Trading site ??

[Michael Martinez]

I think you have to choose one or the other. HTTPOnly tells the browser to ONLY use HTTP and not HTTPS.

[chrishirst]

SSL (HTTPS) only encrypts the communications between client and server.

The httponly flag simply means that the cookie cannot be read or written to by javascript running in the browser context.

The "secure" flag means that the cookie will only be set in a secure communication environment (https)

[piskie]

Thanks Chris, I already got that much more or less.
I am running https in the CMS folders.
The Secure flag I am OK with and it is running as set.

The bit that I am particularly vague on is the HTTPonly part.
I know it will prevent it being exploited by JS, but I am not sure whether HTTPonly is appropriate when already running https.
Also, have I set HTTPonly correctly with my example and can I test if it is set correctly.

setcookie(CookieName, 'Yes', time()+3600, '', "domain.co.uk", true, true);

My other uncertainty was whether this is a secure enough way to track a Logged in Visitor to a CMS directory after User and Password authentication.
There are no transactions, just content presentation by multiple clients using their unique logins.

[chrishirst]

HTTPOnly refers to the method used to access the cookie, javascript runs as a local request NOT as a request to the server, in this context HTTP & HTTPS use the same method. The 'S' simply means that the datastream will be encrypted using a 'key' that was 'agreed on' between the client and server in the 'handshaking'

javascript can only run in a browser context on the SAME parent domain as it is loaded from, so you really may only block your OWN javascript unless your site has been subject to a js code injection attack, (cross site scripting XSS) in which case you should "shut the door" rather than simply "hanging a blind" over the hole, and even then, the rogue javascript should NOT have access to cookies set by the parent domain regardless of the HTTPOnly state.

[piskie]

Thanks Chris, that clears a few things up for me.
I don't have any issues currently because I am still about a week away from launch.

As there will be (hopefully) in excess of 100 Clients with Logged in access to their own CMS directory, I am just trying to shut the doors in advance and make it less likely that a breech will happen.

So in essence, the Cookie that I am setting once a Client has Logged in under https, is going to be reasonably secure Yes ??

setcookie(CookieName, 'Yes', time()+3600, '', "domain.co.uk", true, true);

Edited by piskie, 21 April 2012 - 08:48 AM.

[chrishirst]

Sure, and of course the usual caveats apply,

Don't store plain text passwords in cookies.
Use a "salt" + user provided password in the database.


And if the information warrants it you could encrypt the username/identifier in the cookie then set session variables once the credentials have been accepted.



e

[piskie]

Thanks Chris, don't worry, the password doesn't go out with the Cookie. Authentication is via serverside database lookup.
However the Cookie name does incorporate a Client specific element.
The Cookie gets set and all pages within each clients own CMS directory checks for the Client specific Cookie being set and if it isn't set, it redirects to the Login Page.

As I said, this site has no Transactions and handles no payments, it is for advertising only, so the only motive for breaking in is for mischief.
Although that is no guarantee that Hackers won't come calling, it makes it less likely and less catastrophic if they do.

Edited by piskie, 21 April 2012 - 06:42 PM.

[chrishirst]

To get access to cookies in the first place, hijackers have to be physically at the computer that the cookies are stored on or have access to the machine disk drive in some other way.

There really is a lot of nonesense about cookies that gets bandied about by those with a vested interest in making potential customers paranoid about "security" and therefore buy their "security product"

Hellfire, many people think "computer security" means putting your passwords on a sticky label and "hiding" them on the back of the keyboard.

If hackers/crackers want to break in to your website, you can be assured that "cookie spoofing" will probably be the very LAST thing they will be looking to use

[piskie]

If hackers/crackers want to break in to your website, you can be assured that "cookie spoofing" will probably be the very LAST thing they will be looking to use

Well that's me well and truly reassured.
Thanks for all your help on this Chris, much appreciated.

Edited by piskie, 22 April 2012 - 07:09 PM.