Cookie Structure
(domain) The website domain that created and that can read the variable.
(flag) A TRUE/FALSE value indicating whether all machines within a given domain can access the variable.
(path) The path attribute supplies a URL range for which the cookie is valid. If path is set to /reference, the cookie will be sent for URLs in /reference as well as sub-directories such as/reference/web protocols. A pathname of "/" indicates that the cookie will be used for all URLs at the site from which the cookie originated.
(secure) A TRUE/FALSE value indicating if an SSL connection with the domain is needed to access the variable.
(expiration) The time that the variable will expire on. Omitting the expiration date signals to the browser to store the cookie only in memory; it will be erased when the browser is closed.
(name) The name of the variable.
The limit on the size of each cookie (name and value combined) is 4 kb. A maximum of 20 cookies per server or domain is allowed.
Cookies are the preferred method to maintain state in HTTP protocol. They are however also used as a convenient mechanism to store user preferences and other data including session tokens. Both persistent and non-persistent cookies, secure or insecure can be modified by the client and sent to the server with URL requests. Therefore any attacker can modify cookie content to his advantage. There is a popular misconception that non-persistent cookies cannot be modified but this is not true; tools like Winhex are able to do the job. SSL also only protects the cookie in transit.
The extent of cookie manipulation depends on what the cookie is used for but usually ranges from session tokens to arrays that make authorization decisions.
Cookie Example
Cookie: lang=en-us; ADMIN=no; y=1; time=05:30GMT;
hacker can simply modify the cookie to;
Cookie: lang=en-us; ADMIN=yes; y=1; time=10:30GMT;
Cookies can be set using two main methods, HTTP headers and JavaScript. JavaScript is becoming a popular way to set and read cookies as some proxies will filter cookies set as part of an HTTP response header. Cookies enable a server and browser to pass information among themselves between sessions. Remembering HTTP is stateless, this may simply be between requests for documents in a same session or even when a user requests an image embedded in a page. It is rather like a server stamping a client and saying show this to me next time you come in. Cookies cannot be shared (read or written) across DNS domains. In correct client operation Domain A can't read Domain B's cookies, but there have been much vulnerability in popular web clients which have allowed exactly this. Under HTTP the server responds to a request with an extra header. This header tells the client to add this information to the client's cookies file or store the information in RAM. After this, all requests to that URL from the browser will include the cookie information as an extra header in the request.
Persistent cookies are stored in a text file (cookies.txt under Netscape and multiple *.txt files for Internet Explorer) on the client and are valid for as long as the expiry date is set for (see below). Non-Persistent cookies are stored in RAM on the client and are destroyed when the browser is closed or the cookie is explicitly killed by a log-off script. Secure cookies can only be sent over HTTPS (SSL). Non-Secure cookies can be sent over HTTPS or regular HTTP. The title of secure is somewhat misleading. It only provides transport security. Any data sent to the client should be considered under the total control of the end user, regardless of the transport mechanism in use.
(flag) A TRUE/FALSE value indicating whether all machines within a given domain can access the variable.
(path) The path attribute supplies a URL range for which the cookie is valid. If path is set to /reference, the cookie will be sent for URLs in /reference as well as sub-directories such as/reference/web protocols. A pathname of "/" indicates that the cookie will be used for all URLs at the site from which the cookie originated.
(secure) A TRUE/FALSE value indicating if an SSL connection with the domain is needed to access the variable.
(expiration) The time that the variable will expire on. Omitting the expiration date signals to the browser to store the cookie only in memory; it will be erased when the browser is closed.
(name) The name of the variable.
The limit on the size of each cookie (name and value combined) is 4 kb. A maximum of 20 cookies per server or domain is allowed.
Cookies are the preferred method to maintain state in HTTP protocol. They are however also used as a convenient mechanism to store user preferences and other data including session tokens. Both persistent and non-persistent cookies, secure or insecure can be modified by the client and sent to the server with URL requests. Therefore any attacker can modify cookie content to his advantage. There is a popular misconception that non-persistent cookies cannot be modified but this is not true; tools like Winhex are able to do the job. SSL also only protects the cookie in transit.
The extent of cookie manipulation depends on what the cookie is used for but usually ranges from session tokens to arrays that make authorization decisions.
Cookie ExampleCookie: lang=en-us; ADMIN=no; y=1; time=05:30GMT;
hacker can simply modify the cookie to;
Cookie: lang=en-us; ADMIN=yes; y=1; time=10:30GMT;
Secure vs. Non-Secure
Cookies can be set using two main methods, HTTP headers and JavaScript. JavaScript is becoming a popular way to set and read cookies as some proxies will filter cookies set as part of an HTTP response header. Cookies enable a server and browser to pass information among themselves between sessions. Remembering HTTP is stateless, this may simply be between requests for documents in a same session or even when a user requests an image embedded in a page. It is rather like a server stamping a client and saying show this to me next time you come in. Cookies cannot be shared (read or written) across DNS domains. In correct client operation Domain A can't read Domain B's cookies, but there have been much vulnerability in popular web clients which have allowed exactly this. Under HTTP the server responds to a request with an extra header. This header tells the client to add this information to the client's cookies file or store the information in RAM. After this, all requests to that URL from the browser will include the cookie information as an extra header in the request.
Persistent vs. Non-Persistent
Persistent cookies are stored in a text file (cookies.txt under Netscape and multiple *.txt files for Internet Explorer) on the client and are valid for as long as the expiry date is set for (see below). Non-Persistent cookies are stored in RAM on the client and are destroyed when the browser is closed or the cookie is explicitly killed by a log-off script. Secure cookies can only be sent over HTTPS (SSL). Non-Secure cookies can be sent over HTTPS or regular HTTP. The title of secure is somewhat misleading. It only provides transport security. Any data sent to the client should be considered under the total control of the end user, regardless of the transport mechanism in use.
No comments:
Post a Comment