HTTP session validation module

A web server receives a packet including a web request from a browser of a client. The request includes a session cookie comprising a client token and a session identifier. A secret session token is calculated based on the session identifier and header data that includes data from one or more packet header fields. The web request is processed if the secret session token matches the client token and blocked otherwise. Determining the secret session token may include hashing the session identifier, at least a portion of a user agent string included in a user agent header of the web request, and at least a portion of a source IP address included in an IP header of the packet. The secret session token may have been provided to the client as a session cookie included in a response to an initial web request from the client.

TECHNICAL FIELD

The present disclosure generally relates to Internet security and, more specifically, methods and systems for validating requests received by a Web server.

BACKGROUND

Information handling systems that communicate via the Internet raise a number of security concerns. One particular practice that raises security concerns is the use of Session IDs by HTTP-based applications. Because HTTP is a stateless protocol, any information required by the recipient of an HTTP request must be either included in the request itself, maintained by the recipient, or provided to the recipient outside of the request itself.

SUMMARY

Disclosed subject matter improves/addresses security risks associated with session identifiers (session IDs).

In accordance with disclosed subject matter, an information handling system configured with web server functionality receives a network packet, e.g., an IP packet, including an HTTP-compliant request, sometimes referred to herein simply as a web request, from a client web browser. The web request includes or otherwise indicates a token and a session ID, which may be referred to as the request token and request session ID respectively. The information handling system may generate, calculate, or otherwise determine a secret session token (SST) based on the request session ID and header data. The header data includes data from one or more header fields included in any one or more of: an IP header, a transport layer header, an HTTP header, and/or another suitable header of the web request. If a session validation feature of the web server is enabled, information handling system processes the web request if and only if the SST calculated based on the header data matches the request token provided with the web request. If the SST and the request token fail to match, the web server blocks or otherwise declines to process the web request.

Determining the SST may include performing a hash function or hash algorithm using some or all of: a session ID, a user agent string included in a user agent field of an HTTP header for the web request, and a source IP address included in an IP header of the packet. The SST may have been provided to the client as a session cookie included in a response to an initial web request from the client.

In accordance with further disclosed subject matter, a web server includes a processor, a network interface suitable for coupling the web server to the Internet or another suitable network, and a software in the form of a computer readable medium including processor executable instructions. The software, when executed by the processor, causes the processor to perform particular operations.

The particular operations performed by the web server may include, responsive to receiving an initial request from a web client, extracting from the request one or more data items indicative of a source of the initial request, and generating a session ID corresponding to the request. An SST is generated, based on the data items and the session ID, and a response to the initial request is sent, wherein the response includes the session ID and the SST, e.g., within a set-cookie field of an HTTP header of the response.

Upon subsequently receiving an in-session request, i.e., a web request that includes a session ID, purportedly from the same client web browser and/or associated with the same HTTP session, the web server processes the request only after validating a session ID included in the request by calculating an SST based on the request and verifying that the calculated SST matches a token included with the request.

If session validation is enabled, the request is processed if and only if the token included in the request matches the calculated SST. If session validation is disabled, the web server may, in some embodiments, continue to calculate SSTs, albeit without blocking any requests based on a token mismatch. In other embodiments, the web server may be configured not to calculate token values when session validation is disabled.

The client token included in the in-session request may be included as a cookie, e.g., within a cookie field of an HTTP header of the in-session request. The web server may distinguish initial requests from in-session requests based on the presence or absence of a session ID within the request and/or the presence or absence of a session cookie, i.e., a cookie that does not specify a duration. Accordingly, an initial request may be referred to herein as a pre-session request, which may include any request sent from a browser to a server before a session ID is established between the browser and server. The pre-session request may be a hypertext transfer protocol (HTTP) GET request, or another type of HTTP request, encapsulated in an IP packet.

The data items extracted from the pre-session request may include a first data item and a second data item. The first data item may identify any one or more attributes of the pre-session request including the client browser, client operating system, client browser author or vendor, and client browser revision. The first data item may include all or a portion of user agent data included in a user agent header field of the pre-session request.

The second data item may include some or all of a source IP address included in an IP header of the IP packet. In at least one embodiment, a network portion of the source IP address may be used as the second data item, i.e., a portion of the IP address that does not vary among different requests within a given session. This portion may comprise the upper or most significant 16 bits of a 32-bit IP (v4) address. Thus, generating the SST may include performing a hash of the network portion of the source IP address, the user agent data, and the session ID.

The token generation and verification functionality may be implemented in a session validation module

The above summary is not intended as a comprehensive description of the claimed subject matter but, rather, is intended to provide an overview of the applicable subject matter. Other methods, systems, software, functionality, features and advantages of the claimed subject matter will be or will become apparent to one with skill in the art upon examination of the following figures and detailed written description.

DETAILED DESCRIPTION

References within the specification to “one embodiment,” “an embodiment,” “at least one embodiment”, or “some embodiments” and the like indicate that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the present disclosure. The appearance of such phrases in various places within the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Further, various features are described which may be exhibited by some embodiments and not by others. Similarly, various requirements are described which may be requirements for some embodiments but not for other embodiments.

Sessions and Session IDs are commonly used by Web-servers and other HTTP based applications to maintain state information pertaining to the client-side user. A session ID or token binds user authentication credentials to requests and responses exchanged within the applicable session.

FIG. 1illustrates stages and elements of a typical HTTP session implementation10. The implementation10includes pre-authentication (block12), wherein the web server assigns a unique identifier, referred to as a session ID or session ID, to an anonymous user issuing requests from a particular instance of a web browser. Once a session ID is established, the session ID may be included within each in-session request and response that is part of the session. If the user provides a userID and password or another form of authentication (block14) to the web server, the web server may perform session management (block16) including updating the session ID to reflect authentication credentials and access control details (block18), until the session is ultimately closed or otherwise finalized (block20), e.g., when the user closes the browser.

Session IDs may be communicated in various ways such as by manipulating the uniform resource locator (URL) indicated in requests and responses, via a cookie that is identified by a request or response, as an argument in the body of a request, e.g., a POST request, within a hidden form field, and so forth in ways that will be familiar to those of ordinary skill in the art.

Responsibility for implementing and securely binding the authentication, session management and access control components illustrated inFIG. 1lies primarily with the application developer because applicable development and deployment frameworks may not specify strict relationships. At least in part because application developers may vary in their experience with respect to implementing session IDs, Session IDs present an attractive target for attackers, who, after obtaining a Session ID surreptitiously, may hijack the user's identity and the applicable session.

Known techniques for obtaining session IDs include: session brute forcing, i.e., guessing; session hijacking or stealing, and session fixation; finger printing of session ID names used by the most common web application development frameworks including, as example, PHPSESSIONID, JSESSIONID (JSEE), CFID & CFTOKEN (Coldfusion), ASP.NET_SessioniID (ASP .NET); web traffic interception and manipulation including the use of Man-in-the-Middle/Browser-in-the-Middle attacks of unencrypted HTTP traffic to add or replace legitimate session IDs; reading HTTP meta tags (cookies), which HTTP may be unable to disable; the use of Web references or links that entice users to follow a link with the attacker's session ID; Cross-Site Scripting (XSS) that sets a session ID through JavaScript; exploiting the concept of Used vs. Accepted Sessions, for example, a web application that makes use of cookies as its default session ID exchange mechanism, may still accept other exchange mechanisms; and not renewing a session ID once authentication is completed.

Disclosed techniques and practices for preventing session hijacking may leverage and/or supplement one or more existing practices including, as non-limiting examples: requiring sensitive data be sent over HTTPS and preventing applications from accessing sensitive data via HTTP; the use of “secure” cookies and the exchange of session IDs via encrypted channels only; setting an HTTP13only attribute for each cookie, which instructs browsers not to allow JavaScript, VB script, or any other method that accesses cookies via a Document Object Model (DOM) document.cookie object; limiting session ID exchanges to cookies and prohibit URL-based and other session ID exchange mechanisms; prohibiting or discoursing persistent cookies, which may have a lifetime of 10 years; requiring strict session ID and prohibiting permissive mechanisms that allow a web application to initially accept any session ID value set by the user as valid, e.g., accepting only those session ID values generated by the web application; defining and implementing appropriate session expiration policies including manual automatic expiration policies; web cache controls that reduce the possibility of inadvertently recording private or sensitive data in a web browser cache; and disabling browser cross-tab sessions by forcing the web browser not to share a session ID simultaneously between two or more tabs or windows, a technique that may not be feasible or practical for web applications that employ cookies as the session exchange mechanism because cookies may be shared by all browser windows.

Existing efforts to combat session ID hijacking may emphasize the transport protocol. Authorized use of HTTPS (SSL/HTTPS) involves annual service and certificate costs. In addition, the existing approaches to combat session hijacking may rely on the efforts and diligence of application developers, who may have little experience, desire, and/or incentive to devote resources to session management. For example, the application developer may be free to decide which security measures are implemented, how frequently or consistently measures are enforced, e.g., for every web page served, every time a cookie is defined, every time a URL includes or indicates session ID, etc. In addition, the application developer may be responsible for ensuring that new session IDs are renewed and/or created after successful authentications.

The application development framework may not enforce a strict relationship among the applicable session components of an application. While Web servers may include their own Session modules, web servers may lack a well-adapted mechanism/module to validate the Session IDs included within a request, instead often purely depending on the HTTPS protocol and the application owner to ensure security.

Disclosed subject matter encompasses a web server that includes a session validation module (SVM) configured to continuously monitor a Session ID for each and every user request submitted within the applicable session.

If suspicious activity is detected, the SVM may block the request. The disclosed solution raises the security bar for the attacker and makes it harder for an attacker to perform a successful attack. A disclosed web server may implement a setting or feature to easily enable or disable the SVM that permits administrators to enable/disable SVM for their web application.

FIG. 2illustrates a web session in which a client web browser101sends a request(e.g., GET example.com), referred to herein as pre-session request111, to web server102. As suggested by its name, pre-session request111represents a request, from client web browser101to web server102, that does not include a session cookie or other indicator of a session ID associated with web server102. A pre-session request may correspond to the first request sent from the client web browser to the applicable web server after the client web browser is opened or otherwise instantiated on the client device.

Upon receiving pre-session request111from client web browser101, web server102generates (block104) a session ID112uniquely associated with client web browser101and sends client web browser101a response113that includes the session ID112. As suggested previously, however, the session ID112within response113is vulnerable to detection by an authorized browser or other resource.

FIG. 3illustrates the web session illustrated inFIG. 2at a subsequent point in time. As illustrated inFIG. 3, a miscreant114has devised to sniff (operation115) or otherwise illicitly obtain session ID112from response113. Miscreant114is further illustrated sending a rogue request122to web server102wherein the rogue request122includes or otherwise indicates session ID112. Because web server102has associated session ID112with client web browser101, web server102may process rogue request122as it would process a valid in-session request from client web browser101. The hijacking of the client web server's session by miscreant114is complete when web server102responds to rogue request122by sending hijacked response123to miscreant114.

Turning now toFIG. 4AandFIG. 4B, the client web browser101ofFIG. 2andFIG. 3is illustrated communicating with a web server referred to herein as session-validating web server401. The session-validating web server401illustrated inFIG. 4AandFIG. 4Bincludes a front end, comprising a session validation module404that includes a an SST generator424, a backend comprising a session state module402that includes a session ID generator422, and an HTTP engine405that processes HTTP requests and generates HTTP responses.

In at least one embodiment, session state module402may support functionality substantially similar to the functionality supported by web server102(FIG. 2). In any such embodiment, session validation module404may represent the bulk of functional distinctions between web server102(FIG. 2) and session-validating web server401(FIG. 4A/4B).

As depicted inFIG. 4A, session-validating web server401responds to receiving pre-session request111from client web server101by returning a response413that includes a tokenized session ID412. The tokenized session ID412illustrated inFIG. 4AandFIG. 4Bcomprises a simple concatenation of session ID112and SST414. In other embodiments, however, tokenized session ID412may be the product of a more elaborate function of session ID112and SST414.

In at least some embodiments, SST414is derived from information that is: (a) indicative of and/or associated with client web browser101and (b) conveyed to session-validating web server401within pre-session request111. In these embodiments, the inclusion of SST414beneficially enables a session validation that is inherently and highly selective of the client web browser101.

Referring toFIG. 5, selected elements of the session validation module404ofFIG. 4AandFIG. 4Bare illustrated in context with an in-session request121. In-session request121is depicted as an HTTP request540encapsulated in an IP packet510. IP packet510includes an IP header520, a transport header530, and the HTTP request540. HTTP request540includes an HTTP header550and an HTTP payload560.

The IP header520includes a source IP address field521that stores an IP address of the information handling resource that sourced in-session request121, which may be an IP address associated with client web browser101. The HTTP header550illustrated inFIG. 5includes a User agent header field551that includes a user agent string identifying one or more attributes of the client web browser101(FIG. 1) and/or an information handling system in which client web browser101is implemented.

The SST generator424illustrated inFIG. 5includes a hash function module502that receives SST inputs504-1through504-3and produces SST414as an output. The three SST inputs504illustrated inFIG. 5include a first SST input504-1corresponding to session ID112. The second SST input504-2illustrated inFIG. 5comprises information included in or derived from source IP address field521in IP header520of IP packet510. The third SST input504-3illustrated inFIG. 5includes user agent information included in or derived from user agent field551in HTTP header550of HTTP request540.

Incorporating source-indicative information, such as the SST inputs504provided to SST generator424, beneficially produces an SST414that only validates in-session requests that originate from the same client web browser instance that sent the pre-session request111.

In addition, it will be appreciated that no modification of client web browser101is mandated by the introduction of session validation web server401. If, as an example, session ID112and SST414are communicated via cookie fields within in-session requests and responses, the validating performed by session-validating web server401may be entirely transparent to client web browser101.

The SST414generated by hash function module502may serve two purposes. As previously described, an SST414may be included in a response to a web request from session-validating web server401and stored as a cookie on client web browser101for use in subsequent in-session web requests. In addition, however, an SST414may be generated, based on an in-session web request121, by hash function module502for comparison with a request token505included in a cookie header field552of the in-session request121.FIG. 5illustrates token comparator506configured to perform this comparison and to assert its output507responsive to detecting a match between the SST414and the request token505. Accordingly, in such embodiments, token comparator506is configured to assert comparator output507to indicate validation of the request token505included with in-session request121.

In at least some embodiments, session-validating web server401may be implemented with a validation enable feature that provides a simple mechanism for enabling and disabling session validation. As illustrated inFIG. 5, for example, a session validation enable feature is implemented with token comparator506, validation enable switch512, and multiplexer508. As implemented inFIG. 5, these resources generate a process request signal509that is provided to HTTP engine405(FIG. 4). In at least one embodiment, process request signal509is asserted to a logical “1” to enable processing of the applicable web request by HTTP engine405. When process request signal509is maintained at logical “0,” HTTP engine405may be disabled or otherwise prevented from processing web requests.

Validation enable switch512illustrated inFIG. 5provides a control signal514to a control input of multiplexer508. Control signal514couples either the “A” input or the “B” input of multiplexer508to the output signal509. The “A” input illustrated inFIG. 5is illustrated toed to a logical “1.” The “B” input illustrated inFIG. 6is connected to the comparator output signal507, which indicates whether a token provided in an in-session web request successfully validates the web request.

Session validation may be disabled by toggling validation enable switch512until control input514couples the “A” input of multiplexer508to process request signal509. Session validation may be enabled by toggling validation enable switch512until control signal514couples the “B” input of multiplexer508to process request signal509. When the “B” input of multiplexer508is coupled to process request signal509, process request signal509follows comparator output signal507. Thus, with session validation enabled, the process request signal509is asserted, thereby enabling HTTP engine405to process the applicable HTTP request. The selection of logical “1” as the signal level enabling session validation is arbitrary and other embodiments may use logical “0” to enable session validation. Similarly, althoughFIG. 5illustrates particular logic, devices, or other resources, other embodiments may employ different logic, devices, and resources to achieve the same or similar functionality.

FIG. 6illustrates an HTTP session management method600. Method600may correspond to methods performed by a web server such as the session validation web server401(FIG. 4). The method600illustrated inFIG. 6includes receiving (operation602) a packet comprising a web request from a web client, wherein the web request includes a client token and a session identifier and determining (operation604), based on the session identifier and header data comprising data from one or more header fields of the packet, a secret session token for the web request. The web request may be processed (operation606) responsive to the secret session token matching the client token and the web request may be blocked (operation608) responsive to the secret session token not matching the client token.

Any one or more processes or methods described above, including processes and methods associated with any flow diagrams, may be embodied as a computer readable storage medium or, more simply, a computer readable medium including processor-executable program instructions, also referred to as program code or software, that, when executed by the processor, cause the processor to perform or otherwise results in the performance of the applicable operations.

A computer readable medium, which may also be referred to as computer readable memory or computer readable storage, encompasses volatile and non-volatile media, memory, and storage, whether programmable or not, whether randomly accessible or not, and whether implemented in a semiconductor, ferro-magnetic, optical, organic, or other suitable medium. Information handling systems may include two or more different types of computer readable medium and, in such systems, program code may be stored, in whole or in part, in two or more different types of computer readable medium.

Unless indicated otherwise, operational elements of illustrated or described methods may be combined, performed simultaneously, or performed in a different order than illustrated or described. In this regard, use of the terms first, second, etc. does not necessarily denote any order, importance, or preference, but may instead merely distinguish two or more distinct elements.

Program code for effecting described operations may be written in any appropriate combination of programming languages and encompasses human readable program code including source code as well as machine readable code including object code. Program code may be executed by a general purpose processor, a special purpose processor, including, as non-limiting examples, a graphics processor, a service processor, or an embedded processor or controller.

Disclosed subject matter may be implemented in any appropriate combination of software, firmware, and hardware. Terms including circuit(s), chip(s), processor(s), device(s), computer(s), desktop(s), laptop(s), system(s), and network(s) suggest at least some hardware or structural element(s), but may encompass non-transient intangible elements including program instruction(s) and one or more data structures including one or more databases.

While the disclosure has been described with reference to exemplary embodiments, it will be understood by those skilled in the art that the disclosure encompasses various changes and equivalents substituted for elements. Therefore, the disclosure is not limited to the particular embodiments expressly disclosed, but encompasses all embodiments falling within the scope of the appended claims.

As used herein, the singular forms “a”, “an” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will be further understood that the terms “comprises” and/or “comprising,” when used in this specification indicates the presence of stated features, operations, elements, and/or components, but does not preclude the presence or addition of one or more other features, operations, elements, components, and/or groups thereof.