CS155: Homework #2

Spring 2010

Due: Thursday, May 20

Problem 1: Same-origin policy

The browser same-origin policy (SOP) actually consists of several different policies, including separate SOPs for DOM access and cookies. The SOP for DOM access is based on the triple (protocol, host, port), while the SOP for sending cookies to sites involves the domain and path. Cookies designated "secure" are sent by the browser over HTTPS only. In current browsers, reading document.cookie in an HTTP context does not reveal secure cookies.

Suppose the SOP for DOM access was defined using only host and port only (as was the case in Safari until Safari 3.0) and did not include the protocol.

Explain how a network attacker could steal secure google.com cookies. (Hint: A gmail user may log in using a form served over https, but then receive a google.com page served over http.)
Under the same assumptions, is it possible for a web attacker to steal secure google.com cookies? Describe an attack or explain why you believe none exists. Recall that a web attacker can set up a malicious web site, and operate a browser to visit any site, but cannot intercept or forge network packets. Assume the user is willing to visit any site set up by the web attacker, but the web attacker can only set up web sites at domains other than google.com.

Problem 2: Secure open redirects

Many sites use public scripts that take a URL as a parameter and send the browser to that URL. For example, on LinkedIn, the following link is used to redirect the browser to a user's personal homepage:

http://www.linkedin.com/redirect?url=http://crypto.stanford.edu/cs155

Sites use redirects to learn that the user clicked on an external link. Search engines, for example, use redirects to learn what search result the user clicked on. While open redirects are widely used, they pose a security risk. A phisher, for example, can create a LinkedIn phishing page and trick the user into clicking on

http://www.linkedin.com/redirect?url=http://phisher.com

Clicking on this link will lead to the phishing page, but users will think they are at LinkedIn. Your goal is to design a secure redirect script that will only redirect to URLs that the site approves. Note that it is unreasonable for the redirect script to maintain a whitelist of all external links at the site. First, external links are frequently added and removed. Second, in the case of a search engine, all links are valid links.

A first idea is to rely on the Referer header. In the case of LinkedIn, the redirect script would check that the Referer header is a LinkedIn page, and ignore all other redirect requests. Explain why this approach does not work.
Propose a secure method. That is, a single redirect script that will only redirect to URLs authorized by the site. Make sure to describe your method in sufficient detail.
Hint: use cryptography.

Problem 3: Cookies

Explain what are httpOnly cookies.
What attack are httpOnly cookies intended to prevent? Give an example attack that does not work if the site uses httpOnly cookies, but works with normal cookies.
Show that httpOnly cookies do not eliminate the class of attacks from part (b). Give an example where httpOnly cookies do not improve security.

Problem 4: DNSSEC

DNSSEC (DNS Security Extensions) is designed to prevent network attacks such as DNS record spoofing and cache poisoning. When queried about a record that it possesses, such as when the DNSSEC server for example.com is queried about the IP address of www.example.com, 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 parlance) 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 send packets to R that appear to originate from S.

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.
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?
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?
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?
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.
How should the resolver verify the validity of a response under NSEC3?
The hashes in NSEC3 are a function of the original name, plus a salt and an iteration parameter, computed as follows (from the RFC):
```
 
   Define H(x) to be the hash of x using the Hash Algorithm selected by
   the NSEC3 RR, k to be the number of Iterations, and || to indicate
   concatenation.  Then define:
 
      IH(salt, x, 0) = H(x || salt), and
 
      IH(salt, x, k) = H(IH(salt, x, k-1) || salt), if k > 0
 
   Then the calculated hash of a name is
 
      IH(salt, name, iterations)
```
In a NSEC3 reply, the name of the hash function, the salt and the number of iterations are also included, and all names use the same salt value and the same number of iterations.
Assume that an attacker can get all of the NSEC3 responses for a domain suffix and has access to a dictionary of common host names. Describe how the can use the NSEC3 responses to enumerate hostnames with this domain suffix.
Hint: you may assume that the attacker has a dictionary of common host names that contains all the names of interest for the domain.
Bonus: Why is the salt useful (as part of DNSSEC)? Be sure to consider the fact that the salt for a domain is public and the same for all names that are hased when NSEC3 is used for that domain.

Problem 5: Firewalls

The two main kinds of firewalls are packet-filter firewalls and application-layer gateways. Packet-filter firewalls can either be stateless or stateful. For each of the following attacks, state the simplest form of firewall that can be placed between an enterprise network and the external Internet to detect and significantly mitigate the attack. Explain each answer briefly.

Port sweep
Syn flooding (too many SYN packets with no matching ACK)
DNS cache poisoning
viruses in incoming email addressed to enterprise users
DNS rebinding
unrequested streaming video

CS155: Computer and Network Security