Patent Application
20090165124
Current web browser security models allow script executing on a web page to make HTTP (HyperText Transport Protocol) requests to interact with other HTTP resources on the same domain. If some of these resources require cookie-based authentication, it is possible for someone to stage a cross-site scripting attack to gain access to a victim's data as long as both resources are on the same domain.
One solution to the problem of cross-site scripting attacks includes generating a new publicly-accessible time-expiring URL (uniform resource locator) for each resource whenever it is needed instead of using cookies for authentication. However, this solution enables the URL to be given to unauthorized parties, who then have temporary access to the resource before the URL expires. Another solution involves using a different domain for every resource owner. For example, a script on alice.server.com cannot communicate with bob.server.com. But here too, the cross-site scripting attack problem can still exist when multiple resources within the same subdomain have different access control lists. And using a different domain for every resource suffers from being overly restrictive—no script is able to make HTTP requests to other resources, even when desired.
This Background is provided to introduce a brief context for the Summary and Detailed Description that follow. This Background is not intended to be an aid in determining the scope of the claimed subject matter nor be viewed as limiting the claimed subject matter to implementations that solve any or all of the disadvantages or problems presented above.
An arrangement for reducing the occurrence of harmful cross-site scripting is provided by segregating on-line content or other resources so that they are accessible at different domains or subdomains, each of which corresponds to a set of users, called a “sharing set,” where each user in the set has identical access privileges to certain resources. The sharing set is provided with an identifier (which may or may not be unique), so that the identifier may be used as the name of the domain or subdomain for which any member of the sharing set is authorized to access the resources located there. In this way, script that is embedded with the content can only be executed among members of the sharing set. Users who are not members of the sharing set are unable to invoke cross site-scripting attacks that would allow them to gain access to data from sharing set members.
In various illustrative examples, a unique identifier is assigned to a sharing set and used as a subdomain name so that HTTP resources may be segregated within subdomains that correspond to a given sharing set. The sharing set identifier may optionally be hashed. An encrypted version of the sharing set identifier (or hashed identifier) may be stored as a token in a path part of the URL for a resource to efficiently validate the sharing set subdomain. And, calls from authorized callers made to non-segregated (i.e., un-protected) domains may be redirected to the appropriate segregated domain.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter.
Like reference numerals indicate like elements in the drawings.
The Internet, which includes a large number of networked computers distributed throughout the world, has become an extremely popular source of virtually all kinds of information. Increasingly sophisticated computers, software, and networking technology have made Internet access relatively straightforward for end users. For example, conventional browser software allows a user to request information or items such as a web page from a network location such as a web site on one or more remote computers. To this end, the user provides the address of the web page (e.g., a uniform resource locator, or “URL”) in some manner to the browser software, and the browser software transmits the request using a communication protocol such as HTTP (HyperText Transport Protocol). The request is then routed to the destination computer or web site based on the address.
When the request is received, the remote web site evaluates the request and returns an appropriate response, which may include the information requested in some formatted content, for example using HTML (HyperText Markup Language). The browser software parses and interprets the returned content to render a page or pages of content on the user's computer display.
When accessed, some web sites attempt to store information on the user's computer, in a small text file referred to as a cookie. Cookies provide for HTTP state management, by which a server may correlate multiple requests coming from the same client. Many times this is desirable to the user, for example, so that the user does not have to repeatedly resubmit information manually to the remote computer hosting the web site, but instead can automatically provide the information as stored in the cookie.
For example, a user can allow cookies to be stored on his or her computer so as to be able to view some web sites, and/or to take advantage of desirable customization features, such as local news and weather, or stock quotes. As can be appreciated, cookies may include sensitive and personal information, or the keystrokes needed to get to a user's sensitive and personal information. For example, a cookie may be used as an authenticator where a cookie may contain a ticket that grants the user access to some restricted resource, such as a personal account at an online brokerage.
Because of the ability to store and exchange sensitive and personal information, Internet security has become a significant concern to individual users, software manufacturers and providers of Internet content.
One way in which Internet security is provided on the client side is via cross domain access rules, which generally ensure that for any received content, that content can only interact with content from the same web domain. For example, a typical page on www.1a2b.com can freely script content on any other page on www.1a2b.com, but cannot script to pages that are located on a different web domain. An enforcement mechanism ensures that only pages with identical domain properties are allowed to freely interact on the client side.
A relatively recent but common security problem is cross-site scripting. Cross-site scripting is a server-side vulnerability that enables malicious script (e.g., written by a hacker) to execute on a client machine. Such vulnerability allows an attacker to inject a piece of script (e.g., JavaScript) into a web page produced by a trusted web server. A browser executes the injected script as if it were provided by the server. Since the security restrictions of a browser are based on the origin of the web page, the script is executed by the browser under the same permission as the domain of the web application, by-passing the security restrictions.
For example, consider a web site that, after a user logs in, redirects the user to a welcome page that returns content based on information passed in the URL (e.g., www.1a2b.com/default.asp?name=username) that when rendered at the client, greets the user by the username that was provided. However, if a script instead of the username is provided, vulnerable servers will pass back the script, and when the welcome page is rendered, the script will be executed on the client side. Thus, if a hacker tricks the user into clicking on a link to that site with a malicious script (instead of the username) sent to the server, such as www.1a2b.com/default.asp?name=<script>evilScript( )</script>, the web site passes back the script embedded into its content, as if it was the username.
When the browser interprets this part of the content as script, the browser automatically runs the script, which is normal browser behavior. However, because the script came from the web site, the script is able to instruct the browser to perform operations in that site's domain, including sending that site's cookie or cookies to another computer, such as the hacker's computer. In this manner, cross site-scripting can steal cookies, and thus a hacker can obtain a user's sensitive information. The problem is difficult to detect at both clients and servers, since servers often return content based on information passed with a URL, and clients often run scripts returned from a server.
Turning now to the drawings,
The server 180 maintains content items and cookies at network locations, shown in
As further shown in
When content 216 is returned, the content is passed from the internet transport component 210 (possibly through other layers of code 220) to browser parser/interpreter code 222 that parses and interprets the content for displaying to the user via a browser user interface 224. The browser parser/interpreter code 222 may invoke a script engine 226 as needed to interpret any script embedded in or referenced by the content.
Similar content also may be stored in a local cache 230 accessed via a cache manager 232 that is included in or otherwise associated with the internet transport component 210. For example, the cache manager 232 manages the cache by maintaining site-to-local-file mappings in a cache table 234 or the like, such that the content and related data may be locally accessed as appropriate. Note that although
The internet transport component or processor 210 includes or is otherwise associated with a mechanism that stores and retrieves cookies, referred to as cookie jar mechanism 246. Although the cookie data 248 are maintained in the system storage unit 236, for simplicity the mechanism 246 (which executes in RAM) and stored cookie data 248 (which may reside in RAM, nonvolatile storage or a combination of both) may be together considered as a cookie jar.
Cross site scripting may occur when the browser parser/interpreter 222 invokes the script engine 226 to interpret malicious script. The malicious script may be used, for example, by a hacker to acquire cookie data 248 associated with the domain from which the malicious script was received. As previously mentioned, cross site scripting problems can be mitigated by storing or otherwise locating on-line resources at domains or subdomains that correspond to sets of authorized users who have the same level of access to the resources. In this way users who are not members of the group cannot cause cross site-scripting attacks that would allow them to gain access to cookies or other sensitive information from the members of the group.
This arrangement can be illustrated with reference to
In this example, the caller 310 uploads three resources for storage with the on-line storage service. In this case, the resources are the three files resume.tex, photos.zip, and report.txt. The three files may be uploaded in a single transaction or in two or three separate transactions. For each file, the caller 310 can specify an access control list (“ACL”) in the form of metadata. Instead of specifying the ACL for each and every file the ACL set can be established once within a parent container in the hierarchy, in which case every uploaded file inherits its parent's ACL unless it is overridden.
The ACL specifies a set of callers having identical access privileges with respect to each of the files. In this example, the files report.txt and photos.zip share the same ACL, which as shown in
For example, as indicated at (2) in
The domain or subdomain names that are associated with the ACLs or a representation of the ACL may be generated in any manner that is desired. For example, the subdomain name may be a concatenation of the ACL ID and the user ID of the user who originally uploaded or owns the on-line resource. However, the explicit use of the ACL ID can in some cases lead to long, unwieldy subdomains and could potentially expose sensitive data, depending on the particular user ID and ACL ID. These problems can be mitigated by using as the subdomain name a hash of the ACL ID. Such an arrangement is illustrated in
In the example shown in
Since the steps employed to generate and validate the subdomain based on the ACL ID may be expensive, the URL may contain an encrypted version of the subdomain or the hash of the subdomain. In this case the storage service 320 only needs to confirm that the subdomain of the requested URL matches the subdomain that has been encrypted. Such an arrangement is shown in the example of
In the example shown in
The storage service 320 calculates the hash of the ACL ID 575-abc-c57-ah8, which in this example is x7jfn, and then encrypts the hash and the file name. Both the hash and the encrypted hash and file are used in the URL at which the file can be located. The complete URL at which the file can be located, http://x7jfn.files.example/p8y77kUo_or ZhfzAA-m0/message.doc, is then forwarded to the caller 310.
In general the subdomain, and hence the full URL cannot be determined by the end user a priori. In some cases, the user may first direct the request to a URL on an unprotected, non-segregated subdomain. When the storage service receives the request, the caller is redirected to a URL on the restricted, segregated subdomain.
At (2), the backing store 330 retrieves the metadata and at (3) returns it to the storage service 320. Using the metadata, the storage service 320 constructs a URL on a restricted subdomain. In this case the URL is calculated in the manner presented above in connection with
Although the subject matter has been described in language specific to structural features and/or methodological acts, it is to be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or acts described above. Rather, the specific features and acts described above are disclosed as example forms of implementing the claims.
