Interaction

Interaction

Interaction

  Contributions  

Cookie Tampering

 

Contents

Description

  • Background
    • Cookies are technically small pieces of text that are sent to the Web client browser by a server and intended to be sent back to the server; unchanged, each time it accesses the same server or another server in the same domain.
    • Cookies are used for authentication, tracking, maintaining state Over stateless HTTP.
    • The minimum size of a cookie is a name-value pair.
  • Cookies are used :
  • In Web applications that used online or virtual shopping baskets.
  • Used when users log in to a Web site.
  • Used to save user preferences for a site so that the site presentation and functionality can be personalized, based on the preferences of the user.
  • Used to track user actions across the site or domain.
  • Cookies are destroyed at the point the user closes the browser unless a deletion date has been set.
  • If a deletion date has been set. the cookie will be destroyed on that date instead.
  • Cookies are supposed to be sent only to the server that set them or another server in the same Internet domain.
  • There are some privacy and security concerns around the use (and misuse) of cookies and that has caused some legislation to be enacted to the United States and the European Union.
  • It is also important to know that the only real restriction on cookies is a maximum of 300 at a time which is respected by most browser manufacturers.
  • The site can create one cookie or a lot of cookies — the number is truly up to the site in question and its needs.
  • Cookies are supposed to be sent only between the Web browser and the server or servers in the same domain that set the cookie. But if the is being sent Over an ordinary HTTP connection, it is visible to across the network using a packet sniffer.

Examples

  • For example. cross-site scripting can be used to send cookies to servers that should not he receiving that data. Encryption does not help stop this cookie theft, which is often done with a simple snippet of HTML posted to a site that users can he tricked into clicking on. and which will send their cookie for that site to a location that the attacker specifies.
  • Because the request is coming from the same domain intended for the cookie. there are no problems. These cookies can then be exploited by connecting to the same site using the stolen cookies, thus spoofing the original owner of the cookie.
  • Cookies are supposed to be sent hack to the server unchanged. but attackers can modify the value of a cookie before sending them back to the server. This is typically done to carry out some sort of attack against the server that relates to some sort of data contained in the cookie.

Example

  • If a cookie contains the price per item for something in the shopping basket, a change to this value in the cookie may cause the server to charge the user a lower price for that item. This process of modifying a cookie before it is sent hack to the server is called Cookie poisoning. Sometimes, cookie poisoning is used after cookie theft.
  • There are aspects to how cookies are used in some situations that cause cookies to carry inaccurate data on which to base sensitive transactions.
  • One issue is that separate people using the same computer. browser. and user account will unavoidably share cookies.
  • Another is that if a single user uses multiple browsers, multiple computers. or multiple user accounts. it means that the user will have multiple sets of cookies.

Cross-Site Cooking

  • Despite the fact that each site is supposed to have its own set of cookies and to not be able to alter or set cookies for any other site, There are some browser flaws that cause cross-site cooking vulnerabilities and allow malicious sites to break this rule.
  • Many browsers have a flaw in how they deal with overly relaxed cookie domains. They are supposed to require a two-dot specification for all domains under the following top-level domains:
    • .com
    • .edu
    • .net
    • .org
    • .gov
    • .mil
    • .int
  • This is supposed to prevent the setting of a cookie for a subdomain like .COM. So, the actual intent is that if you wish to set a cookie on a .COM site, you need to specify “.mysite.com” as the two-dot name.
  • This breaks when you get to the international naming system for some domain' like .COM.AU or .COM.DE. In some browsers, it's possible for a cookie to be set for the entire .COM.AU (for example) domain.
  • Another problem is how some browsers deal with periods. There is typically no check to see whether there is anything between the periods or if there is trailing period being used to override the local domain search path.
  • Attackers can force cookies on random visitors' which are then relayed to a third-party site by setting IN A record and then redirecting users to the third-party site.

Anatomy of an Exploit

  • The attacker posts an auction that includes a link to what is advertised to be additional pictures or information about the object in the auction. Instead, when users click on the link, their cookie for the auction Web site is sent to the attacker's server, where a CGI script logs the information.
  • Now the attacker can look through the list of cookies and pick some of the most recent cookies to use to try to log in to the auction site and spoof the user.
  • The attacker visits an E-commerce site and adds an expensive item to his shopping cart. Then, the user examines the cookie stored on his system from that site to see whether the cookie includes the total cost of the items in the attacker's cart.
  • The attacker then modifies the cookie on his system to change the total to be $5.00 and resaves the cookie. Then, the user returns to the E- commerce site and checks his cart to see that the total is now $5.00 and proceeds to order the items for the false price.

Cross-Site Cooking

  • The attacker crafts a cookie for the domain “.COM.UK” and sets up a Web site to distribute the cookie. Then, the attacker posts a link to his Web site on various bulletin boards or via e-mail, and when the users click on the link, they are given the attacker's crafted cookie that can then overwrite or disrupt the real business they do with Web sites in that international domain.
  • A cookie theft vulnerability was reported in January 2005 in the Froogle comparison shopping service.
  • Although the details reported are sketchy, it appears that malicious JavaScript in URL points to Froogle. Once a user clicks that link , the Java script execute a redirect to a malicious Web site, which then steals the user's Google cookie.
  • This stolen cookie apparently contained the username and password for the “Google Accounts” centralized log in service, information that is used by multiple Google services.
  • Cross-Site Cooking:
    • At the moment, cross-site cooking is a proof of concept that demonstrates the vulnerability and hasn't emerged in the wild.

Test Techniques

  • Black-Box Testing
    • The first thing you need to do is know just what cookies are being created by the application and when, and you need to know when and how the cookies are modified.
    • As a black-box tester, you really need to explore the application, track what cookies are being set where, and exactly what they contain. Then. delete or modify the cookie, and see where the system is looking for the data from the cookies. You need to see where the application modifies the cookies.
    • Generally start with a spreadsheet and have the page name on the left, a column for the date and time obtained, and then the contents of the cookies on the right, so I can compare them and the track changes.
    • You should make multiple passes through the product with different user identities to give you a good amount of data to examine, and always include as many user states as you can (logged in, of not logged in,etc).
  • Analyze the Gathered Cookies
    • Once you have some data gathered, you need to examine the cookies you have gathered to try to get an idea of what they are supposed to tell the server or store.
    • The major items to look for are:
      • Predictability — By looking at several samples of the cookies, can you detect a pattern in the format or makeup of the cookies? There can be obviously predictable formats that are made clear by the use of delimiters or labels. There can also be hints in the name of the cookie itself. What changes in the cookies were issued from different sessions? For different users? What causes the cookie to be modified?
      • Sensitive data storage — See if you can determine or guess what data is being stored in this cookie. Sometimes the labels help, but sometimes you can make educated guesses from hints of format, content, etc.
      • Secure flag — Is the secure flag set? This would indicate the cookie is only supposed to be sent over a secure connection and may indicate the cookie contains sensitive data.
      • Expiration data — If a cookie holds session information, it should either have a very short expiration date or no expiration, so that it will be deleted when the browser session is closed. If the cookie is meant to contain nonsensitive information, it may have a longer expiration date.
  • Compare to Documentation
    • Just because you are doing black-box testing does not mean that you cannot seek out any documentation on what the individual cookies are supposed to do and contain.
    • If there is any documentation available, compare that to your spread sheet of notes and guesses and see if any issues are immediately obvious.
    • Disparities can emerge between documentation and reality, and there may be cases where security measures (secure lag and expiration date) are not in place where they should be.
    • These tested cookies become the first to manipulate and explore for vulnerabilities, as described in the next step.
  • Modify Cookies
    • Now you need to start experimenting with the cookies to see if you can find vulnerabilities. If you have documentation to use, you can start with the ones you marked as most interesting. Otherwise, you can start wherever you think the most risk is.
    • Start by modifying one field of one cookie at a time. If you have found a Pattern to the cookie, test both inside and outside the pattern.
    • Naturally, cookies with one or more pieces of data in clear text are the easiest to modify, but to experiment with other cookies and cookie fields, too.
    • Don't stay within the field size the real cookie is using. It may be possible to create an overflow, and that should be explored as well.
    • Write down the results of each attempt and listen to your intuition when it comes to potential vulnerabilities.
  • Cookie Misuse
    • Don't forget to try other cookie uses that go beyond cookie tampering. Try testing as if you had stolen someone else's valid cookie.
  • White-box
    • White-box testing of cookie vulnerabilities uses the same basic theories, but because you have direct insight into the code that saves and reuses the cookies, you don't have carry out the somewhat tedious task of reverse engineering the cookie itself.
Panel title
Lorem Ipsum Dolorestitas
Percipit Mnesarchum Molestie Phaedrum Luptatum constituam Habeo adipisci Inani zril Forensibus sea Habeo adipisci Minimum corrumpit Regione suscipit Has et partem Percipit Mnesarchum Molestie Phaedrum Luptatum constituam Habeo adipisci Inani zril Vel nisl albucius Habeo adipisci Minimum corrumpit Regione suscipit Percipit maiestatis Regione suscipit Percipit maiestatis
Subtitle
Minimum corrumpit Regione suscipit Has et partem
This page was last edited on 29.07.2017 | Template by HTML5 Templates
Privacy policy About Terms and conditions Cookie statement Developers