CS155: Computer and Network Security

CS155: Homework #2

Spring 2016

Due: Thursday, May 19

Problem 1: Cross Site Script Inclusion (XSSI) Attacks

Consider a banking web site bank.com where after login the user is taken to a user information page 

https://bank.com/accountInfo.html
The page shows the user's account balances. Here accountInfo.html is a static page: it contains the page layout, but no user data. Towards the bottom of the page a script is included as: 
<script src="//bank.com/userdata.js">      (*)
The contents of userdata.js is as follows: 
displayData({"name": "John Doe",
             "AccountNumber":  12345,
             "Balance": 45})
The function displayData is defined in accountInfo.html and uses the provided data to populate the page with user data.

The script userdata.js is generated dynamically and is the only part of the page that contains user data. Everything else is static content.

Suppose that after the user logs in to his or her account at bank.com the site stores the user's session token in a browser cookie.

  1. Consider user John Doe who logs into his account at bank.com and then visits the URL https://evil.com/. Explain how the page at evil.com can cause all of John Doe's data to be sent to evil.com. Please provide the code contained in the page at evil.com.
  2. How would you keep accountInfo.html as a static page, but prevent the attack from part (a)? You need only change line (*) and userdata.js. Make sure to explain why your defense prevents the attack.
    Hint: Try loading the user's data in a way that gives bank.com access to the data, but does not give evil.com access. In particular, userdata.js need not be a Javascript file.

Problem 2: Certificate pitfalls

John Smith generates a public/private key pair, and buys from a trusted CA (e.g. Symantec) a personal certificate for John Smith on his public key. He then generates a second public/private key pair, and uses his John Smith private key to sign a certificate on the second public key where the common name is set to www.amazon.com. John now has two certificates: one signed by Symantec for subject John Smith and another signed by John Smith for subject www.amazon.com.

Now, John, being the malicious sort mounts a man-in-the-middle attack on an SSL connection to Amazon.com from some unsuspecting user. John presents his forged certificate chain for www.amazon.com to the intercepted user. The intercepted user’s browser incorrectly accepts the fake Amazon certificate as legitimate because there is a valid certification path to Symantec's trusted CA.

  1. Why does this scenario present an attack? How can it be exploited?
  2. How would you fix this problem? That is, what would the intercepted user's browser need to do to prevent the problem? What would Symantec need to do? Hint: The certificate format is called X509v3. Read about the "CA bit" in the Basic Constraints field of an X509v3 certificate.

Problem 3: The HTML canvas element

The canvas HTML element creates a 2D rectangular area and lets Javascript draw whatever it wants in that area. Canvas is used for client-side graphics such as drawing a path on a map loaded from Google maps. For the purpose of the associated same-origin policy, the origin of a canvas is the origin of the content that created it. In the map example, the origin of the Javascript that creates the canvas is Google. Canvas lets Javascript read pixels from any canvas in its origin using the GetImageData() method.
  1. Canvas lets Javascript embed images from any domain in the canvas. Suppose a user has authenticated to a site that displays private information. Describe an attack that would be possible if Javascript from one domain could embed an image from another domain in the canvas and then use GetImageData() to read pixels from that image.
  2. How would you restrict GetImageData() to prevent the attack above?
  3. A canvas element can be placed anywhere in the browser content area and can be made transparent so that the underlying content under the canvas shows through. What security problem arises if calling GetImageData() always returned the actual pixels shown on the screen at that position?
  4. How would you design GetImageData() to defend against the vulnerability from part (c)? Propose a design that does not require the browser to test if the requested pixel is over content from another origin.

Problem 4: CSRF Defenses

  1. In class we discussed Cross Site Request Forgery (CSRF) attacks against web sites that rely solely on cookies for session management. Briefly explain a CSRF attack on such a site.
  2. A common CSRF defense places a token in the DOM of every page (e.g. as a hidden form element) in addition to the cookie. An HTTP request is accepted by the server only if it contains both a valid HTTP cookie header and a valid token in the POST parameters. Why does this prevent the attack from part (a)?
  3. One approach to choosing a CSRF token is to choose one at random. Suppose a web site chooses the token as a fresh random string for every HTTP response. The server checks that this random string is present in the next HTTP request for that session. Does this prevent CSRF attacks? If so, explain why. If not, describe an attack.
  4. Another approach is to choose the token as a fixed random string chosen by the server. That is, the same random string is used as the CSRF token in all HTTP responses from the server over a given time period. Does this prevent CSRF attacks? If so, explain why. If not, describe an attack.
  5. Why is the Same-Origin Policy important for the cookie-plus-token defense?

Problem 5: The trouble with non-prepared SQL statements

Consider the following (amateur) PHP script for a login page: 
$username = $_GET[user];
$password = $_GET[pwd];
$sql = "SELECT * FROM usertable
            WHERE username = ’$username’
            AND password = ’$password’ ";
$result = $db->query($sql);
if ($result->num_rows > 0) { /* Success */ }
else { /* Failure */ }
  1. Give a value that an attacker can enter in the field called user that will result in a successful login? Assume the attacker does not know any usernames or passwords for the site.
  2. Suppose we change lines 1 and 2 to 
    $username = addslashes($ GET[user])
$password = addslashes($ GET[pwd])
    The addslashes PHP function adds a slash before every quote. That is addslashes("a'b") will output the string "a\'b". Explain why this prevents the attack from part (a).
  3. Does addslashes() completely solve the problem? Consider the GBK Chinese unicode character set. Some characters in GBK are single bytes while others are double bytes. In particular, the following table shows a few GBK characters:
    0x 5c = \
    0x 27 = '
    0x bf 27 = 뼧
    0x bf 5c = 뽜
    That is, the database interprets 0x bf 5c as a single chinese character. Show that using a simple addslashes() that adds a slash (0x5c) before every quote (0x27) as in part (b) leads to a SQL injection attack. What value of user will result in a successful login?

Problem 6: DNSSEC

DNSSEC (DNS Security Extensions) is designed to prevent network attacks such as DNS record spoofing and cache poisoning. Generally, the DNSSEC server for example.com will posses the IP address of www.example.com. When queried about this record that it possesses, the DNSSEC server will return its answer with an associated signature. If the DNSEC server is queried about a host that does not exist, such as doesnotexist.example.com, the server uses NSEC or NSEC3 to show that the DNS server does not have an answer to the query.

Suppose a user R (a resolver, in DNS terminology) queries a DNSSEC server S, but all of the network traffic between R and S is visible to a network attacker N. The attacker N may read requests from R to S and may send packets to R that appear to originate from S.

  1. Why is authenticated denial of existence necessary? To answer this question, assume that S sends the same unsigned DOES-NOT-EXIST response to any query for which it has no matching record. Describe a possible attack.
  2. Assume now that S cryptographically signs its DOES-NOT-EXIST response, but the response does not say what query it is a response to. How is an attack still possible?
  3. A DNSSEC server may send a signed NSEC response to a query that does not have a matching record (such as doesnotexist.example.com). An NSEC response contains two names, corresponding to the existent record on the server that immediately precedes the query (in lexicographic order), and the existent record that immediately follows the query. For example, if a DNSSEC server has records for a.example.com, b.example.com, and c.example.com, the NSEC response to a query for (non-existent) abc.example.com contains a.example.com and b.example.com because these come just before and just after the requested name. To be complete, NSEC records also wrap-around, so a query for a non-existent name after the last existent name will receive an NSEC containing the last and first existent names.

    How should the resolver use the information contained in NSEC records to prevent the attacks you described in previous parts of this problem?

  4. NSEC leaks information that may be useful to attackers on the Internet. Describe how an attacker can use NSEC to enumerate all of the hosts sharing a common domain-name suffix. How is this information useful for attackers?
  5. NSEC3 is designed to prevent DNS responses from revealing unnecessary information. NSEC3 uses the lexicographic order of hashed records, instead of their unhashed order. In response to a query without a matching record, NSEC3 will return the hashed names that are just before and just after the hash of the query. For example, on a server containing a.example.com, b.example.com, and c.example.com, if a hashes to 30, b to 10, c to 20, and abc to 15, the NSEC3 response to a query for abc.example.com would contain 10.example.com and 20.example.com. Hashed names are also assumed to wrap around, in the same way as unhashed names in NSEC.

    Explain how a resolver should verify the validity of a response under NSEC3?