In this example the Visitor cookie was set on the Unvalidated Redirects page. This
particular cookie has no restrictions other than to this web site and session. A cookie
like this should never be used for holding session information, since it can potentially
be modified through Javascript Cross Site Scripting (XSS), related attacks. To see
how this is possible click on the button above to modify the value. You may also wish
to review this in the debug settings of you web browser, and potentially review what is
happening behind the scenes using a Web Proxy like ZAP. ZAP will help you see
how the small web application here is seting the cookies in your browser in HTTP
Responses using 'Set-Cookie: ' HTTP headers, and also how your browser is
forwarding the Cookies using the HTTP Request 'Cookie: ' HTTP header.
Take a peek at the guidance from the Open Web Application Security Project (OWASP):
Cookies have some fairly interesting uses on the web, and if you are using them to
confer session information it is important that you consider properly making use of
all your options:
Expire: ensures the cookie expires after a time equal to their associated risk
Path: specify a URI path where the cookie will apply
Domain: specify which website the cookie applies to
Secure Flag: specify that HTTPS must be used before transmitting
Http Only Flag: prevent client-side Javascript access to the cookie
In 2003 the HTTP TRACE method was conceived as another method to potentially divulge session cookie details. We have placed the code to attempt this here, but most common
Javascript clients should return an error and not execute this. If your browser does
return real data, you should find a new one quickly:
You can compare this response vs. the data available to GET:
and OPTIONS requests:
None of the data presented here should include cookie info. Given that the Cookie
header is just one of the many HTTP headers sent/received in web requests you
should now realize just how important it is, and how Javascript aims to prevent
any disclosure of the HTTP Cookie header information. This should start to get
you thinking about what happens to other custom header information which you may
wish to send receive to/from a server, whether it is truly hidden, and what you
should consider when creating custom headers etc. For instance in all of the
above actions you should see a INSECURE_CUSTOM_SERVER_HEADER
sent in all responses from the server and if you are using a Web proxy you can
see a INSECURE_CUSTOM_CLIENT_HEADER is being transmitted in all
client AJAX requests. In typical HTTP browser actions the Cookie header is the
only HTTP header that is not accessible to Javascript, so placing other details
in HTTP headers traffic will not ensure the data is securely handled by
in-browser Javascript in any way.
We have noticed that some mobile web browsers do not provide for the same
Javascript Cookie interactions as regular browsers. Specifically you will notice
that iOS allows you to set duplicate cookies for 'Secure' and 'HttpOnly' cookies,
so while you cannot access the server supplied values in Javascript, you can
you can somehow create other cookies with the same name that are accessible.
This will no doubt cause confusion for those working with Cookies in
mobile-based web applications etc.