Forum Moderators: coopster
1. What is issue with this if cookies are available in javascript?
2. Can attacker login and access to security pages if he gets cookies from javascript?
3. What does it mean ,,HTTP ONLY'' COOKIES?
I have seen enough data stored in a cookie to get you logged in so it could be what they are referring to. Not to store data in a cookie.
Marks the cookie as accessible only through the HTTP protocol. This means that the cookie won't be accessible by scripting languages, such as JavaScript. This setting can effectively help to reduce identity theft through XSS attacks (although it is not supported by all browsers).
I have not taken the time to dig around the Mozilla developer docs yet but I'm fairly certain if you dig around in their security stuff and changelogs you can find something that pertains to cookies and XSS thwarting-attempts.
And if you do, please post a link to the authoritative browser documentation as it would be quite helpful to future readers, myself included.
I don't think that matters a whick, it's just a session cookie, it has a session id
oooooo
allowing them access to the data is the real problem if they hijack the session cookie
sounds like a bandaid on the wrong cut, smells like magic quotes
[owasp.org...]
According to Michael Howard, Senior Security Program Manager in the Secure Windows Initiative group at Microsoft, the majority of XSS attacks target theft of session cookies. A server could help mitigate this issue by setting the HTTPOnly flag on a cookie it creates, indicating the cookie should not be accessible on the client.If a browser that supports HTTPOnly detects a cookie containing the HTTPOnly flag, and client side script code attempts to read the cookie, the browser returns an empty string as the result. This causes the attack to fail by preventing the malicious (usually XSS) code from sending the data to an attacker's website.
Yes, seemingly another bandaid but if there is any way we can help helpless users I guess we use the techniques provided :)
As a result, even if a cross-site scripting (XSS) flaw exists, and a user accidentally accesses a link that exploits this flaw, the browser (primarily Internet Explorer) will not reveal the cookie to a third party.
>> the majority of XSS attacks target theft of session cookies
but of that great % how often does it work?
>> the browser (primarily Internet Explorer) will not reveal the cookie to a third party.
I have so many issues with this line
>> Secure Windows Initiative group at Microsoft
ok was it only me that laughed at that?
ah well, if it helps a bit maybe it is better than nothing
>>better than nothing
Perhaps. But I'm with you, web developers should be developing sites so that they are immune to cross-site scripting. I've been doing so since long before the httponly method came along and will continue to do so.
Basically if you use this httponly argument the server-side language will send out additional information via the response header in the cookie. So if I send out this PHP code where the last argument, 1, is boolean TRUE for httponly ...
$name = 'mycookie';
setcookie("cname", $name, time()+36000, '', '', 0, 1);
Set-Cookie: cname=mycookie; expires=Fri, 12-Jun-2009 05:04:25 GMT; httponly
... which indicates to browsers that support this feature that the cookie cannot be read using JavaScript. And if you attempt to alert(document.cookie) with a supported browser you are not going to see the data. There are some issues brought up in regards to XMLHttpRequests though so you really can't count on this being your end-all solution to XSS. You have to practice the basics. Many sites tell you how to do that and have been preaching it long before this "new" cookie method came to existence, including MS [msdn.microsoft.com]!
