Abstract:
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.

Description:
BACKGROUND 
       [0001]    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&#39;s data as long as both resources are on the same domain. 
         [0002]    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. 
         [0003]    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. 
       SUMMARY 
       [0004]    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. 
         [0005]    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. 
         [0006]    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. 
     
    
     
       DESCRIPTION OF THE DRAWINGS 
         [0007]      FIG. 1  is a simplified block diagram of an illustrative client-server environment that shows components of a client computer on which browsing software is executed and a server that may be used to host an on-line storage service; 
           [0008]      FIGS. 2A and 2B  show an illustrative process by which a user uploads and downloads, respectively, a resource for storage to an on-line storage service that includes a storage service and a backing store; 
           [0009]      FIGS. 3A and 3B  show another illustrative process by which a user uploads and downloads, respectively, a resource for storage to an on-line storage service that includes a storage service and a backing store; 
           [0010]      FIGS. 4A and 4B  show another illustrative process by which a user uploads and downloads, respectively, a resource for storage to an on-line storage service that includes a storage service and a backing store; and 
           [0011]      FIG. 5  shows an illustrative process by which a call to an unprotected, non-segregated domain is redirected to a restricted, segregated domain. 
       
    
    
       [0012]    Like reference numerals indicate like elements in the drawings. 
       DETAILED DESCRIPTION 
       [0013]    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. 
         [0014]    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&#39;s computer display. 
         [0015]    When accessed, some web sites attempt to store information on the user&#39;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. 
         [0016]    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&#39;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. 
         [0017]    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. 
         [0018]    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. 
         [0019]    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. 
         [0020]    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=&lt;script&gt;evilScript( )&lt;/script&gt;, the web site passes back the script embedded into its content, as if it was the username. 
         [0021]    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&#39;s domain, including sending that site&#39;s cookie or cookies to another computer, such as the hacker&#39;s computer. In this manner, cross site-scripting can steal cookies, and thus a hacker can obtain a user&#39;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. 
         [0022]    Turning now to the drawings,  FIG. 1  is a block diagram of the pertinent components of a client computer  110 , on which browsing software  200  is executed, and a server  180  that may be used to host an on-line storage service. The browsing software  200  communicates via a network interface software and hardware unit  202  with remote server such as network server (or simply “server”)  180 . The communication may include requests for content (e.g., HTTP “GET” requests) such as the request  204 , and result in responses such as the response  206  being received from the server  180 . Communication between the client computer  110  and the server  180  typically uses a network protocol, such as HTTP. 
         [0023]    The server  180  maintains content items and cookies at network locations, shown in  FIG. 1  as the block labeled  208 . Network servers may thus include HTTP web sites, including those having sites with different names (which may be regarded as different virtual servers even if they are hosted on the same physical machine). Note that a web site may be distributed over many virtual servers, which in turn may be distributed over many physical machines. 
         [0024]    As further shown in  FIG. 1 , an internet transport component or processor  210  (e.g., wininet.dll) handles much of the processing of the server&#39;s response  206 . Part of the response  206  comprises one or more headers  212 . The server response  206  may include the requested content  216  and/or cookie (data)  218 , which may be located within the header  212 . 
         [0025]    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. 
         [0026]    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  FIG. 1  shows a single storage unit  236  as maintaining the various data, it is emphasized that the data may be maintained in and/or distributed among separate storage units. 
         [0027]    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. 
         [0028]    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. 
         [0029]    This arrangement can be illustrated with reference to  FIG. 2A , which shows a caller  310  (e.g., client computer  110  shown in  FIG. 1 ) who wishes to upload various resources such as content files or items to an on-line storage service. The on-line storage service may include one or more real or virtual servers, the latter of which may be web sites with different addresses or subdomains that are hosted on the same physical machine. It should be noted that a web site may be distributed over many virtual servers, which in turn may be distributed over many physical machines. In the particular example shown in  FIG. 2A  and the drawings that follow, a storage service  320  (e.g., hosted by the remote server  180  shown in  FIG. 1 ) and a backing store  330  are utilized. As noted, the storage service  320  and the backing store  330  may reside on the same or different machines or systems. 
         [0030]    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&#39;s ACL unless it is overridden. 
         [0031]    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  FIG. 2A , includes the set of members {Alice, Bob}. Likewise, the file resume.tex has an ACL that specifies the set of members {Bob, Eve}. As indicated at ( 1 ) in  FIG. 2A , each file and its associated metadata (e.g., the ACL ID) is uploaded to the storage service  320 . The storage service  320 , in turn, directs the backing store  330  to store each file so that they can be accessed at a URL having a subdomain that is unique to each ACL or a representation thereof. 
         [0032]    For example, as indicated at ( 2 ) in  FIG. 2A , the subdomain associated with the ACL {Alice, Bob} may be 575-abc-c57-ah8.files.example and the subdomain associated with the ACL {Bob, Eve} may be 575-jgh-d22-00z.files.example. Thus, the files report.txt and photos.zip may be accessed at the URLs http://575-abc-c57-ah8.files.example/report.txt and http://575-abc-c57-ah8.files.example/photos.zip, respectively. The file resume.tex may be accessed at the URL http://575-jgh-d22-00z.files.example/resume.tex. As indicated at ( 3 ) in  FIG. 2A , these URLs are forwarded by the storage service  320  on storage service to the caller  310 . 
         [0033]      FIG. 2B  shows an illustrative process that may be performed when a caller attempts to access one of the files (i.e., report.txt) that was uploaded in  FIG. 2A . As shown at ( 1 ), the caller&#39;s browser requests the URL http://575-abc-c57-ah8.files.example/report.txt, which is linked to the file report.txt. Under the direction of storage service  320  running on the storage service, at ( 2 ) the backing store  330  retrieves the file report.txt and the associated metadata, which in this case is the ACL ID that identifies the set of authorized callers {Bob, Eve} is retrieved from the backing store  330 . The file and the metadata are forwarded to the storage service  320  at ( 3 ) in  FIG. 2B . The storage service  320  then compares the ACL ID of the caller with the ACL ID associated with the requested file. If they match, indicating that the caller is a member of the group allowed to access the file, the requested file is forwarded to the caller at ( 4 ). 
         [0034]    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  FIGS. 3A and 3B . 
         [0035]    In the example shown in  FIG. 3A , a caller  310  is uploading the file message.doc, which, as indicated at ( 1 ), has an ACL that includes the members {Alice, Bob}. The ACL ID associated with the ACL {Alice, Bob} is 575-abc-c57-ah8. As shown at ( 2 ), the file message.doc and the ACL ID are stored in the backing store  330 . The storage service  320  calculates the hash of the ACL ID 575-abc-c57-ah8, which in this example is x7jfn, and uses this as the subdomain name at which the file can be located. The complete URL at which the file can be located, http://x7jfn.files.example/message.doc, is then forwarded to the caller  310 . 
         [0036]      FIG. 3B  shows an illustrative process that may be performed when a user attempts to access the file message.doc that was uploaded in  FIG. 3A . As shown at ( 1 ), the user&#39;s browser requests the URL http://x7jfn.files.example/message.doc, which is linked to the file message.doc. Under the direction of the storage service  320 , at ( 2 ) the backing store  330  retrieves the file message.doc and the associated metadata, (which in this case is the ACL ID 575-abc-c57-ah8), which identifies the set of authorized users {Alice, Bob}. The file and the metadata are forwarded to the storage service  320  at ( 3 ) in  FIG. 2B . The storage service  320  then calculates the hash of the ACL ID and compares it with the subdomain of the URL requested by the caller  310 . If they match, indicating that the caller is a member of the group allowed to access the file, the requested file is forwarded to the caller at ( 4 ). 
         [0037]    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  FIGS. 4A and 4B . 
         [0038]    In the example shown in  FIG. 4A , a caller  310  is uploading the file message.doc, which, as indicated at ( 1 ), has an ACL that includes the members {Alice, Bob}. The ACL ID associated with the ACL {Alice, Bob} is 575-abc-c57-ah8. As shown at ( 2 ), the file message.doc and the ACL ID are stored in the backing store  330 . 
         [0039]    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 . 
         [0040]      FIG. 4B  shows an illustrative process that may be performed when a user attempts to access the file message.doc that was uploaded in  FIG. 4A . As shown at ( 1 ), the user&#39;s browser requests the URL http://x7jfn.files.example/p8y77kUo_or ZhfzAA-m0/message.doc, which is linked to the file message.doc. The storage service  320 , at ( 2 ) decrypts the URL and verifies that the subdomain x7jfn matches the subdomain encoded in the metadata associated with the requested file, and directs the backing store  330  to retrieve the file (but not the metadata). The file is forwarded to the storage service  320  at ( 3 ) in  FIG. 4B  and the storage service  320  sends it to the caller  310  at ( 4 ). 
         [0041]    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.  FIG. 5  shows such an arrangement in which a user wishes to access the file message.doc. In this case, at ( 1 ) the caller requests the file from the storage service using the trusted subdomain storage.example. That is, the caller&#39;s browser requests the URL http://storage.example/message.doc. 
         [0042]    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  FIGS. 4A and 4B . That is, the URL is http://x7jfn.files.example/p8y77kUo_or ZhfzAA-m0/message.doc. The storage service  320  then returns this URL to the caller so that the user can access the file using the techniques described above. 
         [0043]    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.