Patent Application
20140280883
1. Technical Field
This disclosure relates generally to web application security and, in particular, to a method and system for ensuring that a web browser updates URL references upon receipt of an authentic HTTP redirect.
2. Background of the Related Art
One way that computers interact via networks such as the Internet is using the HyperText Transfer Protocol (HTTP) open standard designed by the World Wide Web Consortium (W3C) and standardized as Internet Engineering Task Force (IETF) RFC 2616. It is an intentionally simple and open protocol that is implemented across many heterogeneous computer systems.
An “HTTP redirect” is a mechanism in which an HTTP server can indicate to a user-agent, such as a Web browser, that further action is needed to fulfill the request. A simple example is a resource moving to a different location. The original server can provide a pointer to the new location of the resource, and it can further indicate that the pointer is intended to be permanent or temporary.
A web application often needs to modify its URL structure, e.g., to point to a new domain. When the web application has active users, however, the modification of URL structure is a troublesome task. The most difficult aspect is making sure that, even if URLs change, user impact is minimal. In particular, it is important that URLs are preserved in user clients (e.g., bookmarks in web browsers, URLs in feed readers and other rich-clients that use REST-based APIs, and the like) and continue to work for at least some transition period following the change. Typically, this goal is achieved by using HTTP redirects (from an old to a new location). There are two (2) main types of redirects: temporary, when the client is instructed to temporarily use another location (e.g., for a login page or a resource), and permanent, when a resource (e.g., a Web application's URL domain structure) changes permanently. As is well-known, these redirects are done through HTTP response codes, respectively, an HTTP 302 (temporary) and an HTTP 301 (permanent), which are returned from a web application to a requesting user-agent, such as a Web browser.
The HTTP specification (RFC 2616) defines that on permanent redirection (the HTTP 301) “clients with link editing capabilities ought to automatically re-link references to the Request-URI to one or more of the new references returned by the server, where possible.” In other words, and according to the protocol, the requesting client should update its references (e.g., bookmarks, feeds, and the like) upon receipt of an HTTP 301 response. Using such an approach theoretically makes the transition to a new URL scheme easier, as clients with old URLs recorded gradually update to the new scheme and after which transition redirects may be removed.
Practically, however, clients typically ignore (some purposefully) this requirement and do not update their URL references for HTTP 301 redirection. The main reasons for this behavior are usability and security problems. Thus, for example, consider a pay-per-use internet provider (e.g., at an airport or hotel), which providers often send the HTTP 301 redirect code incorrectly. If a browser updates links for this redirection, those links would be permanently changed to the incorrect location (and thus broken). In another example, if a browser updates URIs in response to an HTTP 301, malicious open wireless hotspots or proxies would gain the ability to permanently re-link a user's bookmarks or application URLs, thus expanding the scope of phishing attacks. Because of these and other similar problems, the current default behavior of user-agents is to ignore the RFC and not re-link. While this behavior helps to avoid the issues described above, it also prevents the user-agent from taking full advantage of the redirect functionality as specified in the HTTP standard.
According to this disclosure, a URL update method is implemented in an HTTP-based client upon receipt by the client of an HTTP redirect in response to a request-URI. One or more references to the request-URI are saved in or in association with the client. Upon receipt of the HTTP redirect of a given type, the client automatically re-links the one or more stored references to the request-URI to one or more new references returned by the server (as identified in the HTTP redirect) when the redirect can be verified to originate from the application to which the client is attempting to connect. Preferably, the automatic re-linking is accomplished using a link editing capability for permanent (e.g., HTTP 301) redirects.
In operation, and upon receipt of a permanent redirect, a client user-agent that has been provisioned to implement the method determines whether the permanent redirect is authentic, i.e., whether it is received from the application to which the request-URI was directed. Preferably, this determination is made in one of several ways, e.g., evaluating whether the redirect is received in a trusted SSL connection, whether the redirect is received in a connection that, if not protected by SSL, is otherwise trusted (e.g., because the request-response is being carried out over a corporate network), or even whether a user has, upon receipt of the HTTP redirect, confirmed that re-linking should occur, or the like. In response to a determination that the permanent redirect is authentic, at least one reference (such as a URL identified in the HTTP redirect) is automatically updated at the client user-agent.
In an alternative embodiment, the above-described method is performed in an apparatus. In another alternative embodiment, the method is performed by a computer program product in a tangible computer readable storage medium for use in a data processing system. The computer program product holds computer program instructions which, when executed by the data processing system, perform the method.
The foregoing has outlined some of the more pertinent features of the invention. These features should be construed to be merely illustrative. Many other beneficial results can be attained by applying the disclosed invention in a different manner or by modifying the invention as will be described.
For a more complete understanding of the present invention and the advantages thereof, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which:
With reference now to the drawings and in particular with reference to
With reference now to the drawings,
In the depicted example, server 104 and server 106 are connected to network 102 along with storage unit 108. In addition, clients 110, 112, and 114 are also connected to network 102. These clients 110, 112, and 114 may be, for example, personal computers, network computers, or the like. In the depicted example, server 104 provides data, such as boot files, operating system images, and applications to the clients 110, 112, and 114. Clients 110, 112, and 114 are clients to server 104 in the depicted example. Distributed data processing system 100 may include additional servers, clients, and other devices not shown.
In the depicted example, distributed data processing system 100 is the Internet with network 102 representing a worldwide collection of networks and gateways that use the Transmission Control Protocol/Internet Protocol (TCP/IP) suite of protocols to communicate with one another. At the heart of the Internet is a backbone of high-speed data communication lines between major nodes or host computers, consisting of thousands of commercial, governmental, educational and other computer systems that route data and messages. Of course, the distributed data processing system 100 may also be implemented to include a number of different types of networks, such as for example, an intranet, a local area network (LAN), a wide area network (WAN), or the like. As stated above,
With reference now to
With reference now to
Processor unit 204 serves to execute instructions for software that may be loaded into memory 206. Processor unit 204 may be a set of one or more processors or may be a multi-processor core, depending on the particular implementation. Further, processor unit 204 may be implemented using one or more heterogeneous processor systems in which a main processor is present with secondary processors on a single chip. As another illustrative example, processor unit 204 may be a symmetric multi-processor (SMP) system containing multiple processors of the same type.
Memory 206 and persistent storage 208 are examples of storage devices. A storage device is any piece of hardware that is capable of storing information either on a temporary basis and/or a permanent basis. Memory 206, in these examples, may be, for example, a random access memory or any other suitable volatile or non-volatile storage device. Persistent storage 208 may take various forms depending on the particular implementation. For example, persistent storage 208 may contain one or more components or devices. For example, persistent storage 208 may be a hard drive, a flash memory, a rewritable optical disk, a rewritable magnetic tape, or some combination of the above. The media used by persistent storage 208 also may be removable. For example, a removable hard drive may be used for persistent storage 208.
Communications unit 210, in these examples, provides for communications with other data processing systems or devices. In these examples, communications unit 210 is a network interface card. Communications unit 210 may provide communications through the use of either or both physical and wireless communications links.
Input/output unit 212 allows for input and output of data with other devices that may be connected to data processing system 200. For example, input/output unit 212 may provide a connection for user input through a keyboard and mouse. Further, input/output unit 212 may send output to a printer. Display 214 provides a mechanism to display information to a user.
Instructions for the operating system and applications or programs are located on persistent storage 208. These instructions may be loaded into memory 206 for execution by processor unit 204. The processes of the different embodiments may be performed by processor unit 204 using computer implemented instructions, which may be located in a memory, such as memory 206. These instructions are referred to as program code, computer-usable program code, or computer-readable program code that may be read and executed by a processor in processor unit 204. The program code in the different embodiments may be embodied on different physical or tangible computer-readable media, such as memory 206 or persistent storage 208.
Program code 216 is located in a functional form on computer-readable media 218 that is selectively removable and may be loaded onto or transferred to data processing system 200 for execution by processor unit 204. Program code 216 and computer-readable media 218 form computer program product 220 in these examples. In one example, computer-readable media 218 may be in a tangible form, such as, for example, an optical or magnetic disc that is inserted or placed into a drive or other device that is part of persistent storage 208 for transfer onto a storage device, such as a hard drive that is part of persistent storage 208. In a tangible form, computer-readable media 218 also may take the form of a persistent storage, such as a hard drive, a thumb drive, or a flash memory that is connected to data processing system 200. The tangible form of computer-readable media 218 is also referred to as computer-recordable storage media. In some instances, computer-recordable media 218 may not be removable.
Alternatively, program code 216 may be transferred to data processing system 200 from computer-readable media 218 through a communications link to communications unit 210 and/or through a connection to input/output unit 212. The communications link and/or the connection may be physical or wireless in the illustrative examples. The computer-readable media also may take the form of non-tangible media, such as communications links or wireless transmissions containing the program code. The different components illustrated for data processing system 200 are not meant to provide architectural limitations to the manner in which different embodiments may be implemented. The different illustrative embodiments may be implemented in a data processing system including components in addition to or in place of those illustrated for data processing system 200. Other components shown in
In another example, a bus system may be used to implement communications fabric 202 and may be comprised of one or more buses, such as a system bus or an input/output bus. Of course, the bus system may be implemented using any suitable type of architecture that provides for a transfer of data between different components or devices attached to the bus system. Additionally, a communications unit may include one or more devices used to transmit and receive data, such as a modem or a network adapter. Further, a memory may be, for example, memory 206 or a cache such as found in an interface and memory controller hub that may be present in communications fabric 202.
Computer program code for carrying out operations of the present invention may be written in any combination of one or more programming languages, including an object-oriented programming language such as Java™, Smalltalk, C++ or the like, and conventional procedural programming languages, such as the “C” programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer, or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider).
Those of ordinary skill in the art will appreciate that the hardware in
As will be seen, the techniques described herein may operate in conjunction within the standard client-server paradigm such as illustrated in
With the above as background, the subject matter of this disclosure can now be described. In this context of this disclosure, it is assumed that browser-to-server communications may take place over a secure transport, such as SSL (or TLS, or equivalent) over TCP over IP. This transport is well-known in the art, and it creates an “https session” between the browser and the server. Familiarity with SSL/TLS transport is assumed. The techniques may be used with other secure transport protocols that implement certificate-based cipher suites.
According to this disclosure, when a user-agent that is provisioned with the above-described link editing capability receives an HTTP 301 permanent redirect, the user-agent automatically determines whether the response originates from the application to which the client is attempting to connect. If the user-agent can verify the authenticity of the HTTP redirect (i.e., it originates from the application to which the client is attempting to connect), one or more URLs are securely re-linked in associated with execution of the redirect itself. The secure re-linking is carried out using the native link-editing capability of the user-agent, or using separate software functionality (e.g., a plug-in, an applet, an ActiveX control, a script, or the like) that performs the link editing. The URL re-link may take place before, during or after the redirection, although preferably it occurs concurrently with the redirect. By re-linking in this secure manner, the user is assured that HTTP redirection achieves its intended purpose but does not otherwise interfere with saved URLs that are otherwise used by the user-agent (typically for other purposes). The technique is seamless and secure, and it ensures that the HTTP protocol suggestion to re-link references (RFC 2616, Section 10) can be carried out without the security and usability issues that have plagued this operation in the past.
When the browser establishes an HTTP or HTTPS connection to a target server application (step 400), the operation begins and, in particular, upon receipt by the browser of an HTTP redirect. As illustrated in
If, however, the outcome of the test at step 404 indicates that the redirect is a permanent one, the routine continues at step 412 to test whether the user-agent is enabled for the URL re-linking functionality. If the outcome of the test at step 412 indicates that the user-agent is not enabled to perform the automated re-linking function of this disclosure, the control branches to step 410 to perform the redirect. As before, after the redirect is performed, the routine ends at step 408.
If, however, the outcome of the test at step 412 indicates that the user-agent is enabled to perform the automated re-link functionality, the routine continues at step 414 to test whether current request and response are being carried out over SSL (Secure Sockets Layer). If the outcome of the test at step 414 indicates that the communication link itself is SSL-secured between the requesting client and the target server, then the server is trusted and the received HTTP redirect is considered to be authentic. Accordingly, control branches to step 416 to update one or more links in the browser cache (e.g., a bookmark, the URL for the server application, or the like). Typically, the one or more links that are updated are those that are associated with the Web application to which the HTTP request is directed, but this is not a requirement. At step 416, and in addition to update the one or more links to reflect the permanent redirect, the routine also performs the redirect itself. The routine then continues to step 408 and ends. Preferably, the one or more links are updated by the browser automatically and without further user input (or even active awareness).
While the existence of the SSL connection is one preferred way of determining that the HTTP response is authentic, the determination regarding authenticity of the HTTP redirect may be confirmed in other ways. To that end, if the outcome of the test at step 416 indicates that the communication link itself is not SSL-secured, a test is performed at step 418 to determine whether the communication is otherwise trusted. The HTTP redirect may be considered to have originated from a trustworthy source for one of many alternative reasons (other than being received via SSL), e.g., the client has been authenticated to the server via other means, the client recognizes the network address of the target server, the client recognizes the target server from the contents of an HTTP response header, the target server is associated with a given trusted domain (e.g., an enterprise or corporate network, as opposed to an open WiFi hotspot), or the like. Any such techniques may be implemented. If the outcome of the test at step 418 indicates that the HTTP redirect received is authentic (in other words, that the target server or the connection itself is trusted), then control returns to step 416. As noted above, at this step one or more links are updated and the redirect implemented.
If, however, the outcome of the test at step 418 still indicates that an insufficient proof of authenticity still exists, the routine branches to step 420. At this step the redirect (received at step 402) is implemented (as it must). The routine then branches to step 422 to issue a message to the user that a redirection is taking place; the message also provides a prompt to the user to query whether the user desires to re-link one or more URLs affected by the permanent redirection. Preferably, the message also provides the user with information about the risk of updating URLs. If the user answers in the affirmative, the routine continues at step 424 to test whether the requested re-linking should take place. Step 424 may by default be answered affirmatively, but it may also implement one or more conditions that have to be met before even the user-approved re-linking occurs. Thus, for example, step 424 may implement a security policy that includes at least one configurable condition that must be met before the user-approved re-linking occurs. This condition may be that the target server's domain is recognized in the security policy, that some temporal condition associated with the request is met, or the like. If the outcome of the test at step 424 indicates that the update should not occur, the routine branches to step 408 and terminates. If, however, the one or more condition(s) specified are met, the routine continues at step 426 to update the one or more links. The process then terminates at step 408.
Steps 414, 418 and 424 need not occur in any particular order or sequence. These steps may take place concurrently. Additional tests for determining authenticity of the HTTP redirect (or, in particular, authenticity of the target server that issued the user-agent the HTTP redirect) may be implemented as well.
A particular redirect that triggers the described functionality is sometimes referred to herein as “protocol-compliant” if it otherwise satisfies the requirements (e.g., syntax, content, style, etc.) required by the protocol.
A particular redirect may include one or more new references. Provided the redirect is verified to be authentic, any stored reference to the request-URI is then updated to each of the one or more new references according to the update techniques described herein.
The subject matter described herein has many advantages. The technique provides a mechanism to ensure that the HTTP protocol's suggestion to automatically re-link references is carried out seamlessly and reliability in those clients that include link-editing capabilities. As described, clients that implement the approach automatically update one or more URL references upon receipt of the HTTP 301 redirect. By restricting the URL reference updates to occur only upon receipt of an authentic HTTP redirect, the approach ensures that clients update the URL references safely and in a manner contemplated by the HTTP specification. As noted above, the preferred approach is to re-link one or more references to the request-URI to one or more new references returned by the server when the response can be verified to originate from the application to which the client is attempting to connect. As noted, if the user-agent can verify the authenticity of the HTTP redirect (i.e., it originates from the application to which the client is attempting to connect), one or more URLs are securely re-linked in associated with execution of the redirect itself. By re-linking in this secure manner, the user is assured that HTTP redirection achieves its intended purpose but does not otherwise interfere with saved URLs that are otherwise used by the user-agent (typically for other purposes). The technique is seamless and secure, and it ensures that the HTTP protocol suggestion to re-link references (RFC 2616, Section 10) is carried out without security and usability issues.
The functionality described above may be implemented as a standalone approach, e.g., a software-based function executed by a processor, or it may be available as a managed service (including as a web service via a SOAP/XML interface). The particular hardware and software implementation details described herein are merely for illustrative purposes are not meant to limit the scope of the described subject matter.
More generally, computing devices within the context of the disclosed subject matter are each a data processing system (such as shown in
The secure URL update scheme described herein may be implemented in conjunction with various server-side architectures including simple n-tier architectures, web portals, federated systems, and the like. The techniques herein may be practiced in association with a loosely-coupled server (including a “cloud”-based) environment. The server itself (that issues the redirect) may be hosted in the cloud.
The secure URL update for HTTP redirects may be implemented in any computing entity that acts as a “client” to another server; thus, the techniques herein are not limited for use for strictly client-side web browser software but may also be implemented, for example, in a server or intermediary process that itself is acting as a client (to some other server component).
Still more generally, the subject matter described herein can take the form of an entirely hardware embodiment, an entirely software embodiment or an embodiment containing both hardware and software elements. In a preferred embodiment, the function is implemented in software, which includes but is not limited to firmware, resident software, microcode, and the like. Furthermore, as noted above, the secure URL update functionality can take the form of a computer program product accessible from a computer-usable or computer-readable medium providing program code for use by or in connection with a computer or any instruction execution system. For the purposes of this description, a computer-usable or computer readable medium can be any apparatus that can contain or store the program for use by or in connection with the instruction execution system, apparatus, or device. The medium can be an electronic, magnetic, optical, electromagnetic, infrared, or a semiconductor system (or apparatus or device). Examples of a computer-readable medium include a semiconductor or solid state memory, magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk and an optical disk. Current examples of optical disks include compact disk-read only memory (CD-ROM), compact disk-read/write (CD-R/W) and DVD. The computer-readable medium is a tangible item.
The computer program product may be a product having program instructions (or program code) to implement one or more of the described functions. Those instructions or code may be stored in a computer readable storage medium in a data processing system after being downloaded over a network from a remote data processing system. Or, those instructions or code may be stored in a computer readable storage medium in a server data processing system and adapted to be downloaded over a network to a remote data processing system for use in a computer readable storage medium within the remote system.
In a representative embodiment, the cookie management components are implemented in a special purpose computer, preferably in software executed by one or more processors. The software is maintained in one or more data stores or memories associated with the one or more processors, and the software may be implemented as one or more computer programs. Collectively, this special-purpose hardware and software comprises managed cookie framework that provides single sign-off in a proxy.
The cookie function may be implemented as an adjunct or extension to an existing access manager or policy management solution.
While the above describes a particular order of operations performed by certain embodiments of the invention, it should be understood that such order is exemplary, as alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, or the like. References in the specification to a given embodiment indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic.
Finally, while given components of the system have been described separately, one of ordinary skill will appreciate that some of the functions may be combined or shared in given instructions, program sequences, code portions, and the like.
As used herein, the “client-side” application should be broadly construed to refer to an application, a page associated with that application, or some other resource or function invoked by a client-side request to the application. A “browser” as used herein is not intended to refer to any specific browser (e.g., Internet Explorer, Safari, FireFox, or the like), but should be broadly construed to refer to any client-side rendering engine that can access and display Internet-accessible resources. Further, while typically the client-server interactions occur using HTTP, this is not a limitation either. The client server interaction may be formatted to conform to the Simple Object Access Protocol (SOAP) and travel over HTTP (over the public Internet), FTP, or any other reliable transport mechanism (such as IBM® MQSeries® technologies and CORBA, for transport over an enterprise intranet) may be used. Also, the term “web site” or “service provider” should be broadly construed to cover a web site (a set of linked web pages), a domain at a given web site or server, a trust domain associated with a server or set of servers, or the like. A “service provider domain” may include a web site or a portion of a web site. Any application or functionality described herein may be implemented as native code, by providing hooks into another application, by facilitating use of the mechanism as a plug-in, by linking to the mechanism, and the like.
The techniques disclosed herein are not limited to a Web-based portal having a point of contact that provides authentication, session management and authorization, but this will be a typical implementation. As noted, the above-described function may be used in any system, device, portal, site, or the like wherein server-set session management data might be re-used (either by an original user in a different session, or by another user) through the same client browser. More generally, the described technique is designed for use in any operating environment wherein given information (including, without limitation, session management data) is not intended to persist across applications or sessions but ends up doing so because of patterns of client re-use and/or application-level granularity of session information.
The term “redirect” should be broadly construed to refer to the HTTP specification (RFC2616) or, more generally, any request-response protocol directive (including FTP, SMTP and others) that instructs a client side user-agent to look elsewhere for a requested resource.
