I have a slight confusion regarding HTTPOnly attribute in cookies. I am aware that its main use is for protection against XSS attacks. Let us assume there is web application which has set httponly enabled for the cookie. I used a interception proxy like Fiddler for this. But in all subsequent transactions the cookie is not accompanied with the httponly flag. is this a feature like set it once and the whole session is covered under httponly flag...or is this a implementation flaw. But again when monitored through a cookie manager addon,the properties show that httponly is enabled. My question is if its enabled why the cookie manager shows it enabled but not an interception proxy,is this the normal expected behaviour or a wrong implementation. Please help me understand.
HttpOnly is sent by the server in the Set-Cookie header to instruct the browser not to make the cookie available to javascript. The browser will still send it over http connections. The Set-Cookie header can contain all sorts of instructions for cookies, like when they expire, what domain they are for, whic path, whether they should only be sent over https(Secure flag) and HttpOnly. These are all instructions from the server to the browser, so there is no point in the browser sending them back to the server on each request.
Related
I was researching the purpose of CORS headers, and the accepted answer here: What is the issue CORS is trying to solve? says, that the reason for its existence is, to prevent cookies unintentionally being sent to external sites when making HTTP requests from JS (fetch or XMLHttpRequest).
Reading up on how cookies are handled based on the Set-Cookie documentation page, doesn't the SameSite=Strict cookie option obsolete CORS completely? It says:
means that the browser sends the cookie only for same-site requests,
that is, requests originating from the same site that set the cookie.
If a request originates from a different domain or scheme (even with
the same domain), no cookies with the SameSite=Strict attribute are
sent.
In summary both CORS headers and the SameSite=Strict option for the Set-Cookie header seem to solve the same problem. Why does both exist?
We have a site that uses first party and third party cookies. Security has pointed out that several of our cookies are not httponly and not secure. After looking the web.config file I see this:
<httpCookies httpOnlyCookies="true" requireSSL="true"/>
Hitting the site and using Google Dev Tools shows the cookies are still not marked as httpOnly or secure.
Shouldnt this setting force all first party cookies to be rendered as httpOnly and Secure? Or am I missing something? Any reason these cookies would not be httpOnly/secure? I also set this via IIS at the server level, but no change in the cookie's status.
I have a django app. That app has 2 main cookies that are returned from the server (csrftoken and sessionid). I set the SESSION_COOKIE_SECURE and CSRF_COOKIE_SECURE flags in my settings.py file to True, and if I examine the initial request to login to my app I see that both of those cookies have the "secure" flag set in the response from the server.
When I am examining cookies in my app, I notice there are "request cookies" and "response cookies". The "response cookies" are the ones that have their flags set. The request cookies do not.
My question: Is there some way to force "request cookies" to have their secure flag set? Is this even a security concern? My application traffic is over https, so all connections between the browser and the server will already be encrypted from that...
It doesn't really work that way ... The flags are only present in the Set-Cookie header (the response).
When the client (a browser) receives a Set-Cookie header, it will store the flags together with the cookie value, but only for its own usage (so that the browser itself can know when and where to send the cookie value if necessary).
The Cookie header (request) cannot contain flags; it is only a list of <cookie-name>=<cookie-value> pairs and when you (the server) receive them, you're not even guaranteed to have set them yourself.
That's because any application under the same domain name can set cookies for that said domain. For example, an application running on example.com/foo would be able to set a cookie for example.com/bar, or even for another.example.com.
However, excluding the possibility of really horrible browser bugs, you can be sure that if you set the "secure" flag for a cookie in your response, the receiving browser won't send it over a non-encrypted connection.
It's not really 100% guaranteed, but it's really the only option you have and the pretty much the whole web relies on browsers behaving properly, so you're not alone in that.
Sadly, that's just how cookies work. Read the official standard for them here if you're interested in learning more about them.
I am trying to mark the ASP session ID cookie as HttpOnly but can't seem to find a way to tell if it is working. The environment I am trying this in is as follows:
OS: Windows Server 2003
IIS: 6
ASP Version: ASP 3 (Classic ASP)
In order to mark the cookie as http only, I followed MS KB
As per our architect's suggestion, to test whether this works, a javascript document.cookie should not be able to read the ASPSESSIONID* cookie. My issue is that javascript:alert(document.cookie) still echoes the ASPSESSIONID* cookie, albeit it appears to be encrypted(?)
I also tried to do this via Response.AddHeader "Set-Cookie" but can't determine what value to give for this header to mark all the cookies OR AT LEAST the ASP Session ID cookie as HttpOnly.
Help!!!
Just came across this issue because of a "new" PCI compliance item. It's a bit clumsy but this seems to work:
<%
Dim AspSessionCookie
AspSessionCookie = Request.ServerVariables("HTTP_COOKIE")
If len(AspSessionCookie) > 0 Then
AspSessionCookie = "ASPSESSIONID" & Split(AspSessionCookie,"ASPSESSIONID")(1)
If InStr(1,AspSessionCookie,";") then
AspSessionCookie = Split(AspSessionCookie,";")(0)
End If
Response.AddHeader "Set-Cookie", AspSessionCookie & ";HttpOnly"
Else
Response.redirect(Request.ServerVariables("URL"))
End If
%>
You seem to be confused between SECURE and HTTPONLY
These are different. The MS KB article you refer to is for SECURE.
Setting a cookie SECURE will stop IIS/Browser sending the ASP Session ID over HTTP.
Setting a cookie HTTPONLY will stop script (javascript) from accessing the value in most browsers.
There is a very GOOD reason to set HTTPONLY on a sessionID cookie. It help prevent theft of the users sessionID cookie, which could lead to session hijacking. That is why major browsers have implemented it.
I don't think your architect is correct regarding accessing the cookie in javascript.
There is no reason to stop javascript running in your page from accessing the cookie any more than javascript accessing the rest of your data in the HTML.
The purpose of adding the secure qualifier to a cookie is to prevent it from being sent in an unsecure request.
Oridinarily cookies set when the client is connected using https will still be sent when requests are made to the same server using plain http. The marking a cookie with the secure qualifier when its Set indicates to the client that it should only be sent in subsequent requests if those requests are using https.
Hence to test your setting get yourself a copy of fiddler, with that running hit the server over https then in the same browser session hit the same location with just http. Fiddler should show the second request going to the server and there should not be an ASPSESSION cookie present.
Searching for possible ways to get cookie with httpOnly enabled, I cannot find any. But then again, how do browser addons like Firebug, Add 'N Edit Cookie, etc. can get the cookies? Can't an attacker do the same?
So my question is, is it really, really impossible to get cookie of httpOnly enabled requests, using javascript?
p/s: Yes I'm aware httpOnly doesn't stop XSS attacks. I'm also aware it's futile against sniffers. Let's just focus on javascript, sort of alert(document.cookie) type / pre httpOnly era.
how do browser addons like Firebug,
Add 'N Edit Cookie, etc. can get the
cookies?
They are browser extensions, and the browser has access to the cookies ; extensions have a higher level of privileges than you JS code.
is it really, really impossible to get
cookie of httpOnly enabled requests,
using javascript?
Provided you are using a browser (ie, a quite recent browser) that support httpOnly and doesn't have a security bug about it, it should be impossible -- that's the goal of httpOnly.
Quoting wikipedia :
When the browser receives such a
cookie, it is supposed to use it as
usual in the following HTTP exchanges,
but not to make it visible to
client-side scripts.
Firebug and other addons can do that because they are not running under security restrictions imposed to the JavaScripts of the web pages.