Answers to homework #1

Question 1

Your solutions to this problem were, on the whole, excellent. I was very pleased with your work and how carefully thought-out your solutions were.

I was able to find a confirmed vulnerability in 11 (61%) 6 (33%) were immaculate and had no weakness or vulnerability that I could find. (Compared to how prior classes did: I broke 50% of the solutions the last year I did this, and in all previous years I was able to break 100% of the solutions.) So, well done! Of course, I have a bit of an unfair advantage: I have been collecting examples of obscure browser behavior and subtle pitfalls for the past few years.

Here were the most common attacks that I found on your solutions:

• Blacklisting doesn't work. A few submissions that used a blacklist of bad tags. In every one, the blacklist was incomplete and as a result the submission was insecure.
  
  
• Policy too permissive. In some cases, your policy allowed some tags or combinations of attributes that proved dangerous. Fortunately, this is easy to fix if your enforcement architecture is solid.
  
  
• Shadow-parse attacks, due to insufficient output sanitization. Most of your solutions worked like this: (a) parse the input, (b) filter it, (c) convert the filtered parse tree back to HTML. The final stage (emit to HTML) is arguably the most critical part of your solution: it is the main opportunity to defend against "shadow parse" attacks, where the browser parses your HTML differently than you expected. A good strategy is to escape outputs when you emit them to HTML, when possible, and convert to a canonical format that should have be parsed identically by all browsers. For instance, if you think something is plain text (not markup), rather than just printing it out to the output, a better scheme is to escape the < and > characters (turning them into < and >, respectively), to make sure there's no way any browser will ever interpret it as containing a tag. As another example, whenever you see an attribute, it's a good idea to always quote the value of the attribute (and escape any quotations within the value), to make sure its start and end will be inferred by the browser exactly as you expect.

I have more details about this homework assignment below, broken down into two categories: policy (which tags and attributes should be allowed?), and enforcement architecture (what mechanism do we use to ensure that only tags allowed by the policy appear in the resulting document?).

Mechanism: the enforcement architecture

The only approach that worked reliably is to parse the HTML document to get a parse tree, apply the policy to the parse tree, and then convert it back to a string. Solutions that attempted to use regexps or otherwise work with straight text invariably could be fooled through sufficiently complex or obscure HTML.

Similarly, whitelisting was a must. I found that blacklists were almost always incomplete.

The best solutions parsed the HTML document to get a parse tree, then applied a whitelist to the tags (keeping only tags whose names are on the whitelist), to the attributes (keeping only attributes whose names were on the whitelist), to attribute values (e.g., keeping only URIs whose protocols were on a whitelist), and to the characters that are allowed to appear in the document (HTML or URI encoding all other characters). Everything else was dropped. Then, there was some code to print the resulting parse tree to a string---call this "unparsing", to give it a name.

The final unparsing step is crucial, because we need to make sure that the browser will interpret the resulting HTML document in the same way we did. It is important to HTML-escape values as they are unparsed: for instance, when rendering text that isn't supposed to contain any tags, replace < and > by < and > (respectively) to ensure that the browser doesn't treat this text as containing tags. Part of the problem is that, because erroneous markup is common on the web, many web browsers contain heuristics to try to make sense of technically-invalid syntax and helpfully accept these documents despite their syntax errors. These heuristics may cause the browser to find tags in places that we did not want the browser to find them. By HTML-escaping text that is not intended as a tag, we reduce the chances that some browser heuristic will treat it as a tag.

During the filtering step, we must ensure that no value gets carried over into the output without being checked. One approach is for the filtering phase to accept a parse tree as input, and build up a new parse tree to produce as output, constructing new parse nodes and filling them in with only values that have been filtered. This helps avoid a case where we forgot to check some attribute/aspect of the input node because we weren't aware of its existence. Alternatively, another approach is to skip filtering the tree, and instead move all the logic into the "unparsing" step: we traverse the parse tree and build up an output string from the parsed data, based upon only the whitelisted content (we ignore unsafe tags/attributes and do not emit any output for them).

Escaping and sanitizing data during the "unparsing" step is important. Otherwise, some browsers may find HTML tags in all sorts of places you never would have guessed. For instance, each of the three examples below contain SCRIPT tags that will be recognized by some browsers.

  <SCRIPT/SRC="foo.js">
  <SCRIPT SRC="foo.js" </SCRIPT
  <P<SCRIPT>alert();

It also helps to be conservative and drop elements that have the potential to confuse a browser. Dropping all comments is helpful, because it avoids the risk that the browser parses comments differently than we'd expect. Also, many browsers peer inside comments and interpret <SCRIPT> and <STYLE> blocks inside comments (this idiom was once used for backwards compatibility with browsers that didn't support Javascript, and once browsers add support for a strange hack like this, it's hard to remove it), so if you leave comments intact you may find that you've provided a way for someone to break your filter. I was able to break a few submissions by exploiting subtle aspects of comments.

A few people used blacklisting: they removed all tags (or attributes, or attribute values, or URIs) that are known to be dangerous. However, blacklisting is error-prone. If you forget, or were unaware of, some dangerous tag, you might fail to filter out unsafe HTML. None of the blacklisting-based solutions that I saw were secure. I was able to successfully attack every blacklist-based implementation that I saw, usually by finding some unsafe tag or attribute or type of URL that was omitted from the blacklist.

Implementation issue: Beware mutating a list while iterating over it. An implementation bug I saw in several solutions involved iterating over a set of attributes, and removing each one that was prohibited. Unfortunately, in many languages modifying a list (e.g., deleting some of its items) while iterating over it leads to unexpected behavior. For instance, consider this Python snippet:

l = [0,1,2,3,4,5]
for i in l:
    l.remove(i)

I saw several solutions that iterated over all attributes of a tag, and if the attribute was not on a whitelist, removed the attribute. Unfortunately, this violates the rules, because it is mutating a list while iterating over it. As a result, if the attacker creates an input with a tag that has a bunch of malicious attributes, then half of them will be deleted but the other half will survive. For instance, the following Python snippet is buggy, because it mutates tag.attrs while iterating over it:

for name,value in tag.attrs:
    if name not in whitelist:
            del tag[name]

In some sense, this is just a little implementation bug. But when you have an implementation bug like this, it is worth pondering how you could have structured your code to be more resilient to bugs. One approach is to avoid mutating data structures in place, and build up a new data structure with "only the good stuff". Perhaps a better approach is to use a proof-carrying code trick, where you have two components, the transformer and the verifier. The transformer is supposed to transform the HTML to eliminate all bad stuff; the verifier then checks that no bad stuff is present in the output of the transformer (the verifier does not try to transform the document; if the output if the transformer has any amount of bad stuff, no matter how small, then the verifier fails and nothing is output). In this architecture, only the verifier need be trusted, and bugs in the transformer cannot harm security; this would have protected yourself against this sort of bug. A third possible approach is to build your own pretty-printing engine. If you write your own code to translate from a parse tree to a string, then you can write it so that it only outputs anything for parts of the parse tree that appear to be safe. In that architecture, only this pretty-printing code becomes trusted.

Policy

Tags. To eliminate active content, we must forbid the SCRIPT, OBJECT, EMBED, APPLET tags, as they can be used to invoke active code.

Forms may allow social engineering attacks on the user that trick the user into revealing passwords, data, or uploading files. Probably forms aren't very useful in webmail. Eliminating forms requires stripping FORM and INPUT tags.

Attributes. To eliminate active content, we must forbid the ONCLICK, ONMOUSEOVER, ONDBLCLICK, ONMOUSEDOWN, ONMOUSEUP, ONMOUSEMOVE, ONMOUSEOUT, ONKEYPRESS, ONKEYDOWN, ONKEYUP, ONFOCUS, ONBLUR attributes, as they can be used to execute Javascript. This list is not exhaustive: Microsoft Internet Explorer appears to have introduced many proprietary additional scripting-related attributes of their own -- which is a good argument for a whitelist instead of a blacklist.

URIs. Some URIs can refer to or invoke active code, so we must filter URIs. For instance, <A HREF="javascript:foo()"> executes Javascript code if that link is clicked. There are many ways to conceal the javascript: string, e.g., j%41vascript%3A, jaVaSCRiPt:, jAvascript:, jAvascript:, and so on. Also, data: URIs are potentially dangerous, because they can be used to conceal malicious HTML or other content (which may itself contain Javascript). For this reason, we probably should apply some policy to URIs, e.g., requiring that they refer only to a whitelisted set of protocols (e.g., http: or https:).

URIs can appear in lots of places, including in HREF, SRC, LOWSRC, DYNSRC, LONGDESC, ACTION, CITE, USEMAP, BACKGROUND, PROFILE attributes. URIs can even occur in <META HTTP-EQUIV="Refresh" CONTENT="?: URL=..."> and <PARAM VALUETYPE=ref VALUE="...">. This makes it challenging to ensure that we have applied a policy to every URI.

Images and other external resources. Loading an image or other external content can cause an externally-visible side effect. For instance, consider an HTML email that contains a tiny, 1 pixel by 1 pixel, image loaded from the sender's web server. This image--sometimes called a "web bug"--will be loaded by your browser when you view the email. If each image URI is unique, the sender will be able to tell when you read the email. The sender can also learn the IP address of the machine you used to read the webmail. This is arguably a privacy leak; some email users might feel a bit creeped out if the sender can tell whether and when their email was read. "Web bugs" are widely used by spammers for address verification. The spam email includes a customized image whose URI contains your email address; when that URI is loaded, the spammer will know that you received the email and your email address was valid. Also, because the browser will send cookies along with the request for the image, "web bugs" can be used to track you, and in fact web bugs are frequently used for this purpose on the web by advertisers interested in targeting their advertising. Finally, loading an external resource can cause side effects on your browser, if the remote web server uses its response to set a cookie.

So for privacy reasons it might make sense to strip out anything that could automatically cause images or other resources to be automatically loaded when the email is opened. In other words, arguably we should be stripping all images from the HTML document. An alternative approach is to convert images so they are embedded inside the HTML document, e.g., using a data: URI (which allows to hardcode the contents of the image inside the HTML document, rather than referring to a file stored separately).

CSS. Cascading style sheets (CSS) can contain Javascript that will be executed by some older browsers. e.g.,

  background: url(javascript:alert())
  background: url("http://evil.com/evil.js")
  any: expression(alert())

Hence, the safest thing is to block all CSS, e.g., by blocking STYLE tags and attributes. This is unfortunate, because CSS is a powerful and clean way to specify presentation information (e.g., font sizes, colors, and so on), but it is probably the best one can expect for this homework.

Ultimately, the right answer is probably to write a CSS sanitizer. However, this is more work than I would reasonably expect you to take on in a homework. A large webmail provider might reasonably be able to write a CSS sanitizer to go with the HTML sanitizer, and that would probably be the way to go in practice.

If you overlooked this one, I don't blame you: this is an obscure gotcha, and you aren't the only one to be unaware of it. The Samy worm spread through MySpace due to a similar oversight in MySpace's HTML sanitizer; if you're curious, you can read the story, as told by the author of the Samy worm. Two years later, it was discovered that Facebook had a similar but more complex security hole with Javascript in user-specified CSS styles. This stuff is tricky.

Crazy stuff you have to deal with

Character sets. One of the craziest corner cases in browsers has to do with character sets. You may be familiar with UTF-8, which is a way of encoding Unicode characters as variable-length byte sequences. But have you heard of UTF-7? It's a way of encoding Unicode characters as a variable-length sequence of 7-bit bytes (bytes with their high bit clear).

It turns out that the following:

  +ADw-SCRIPT+AD4-alert(+ACc-xss+ACc-)+ADw-+AC8-SCRIPT+AD4-

  <SCRIPT>alert("xss")<script>

The standard solution is to add a META EQUIV tag at the head of the document you generate, specifying the character set that the HTML sanitizer used, to ensure that the browser interprets the document with the same charset as you did. For instance, your HTML sanitizer could rewrite the HTML to insert the following near the beginning of the document:

  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-8">

You can find more on the charset issue here.

Fortunately, because guessing a UTF-7 character set is so problematic for security, modern browsers will not infer a UTF-7 character set. But older browsers (like IE6) still have a significant market share, so you must design a filter that will be secure for them, too--and some older browsers will guess a UTF-7 character set in some conditions. And, of course, if the document explicitly specifies a UTF-7 character set (e.g., via <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=utf-7">), the browser will honor it--so your policy needs to ensure that the document cannot include such a declaration.

Comments. Be careful when handling comments. HTML supports a funky scheme for nested comments. Check this out:

  V<!--W--X-->Y-->Z

  <!-- W: -- X -->
  <p name="Y: --evadefilter><img onerror=alert(999) src=''/><div name=">