In Section 6.3, we discussed pharming vulnerabilities with library import and data ex- port features in browsers. Many import and export features are not governed by the same- origin policy. Web sites can import libraries from and export data to any domain. Since Web sites routinely use import and export features, without additional protection mecha- nisms, the locked same-origin policies alone are insufficient to protect sites from pharming attacks. Using YURLs for all library import and data export operations resists pharming and active attacks because a YURL explicitly specifies the public key of the server host- ing the library or receiving the data. However, as we discussed at the beginning of this chapter, YURLs may be troublesome for Web sites to manage and deploy. In this section, we discuss some alternative solutions for protecting library import and data export features that work in conjunction with the locked same-origin policies to resist pharming and active attacks.
7.7.1
With the weak locked same-origin policy
The weak locked same-origin policy isolates a domain’s locked Web objects with valid certificate chains from objects with invalid chains. Our goal is to provide similar guaran- tees for Web documents that use library import and data export features. Currently, many browsers will display a warning if a document imports from or exports to a server with an invalid certificate. This warning may be a “ribbon-type” warning, a pop up warning, or a full page warning, depending on the browser and the circumstances. Many of these warn- ings offer a user override option, which allows the import or export to continue, potentially compromising the integrity of the Web application during a pharming or active attack.
One solution to this problem we propose is a variant of YURLs we call weak YURLs. A weak YURL is an HTTPS URL together with a bit flag indicating that the browser should
only connect to a server that provides a valid certificate for the domain in the URL. The security properties of weak YURLs are similar to those the weak locked same-origin policy. In conjunction with the weak locked same-origin policy, weak YURLs resist pharming and active attacks against library import and data export operations as long as an adversary can not obtain a valid certificate for the target domain. If the adversary attempts to intercept the import or export operation, it will cause a certificate error, and the browser will cause the operation to fail without any option for user override.
An advantage of weak YURLs over “strong” YURLs is that weak YURLs are easier to manage and deploy. Strong YURLs require Web sites to maintain an accurate list of public keys for the servers involved in library import and data export operations. Some Web sites import libraries from “third parties”, for example the home page for www.paypal.com includes the following import:
<script type="text/javascript"
src="https://www.paypalobjects.com/...">
If the server for www.paypalobjects.com updates its public key and www.paypal. com fails to update its “strong” YURL to use the new public key, this import will fail, potentially breaking the functionality of the application. Weak YURLs avoid this problem. As long www.paypalobjects.com always uses a valid certificate, then a weak YURL will always resolve successfully (except during an attack, of course). One easy protocol to take advantage of weak YURLs is for a Web site to include a special HTTP or HTML header indicating that compliant browsers should interpret all URLs in the document as weak YURLs.
A disadvantage of this solution is that unlike the weak locked same-origin policy, weak YURLs require minor server modifications. However, if the enclosing document was fetched from a server with a valid certificate, we argue that browsers could by default safely interpret all “first-party” URLs (i.e., URLs with the same domain as the enclosing docu- ment, including relative URLs) in import and export operations as weak (valid) YURLs with little risk of breaking those applications. In other words, if the enclosing document was fetched from a server with a valid certificate, all import and export operations (in the enclosing document) to the same domain must also be to a server with a valid certificate,
otherwise the operation will fail with no chance of override. This would only cause a prob- lem if a domain has multiple servers with a mix of valid and invalid servers, and only 0.05% of the domains in our survey had this property (Section 7.4.3). This policy does not require any server changes and helps Web applications that only import from and export to their originating domain resist pharming and active attacks.
7.7.2
With the strong locked same-origin policy
To resist pharming and active attacks against import and export operations in conjunc- tion with the strong locked same-origin policy, we propose extending the policy file mech- anism in Section 7.5. To authorize a domain for import or export operations, a Web site includes the domain and its associated public keys in the policy file. Although, conceptu- ally this is similar to using YURLs for all import and export operations, we argue that this solution is easier for sites to deploy than YURLs. Policy files allow sites to consolidate the public keys of the import/export servers in a single location without requiring significant changes to their server infrastructure or Web application framework.