Improving Security in Web Sessions
Special Management of Cookies
Nicolás Macia and Fernando G. Tinetti, The National University of La Plata, La Plata, BA, Argentina
The current mechanism implemented for Web session management implies exchanging session cookies between a Web application client (usually a browser) and a Web application server. Besides having privacy issues, the security of Web sessions can be affected by various reasons related to cookies. There are several vulnerabilities that threaten a Web application specifically related to cookies: theft, tampering, and/or forgery. Any of these vulnerabilities may favor session theft and/or unauthorized access using the identity of another user in the system. In this chapter, we present an alternative technique for management of Web sessions, where no session cookies are sent to clients while maintaining backward compatibility. As a result, the proposed technique is shown to avoid several specific vulnerabilities that affect the security of Web application sessions and users. The proposed mechanism works transparently for Web applications, and a proof of concept was successfully tested with Web applications based on different languages such as Php, Perl, Ruby, and Python.
Keywords
Web session security; Web session management; OWASP; cookie management; Web privacy; Web server filters/modules
Information in this chapter
• Alternative proposal to enhance security and privacy of Web sessions avoiding cookies
• Experimental verification of the proposed mechanism for Web session management
Introduction
Since its inception, HTTP (HyperText Transfer Protocol) has been a protocol for the rapid distribution of information [1,2]. Through simple requirements-responses, the protocol provides access to text, images, audio, HTML (HyperText Markup Language), and other resources. The protocol was created following the premise of a stateless one, with individual requests for specific resources replied with concrete answers providing either the resource or an indication of failure. HTTP rapidly became established as the quintessential application protocol due to massive Internet use, and evolved to what is known today as the World Wide Web. Over time, the need for different types of Web applications emerged (shopping sites, Webmail sites, home banking, etc.), and with them the need for a mechanism that allows the management of user sessions. Up to that point, the stateless nature of the HTTP protocol made it almost impossible to associate several requests of a Web application to the single user that originated those requests.
In order to be able to implement Web applications as those described above, a mechanism for HTTP session management was developed [3]. This mechanism enabled Web applications to have what is known as user sessions or Web sessions. Web session management does not alter in any way the HTTP protocol, since the mechanism is based on the use of additional HTTP headers exchanged between the client browser and the Web application server to associate the request with a particular user/session. The first proposal that allowed HTTP sessions called “cookies” to this additionals headers. The term remained in future recommendations to the IETF (Internet Engineering Task Force), which were introduced in order to standardize the management of HTTP sessions [4–7]. Currently, the basic operation for the establishment of a Web session, when a user enters a particular site (i.e., makes a Web application request), can be explained as follows:
• The server sets a cookie and sends the cookie to the client in an HTTP header in the HTTP response.
• When the client receives the HTTP response, the client extracts the session cookie and stores it for the next HTTP requests to the same site.
• Every future requirement from the client to the previously visited site includes the stored HTTP cookie.
• The server is able to associate a request with a user session by inspecting the value of the header where the cookie is found.
Thus, the mechanism for Web session management enabled Web applications to set the association of a specific client with the requirements that the client has previously made. Basically, the use of cookies allowed for managing user sessions, which, in turn, allowed Web applications to authenticate users, authorize access to resources, and even to audit the actions performed by the users at the application level. However, cookies also introduced problems associated with security and user privacy [8,9]. Cookies could be stolen by different techniques, and other cookie-related issues in the development of Web applications further exposed the security of these types of applications and users. In this regard, note that when a cookie is stolen, it is possible to carry out session hijacking attacks, which can lead to identity theft attacks, denial of service, etc.
OWASP (Open Web Application Security Project) became a source of reference in different aspects of Web application security [10], and mainly focused on the development of secure Web applications. OWASP provides various guidelines for the safe development of Web applications, verification of Web application security, and code review, among others [11–14]. OWASP also provides another valuable resource to the Internet user community: a document called OWASP Top Ten Project, which describes the ten most dangerous security vulnerabilities in Web applications. The document was initially written in 2004 and was updated in 2007, 2010, and 2013 [15]. Many of the security problems identified by OWASP are related to the previously described session management via HTTP cookies.
We propose a new technique for Web session management, which transparently avoids exchanging HTTP cookies between a Web client and a Web server interconnection. Thus, there is no need for redesign or reimplementation of current Web applications to work under the proposed mechanism.
The rest of the chapter is organized as follows: The section titled “Related Work” introduces a summary related to session security, specifically focusing on cookie-related vulnerabilities; in “Proposed Mechanism for Web Session Management,” the proposal for the special management of cookies is conceptually explained; “Implementation and Experiments” details the proof of concept implementation as well as the experimentation results on some specific Web applications; ”Conclusions and Further Work” is devoted to conclusions and includes suggestions for future lines of research and work.
Related work
As explained above, the current mechanism for Web session management implies exchanging cookie/s between the client and the server of a Web application. Because of the very definition of the mechanism, the issue of user privacy was a topic of debate. The use of cookies and HTTP headers like Referer leads to situations where a third party is able to set up user profiles and determine, for a large set of users, which sites are visited by each of them, at what time of day, etc. Since the proposal for and creation of cookies, there have been several warnings published about a large loss of privacy, even from one of the authors of the RFC, which defined cookies as part of the HTTP headers for session management [8,9]. Besides the problems that cookies represent for user privacy, the security of Web applications can be affected by various problems, allowing for unauthorized access or identity fraud through manipulation or stolen cookies. Several Web session attacks are shown in [16], including those using SSL (Secure Sockets Layer), leading to the conclusion that (a) part of the problem is that HTTP is a stateless protocol, and (b) a solution would be to replace HTTP for something more suitable. Our approach does not include changing the protocol; it involves operating differently in order to avoid cookies while maintaining backward compatibility (i.e., no Web applications recoding/fixing).
OWASP has been working to enhance Web applications security in the current scenario of HTTP usage (including cookies). Also, OWASP explicitly identifies commercial initiatives working on Web security [17]. Several Web application security vulnerabilities included in OWASP Top Ten Project [15] are directly related to cookies, such as:
• “A2 Broken Authentication and Session Management,” which is possible once a session cookie has been stolen or by session fixation attacks [18]. The stolen cookie can be used to steal the complete session, which, in turn, allows a third party/user to act as the real/original user.
• “A3 Cross-Site Scripting,” or XSS, which allows stealing session cookies. Even if the HttpOnly attribute is used for cookies, another attack, XST (Cross-Site Tracing) [19], which can be considered as an XSS variant, allows stealing of cookies. The XST attack is possible only when the “harmless” HTTP Trace method is available. Enabling the HTTP Trace method could be considered as part of another OWASP top ten vulnerability: “A5 Security Misconfiguration.”
• “A6 Sensitive Data Exposure,” which also allows stealing session cookies. Some sites do not use SSL at all or use SSL only for exchanging user/password information, while all other data exchange is transferred as plain text. Non-encrypted data is easily recovered by means of sniffing techniques.
A summary of Web applications security actions/arrangements, taking into account [11–13] (specifically development and testing guides), can be done by different groups of people:
• Verify all application inputs in order to prevent XSS attacks (“A3 Cross-Site Scripting”).
• Implement several controls related to cookies that are specifically oriented to prevent “A2 Broken Authentication and Session Management,” such as:
• Set a short time for cookies to expire, or expire them when the browser is closed.
• Set the HttpOnly and Secure attributes to cookies.
• Set the proper Domain and Path attributes to cookies.
• Verify that every cookie maintains the same source IP.
• Invalidate cookies after ending a session.
• Always generate non-predictable cookies at the server side.
• Renew cookies after a user/application privilege level change.
• Use random tokens in order to avoid CSRF attacks: “A8 Cross-Site Request Forgery.”
• Web server managers/administrators:
• Disable dangerous HTTP methods: Trace, Connect, Delete, and Put, as suggested in OWASP Testing Guide (Put and Trace are the most dangerous).
• Always use HTTPS in sites requiring user authentication and sensitive data transfer (cookies are one of the sensitive data, most of the time) so to reduce “A6 Sensitive Data Exposure.”
• Perform security tests to find possible gaps in the system.
As expected, OWASP suggestions do not imply that a site must be absolutely free of security concerns the suggestions are to reduce the number of possible issues as well as increase the complexity of eventual security/privacy attacks.
Proposed mechanism for web session management
Given that Web session management can be defined as the capability of maintaining a record of the succession of requests a Web client (user) has made, the proposed mechanism is based on the association
in order to take advantage of the HTTP 1.1 keep-alive capabilities to persist the TCP connection used between Web client and server. The core of the proposed mechanism is the identification of a user session through the TCP connection, instead of the transfer of cookies set at the server side between client and server. The concept is not completely new; different application protocols transported over TCP, such as SSH, imap, pop, rdesktop, and so on, give meaning to the session while the corresponding TCP connection is established. If the TCP connection is interrupted, the session is lost or canceled. Two important problems have to be solved at this point:
• The proposed mechanism should be able to keep the state of a user/Web client session. The Web application has no way of determining whether successive requirements that come from the same TCP connection correspond to the same user a priori, since HTTP is a stateless protocol.
• The proposed mechanism should be transparent to existing Web applications. Currently, Web sessions are implemented as defined in RFC 6265. Although the proposed mechanism avoids cookie exchange with the client side, the Web application will maintain cookie usage (as coming from Web clients).
If these problems were solved, it would be possible to maintain backward compatibility with Web applications currently in production, as well as to avoid cookie/s exchange between Web clients and Web applications.
Conceptually, the proposed mechanism is based in a Web server filter/module capable of managing cookies so that:
• one HTTP session will be associated to the (client/server) TCP connection used at the transport layer.
• cookies are neither sent to nor received from Web clients. Instead, the filter module completely manages cookies.
• every cookie is associated with a Web client using its TCP connection to the Web server.
• the Web application software still receives the cookies as being sent by the Web client; that is, transparently.
Figure 29.1 shows schematically how the proposed scheme works, and in fact the proof of concept implemented and reported in this work follows exactly that description, taking advantage of the Apache Web server modular software architecture. Note that a cookie is necessary at the client side just to be returned in each following HTTP request (as described in RFC 6265), now the server replaces the usage of cookies by the TCP connection established by the client. However, given that current Web applications still use/need cookies at the server side, the intermediate filter in Figure 29.1 not only associates a persistent TCP connection to a Web session but also associates the persistent TCP connection to the corresponding cookie.
The cookie association with a persistent TCP connection is easily implemented by means of a database, as shown in Figure 29.1, which allows:
• the storage of cookies set by the server side, along with the corresponding persistent TCP connection.
• retrieval of the session cookie corresponding to a (persistent TCP connection) Web session by issuing a simple SQL query.
Note that the database stored at the server side is small: only data corresponding to open TCP connections have to be stored. Once a TCP connection is closed, the corresponding data is deleted from the database.
Specifically, the intermediate filter/module implementing the proposed Web session mechanism carries out very simple tasks on demand (for each HTTP request/response):
• When the Web application at the server side provides a response by setting a cookie, that cookie is stored in a local database by the filter/module. Data storage is minimal: each cookie and its corresponding persistent TCP connection, which is the TCP connection used to send the HTTP response, is stored. Also, the cookie is not included in the TCP response sent to the Web application client, since the Web application client (i.e., a browser) does not need the cookie.
• Every cookie is deleted from Web client requests; no cookies are used as received from Web clients. In this sense, there is no need to trust the client cookies, since every cookie is locally managed at the server side.
• Every Web client request generates a query on the local database, looking for cookies associated with the Web client persistent TCP connection. Every cookie provided by the database query is attached as part of the HTTP request headers sent to the Web application server. Thus, the Web application server receives the requests with the right cookies—those set by the server—which identifies user/Web session.
Clearly, several other adaptations/changes are also needed at the server side and in Web browsers for implementing client/user identification by its TCP connection.
• Adapt session time (usually a large one).
• Set the number of requirements received through a connection to a large one.
• At the client (Web browser) side:
• Set to 1 the number of simultaneous connections to the server.
The next section provides more details, as there are implementation-specific configurations/settings, depending on the Web server application and the browser, used at the Web client application side.
Implementation and experiments
As a proof of concept, the proposed mechanism has been implemented using Apache 2 HTTP server, taking into account its popularity (and its large market share of sites in production), efficiency, and extensibility. Clearly, Apache versatility has been one of the major reasons for its wide installation market share at the production level, and certainly its modular software architecture provides an excellent base for implementing proposals, such as the one in this work. More specifically, the filter/module was implemented as an Apache mod_perl.
At the client side, the Mozilla Firefox Web browser was used with various specific configuration details (non-default configuration). Other browsers were considered, but they were not used for various reasons:
• Google Chrome: the maximum number of simultaneous connections to the server is not configurable in this browser. Recall that the maximum number of TCP connections to the server should be 1.
• Opera: Despite being specifically configured for persistent HTTP 1.1 connections, this browser operates connections in a way similar to that expected by non-persistent connections in HTTP 1.0. It was found that the browser closes the connection and starts another one relatively soon. It was not found how to configure the browser to avoid this behavior.
As another part of the proof of concept, several Web applications were tested, taking into account several languages at the server side, as shown in Table 29.1.
Table 29.1
| Application | Version | Language |
| DVWA | 1.0.7 | Php |
| MediaWiki | 1.20.4 | Php |
| Wordpress | 3.5.1 | Php |
| Redmine | 2.3.1 | Ruby on Rails |
| Mailman | 2.1.15 | Python+C |
| Meran | 0.9.4 | Perl |
Web applications were selected to represent well known applications maintaining some language heterogeneity at server side. Also, the first application, DVWA, has been specifically included because of its well-known number of vulnerabilities, so that it is possible to verify that cookie-related ones are fixed.
Experimental environment
Different configurations were performed on the server and browser to enable persistent connections. The server runs on a Linux Debian Stable (Wheezy), installed with the advanced packaging system (apt command), package apache2-mpm-prefork, HTTP Server: Apache/2.2.22. Specific configuration options to allow persistent TCP sessions
/etc/apache2/apache2.conf include:
#
# KeepAlive: Whether or not to allow persistent connections (more than
# one request per connection). Set to "Off" to deactivate.
#
KeepAlive: On
#
# KeepAliveTimeout: Number of seconds to wait for the next request from the
# same client on the same connection. 10 minutes=600 seconds
#
KeepAliveTimeout: 600
#
# MaxKeepAliveRequests: The maximum number of requests to allow
# during a persistent connection. Set to 0 to allow an unlimited amount.
# We recommend you leave this number high, for maximum performance.
#
The client runs on a Linux Ubuntu 13.04 (Raring Ringtail), with Web browser Mozilla Firefox 22.0 installed with the ). Specific configuration options to allow persistent TCP sessions (about:config) were set to:
network.http.keep-alive.timeout 600
network.http.max-connections-per-server 1
network.http.max-persistent-connections-per-server 1
network.http.keep-alive true
network.http.pipelining true
network.http.use-cache false
Note that the configuration option “network.http.use-cache false” does not affect the connection persistence itself, but it is used in order to avoid testing on modified scenarios due to cache contents/state.
Results and application-specific details
In general, the Web applications shown in Table 29.1 were successfully tested; that is, there were no problems detected while it was used. It is worth noting that the Web browser was not changed (only specifically configured) and the Web application remained unchanged (with only one minor exception, explained below). The main (and only) problem identified in the experimentation phase is related to the browser-side behavior: close the persistent HTTP connection and open another one. While this is acceptable in the current HTTP definition, it completely broke the proposed Web session management, since a new connection implies a brand new Web session. Several Web browser and Web client issues have been identified:
• Firefox implementation of Ctrl-F5: Reloading a page without using a cache in Firefox causes the TCP connection to be regenerated (Firefox closes the current connection and opens a new one). This is clearly an issue related to the browser implementation, since it was found that another browser such as Google Chrome does not regenerate the connection every time the Ctrl-F5 sequence is entered.
• Browser cache: The browser cache threatens normal use of the proposed mechanism. A cached page could be the cause of a malfunction in a Web application. Refreshing all pages using the Ctrl-F5 sequence goes against the proposed mechanism because it causes the use of a new connection. It also makes the debugging tasks much more difficult.
• A 500 HTTP response error code: Every HTTP response type 500 implies the current session should be closed. This is not necessarily a problem, since it would be wise to reset the connection once the server has identified and reported a problem.
• Issues related to HTTP pipelining/pending requests: When too many requests are generated and pipelined, the persistent HTTP connection is reset abruptly and the browser generates a new connection, even though previous responses to previous requests are expected. Clearly, this was found as a result of several stress experiments and depends on the browser implementation details specifically related to HTTP pipelining.
• Large amounts of data: This item is probably related to the previous problem, but problems were found when a page requires a large data transfer from the server. More specifically, Meran has a configurable homepage that, by default, issues 37 requests, implying a total space of 1.6 MB. After setting and configuring the homepage, 34 requests were necessary, implying a total of 319 KB of space, and no more problems were found.
• DVWA hyperlinks different pages using simultaneously HTML <a> tag and javascript object “window.location” to the linked page, as in
<li onclick="window.location='...site here.../.?page=include.php'" class>
<a href="...SITE HERE.../.?PAGE=INCLUDE.PHP">File Inclusion</a>
</li>
which was changed to
<li class>
<a href="...SITE HERE.../.?PAGE=INCLUDE.PHP">File Inclusion</a>
</li>
and the application functionality and usability did not change at all.
Most of the problems are related to Web browser implementation choices and are expected to be easily solved. Some application-specific issues, such as that explained above in the context of the DVWA application, are not possible to guess in advance and should be analyzed carefully for each application. DVWA was not chosen because it is easily fixed, though. Performance details such as pipelining, delayed responses, or exchange of large amounts of data could affect the proposed mechanism, as reflected in the above comments and explanations.
In general, as a result of the tests, it was found that the proposed mechanism is immune to all security problems that could be introduced by non-enforcement of security policies provided by OWASP for safe management of user sessions [20]. On the other hand, OWASP policies for authentication management of a Web application [21] are equally useful in both the current mechanism and the proposed mechanism.
Conclusion and further work
It was proposed an alternative mechanism for web sessions management that does not require storage of cookies on browser-side. The proposed mechanism was successfully tested in a proof of concept on a set of Web applications based on different scripting languages. OWASP current security suggestions that should be taken into account (as explained above) by developers and server administrators would be reduced to: (1) prevent CSRF attacks and (2) use HTTPS connections. A browser using the proposed mechanism and specifically implemented for access to Web applications could help prevent CSRF problems on those Web applications. In the extreme scenario in which the World Wide Web uses only the proposed mechanism, there would be no issues about user privacy. However, despite being a utopian idea—that popular sites taking advantage of advertisement would use the proposed mechanism—this mechanism may be appropriate for home banking websites, as well as any other website that provides users access to critical functionality aor critical information.
To summarize, Web applications that use the proposed mechanism for session management would enhance security and privacy, since:
• no session cookies are stored at the client side, thus improving privacy. However, the proposed method does not solve every privacy issue since, for example, Referer usage would be almost forbidden or not used.
• all OWASP recommendations related to session management are not needed under the proposed mechanism.
• several vulnerabilities become harmless under the proposed method for session management:
• Broken authentication and session management:
• Web session stealing/tampering/denial of service would be possible only via the more difficult TCP connection stealing/tampering/denial of service. Notice that the use of secure protocols such as HTTPS makes stealing and tampering practically impossible.
There are several future lines of work, some related to current Web application analysis (checking for backward compatibility) and others related to client-side enhancements with respect to the use of different Web browsers. Since Web applications are now so heterogeneous, possibly including RIA (Rich Internet Applications), the analysis of the proposed techniques as a case-by-case job would be too complex. Several tests should be defined and done almost automatically so as to reduce such complexity. At the client side, it would be possible to implement a proxy that enables the use of any browser for Web access. Such a proxy should maintain only one connection with the server while it accepts requests of any Web browser on one or multiple (TCP) connections. If two or more users request access to the same Web application, the proxy should open one connection to the server for every user. If requests come from a NAT network, it could be useful to configure user authentication.
References
1. Fielding R, Gettys J, Mogul J, Frystyk H, Masinter L, Leach P, et al. RFC 2616–Hypertext transfer protocol–HTTP/1.1; 1999.
2. W3C. Http-Hypertext transfer protocol. [Internet]. Retrieved from: <http://www.w3.org/Protocols/>; [accessed 06.13].
3. Netscape. Persistent client state-http cookies. [Internet]. Retrieved from: <http://curl.haxx.se/rfc/cookie_spec.html>; [accessed 06.13].
4. Kristol D, Montulli L. RFC 2109-Http state management mechanism. 1997.
5. Moore K, Freed N. RFC 2964-Use of http state management. 2000.
6. Kristol D, Montulli L. RFC 2965-Http state management mechanism. 2000.
7. Barth A. RFC 6265-Http state management mechanism. 2011.
8. Schwartz J. Giving Web a memory cost its users privacy. The New York Times. [Internet]. Available at: <http://www.nytimes.com/2001/09/04/business/giving-web-a-memory-cost-its-users-privacy.html>; 2001 [accessed 06.13].
9. Kristol DM. Http cookies: Standards, privacy, and politics. ACM Transactions on Internet Technology (TOIT). 2001;1(2):151–198.
10. OWASP. The open web application security project. [Internet]. Retrieved from: <http://www.owasp.org>; [accessed 06.13].
11. OWASP. OWASP guide project. [Internet]. Retrieved from: <http://www.owasp.org/index.php/Category:OWASP_Guide_Project>; [accessed 06.13].
12. OWASP. OWASP testing project. [Internet]. Retrieved from: <http://www.owasp.org/index.php/Category:OWASP_Testing_Project>; [accessed 06.13].
13. OWASP. OWASP code review project. [Internet]. Retrieved from: <http://www.owasp.org/index.php/Category:OWASP_Code_Review_Project>; [accessed 06.13].
14. OWASP. Cheat sheets. [Internet]. Retrieved from: <https://www.owasp.org/index.php/Cheat_Sheets>; [accessed 06.13].
15. OWASP. OWASP top ten project. [Internet]. Retrieved from: <http://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project>; [accessed 06.13].
16. Böck J. Session-Cookies and SSL. Study research project at the EISS (European Institute for system security). [Internet]. Available at: <http://blog.hboeck.de/uploads/ssl-cookies.pdf>; 2008 [accessed 06.13].
17. OWASP. OWASP testing project, appendix A: Testing tools. [Internet]. Retrieved from: <https://www.owasp.org/index.php/Appendix_A:_Testing_Tools#Commercial_Black_Box_Testing_tools>; [accessed 06.13].
18. OWASP. Session fixation. [Internet]. Retrieved from: <https://www.owasp.org/index.php/Session_fixation>.
19. OWASP. Cross site tracing. [Internet]. Retrieved from: <https://www.owasp.org/index.php/Cross_Site_Tracing>.
20. OWASP. Session management cheat sheet. [Internet]. Retrieved from: <https://www.owasp.org/index.php/Session_Management_Cheat_Sheet>.
21. OWASP. Authentication cheat sheet. [Internet]. Retrieved from: <https://www.owasp.org/index.php/Authentication_Cheat_Sheet>.