Session Management Vulnerabilities in Today's Web - IEEE Xplore

Session Management Attacks

Session Management Vulnerabilities in Today’s Web Many

cyberattacks

exploit

session

management

vulnerabilities that allow attackers to be recognized as valid website users. This article describes Web application design flaws that could be exploited for session management attacks and discusses these flaws’ current prevalence. Corrado A aron Visaggio University of Sannio Lorenzo Convertito Blasio Progesi

48

C

enzic has estimated that 82 percent of Web technology vulnerabilities relate to Web applications and that 34 percent of major Web application vulnerabilities affect session management mechanisms.1 Hijacking a Web navigation session is one of the most studied kinds of attacks. Recently, Christopher Soghoian and Sid Stamm discovered a vulnerability that lets government agencies compel a certification authority to issue a false certificate for covertly intercepting and hijacking individuals’ secure communications through a Secure Sockets Layer (SSL).2 Soghoian and Stamm claim that at least one company produces network applications specifically designed to intercept SSL communications using compelled certificates. The Open Web Application Security Project (OWASP) includes session management vulnerabilities in the top 10 Web application vulnerabilities of 2010.3 OWASP concisely defines session management attacks: “Account credentials and tokens are often not properly protected. Attackers compromise passwords, keys, or authentication tokens to assume other users’ identities.” Here we provide a comprehensive, but not exhaustive, reasoned overview of some types of session management vulnerabilities. We also assess a sample of significant Italian Web applications to address two questions. First, how critical is session management vulnerability in terms of prevalence and severity? Second, are some vulnerabilities more prevalent than others? (Please see the “Session Management Tools for Security Assessment” sidebar for information on tools that check the security of session management.)

Session Management Session management tracks a user’s activity across sessions of interaction with a website. Its most widespread use is login, but it’s also used when the user isn’t required to log in, as in the case of many e-­ commerce websites or Web-based social networks. The typical way to implement it is to associate each user with a unique identifier—the session ID or session token. Token implementation typically employs one of these mechanisms: • Tokens are stored in cookies. • Tokens are sent in hidden fields of a specific form on the website. • Tokens, once created by the server, are added to each link the user clicks on. Session management also employs other mechanisms. For example, some applications use HTTP authentication (basic, digest, or NT LAN Manager). The browser could use the HTTP header, rather than the application’s Web page code, to send user credentials. This kind of authentication isn’t common. Other applications exploit sessionless mechanisms; in other words, they don’t use tokens but send the user’s dataset with each server interaction. Usually, this mechanism is used in conjunction with cryptographic algorithms.

Vulnerabilities The main vulnerabilities concern token generation and session management mechanisms.

COPUBLISHED BY THE IEEE COMPUTER AND RELIABILITY SOCIETIES ■ 1540-7993/10/$26.00 © 2010 IEEE ■ SEPTEMBER/OCTOBER 2010

Session Management Attacks

Session Management Tools for Security Assessment

T

o our knowledge, no tools support the overall process for detecting the session management vulnerabilities described in the main article. Here, we briefly discuss the three most representative tools for security assessment. Rapid7’s NeXspose (www.rapid7.com/products/metasploit.jsp) is a platform for assessing Web application vulnerabilities; it focuses on a set of vulnerabilities as well as SQL injection and cross-site scripting. Its distinctive feature is that it can analyze JavaScript, Ajax, and Flash applications. It realizes pen tests by executing attacks taken from a repository of exploits. EEye (www.eeye.com/Home.aspx) analyzes a website’s structure, content, and resources to find vulnerabilities. It focuses on localizing sources of vulnerabilities such as forms, cookies, scripts, SQL strings and Open Database Connectivity connectors, authentication, applets or objects, and hidden fields. In this way, it can find weaknesses such as input validation, poor coding practices, and weak configuration management. Nessus (www.nessus.org/nessus) is a scanner for security policy assessment with some features for Web application security, but it doesn’t focus on session management.

Token Generation This kind of vulnerability lets attackers generate and use a valid token. Tokens can be created by composing some pieces of user information, such as a username or e-mail address.4 If these schemas are reversible, an attacker could decode the token and create a valid one. Alternatively, tokens might be elements of an alphanumeric sequence, with the requirement that each token be as random as possible. Attackers can predict tokens with higher probability when the token-creating algorithm uses one of three strategies. Hidden sequences generates tokens by coding a normal sequence of numbers. In time dependences, tokens are a function of the generation time. The third strategy is the weak generation algorithm. Computers can’t provide true randomness because their operation is based on deterministic mechanisms. To overcome this, they employ pseudorandom number generators (PRNGs).5 PRNGs are created by merging different high-entropy sources, such as audio board output and the number of mouse clicks.

Session Management Mechanisms Even if a token is properly generated and unpredictable, attackers could intercept it. They can do this by exploiting unencrypted transmissions or weak mechanisms for preserving the cryptographic keys that a website uses to generate tokens. Another way to intercept tokens is by detecting them from log files, such as browser logs, Web server logs, and server proxy logs. If the token is passed as a URL parameter, an attacker can read it on the log. Yet another way is to find tokens in a browser or proxy cache, which can record the entire webpage and the response header. Other ways include exploiting faulty mechanisms used to assign tokens, assigning multiple tokens to the same user, and using static tokens for each user. Additionally, poor session termination policies

create many opportunities for attack. To reduce the temporal window for attacks, the session should be as short as possible. Some applications provide no mechanism for a session’s expiration, which enables attackers to try many values before the session expires. When a user logs out, the server removes that token from the user’s browser, but if the user (or attacker) sends a previously used token, the server keeps accepting it. In the worst case, the server receives no request at logout and doesn’t invalidate the session. If an attacker obtains this token, the attacker could use the session, just as the user who never logged out could. Finally, if the token is captured in a cookie, cookie parameter settings might contain other vulnerabilities. If a cookie doesn’t have the secure flag set, the cookie will be sent in unencrypted transmissions. If the HTTPOnly flag isn’t set, attackers can catch it through cross-site scripting (XSS) attacks. Attackers could also exploit a cookie’s scope. For example, if an application related to exp.testsite.com sends a cookie, the cookie is valid for each subdomain but not for the parent domain (in other words, testsite.com). By setting the domain flag, the designer of a Web application can define the cookie’s scope, in which case, if the domain isn’t properly set, attackers could exploit vulnerable applications in subdomains to intercept the token. Other vulnerabilities concern an improper use of HTTPS. First, some applications identify protected areas that use HTTPS but use the same token outside the protected area. So, attackers can obtain the token by intercepting HTTP transmissions. Second, some applications allow HTTP connections even in protected areas, where HTTPS should be used. So, attackers can induce users to make an HTTP request and then steal the token. Such attacks commonly use phishing mails, banners, or social engineering. Finally, some applications use an HTTP connection to access static content as well as images, scripts, and Cascading Style Sheets. Attackers can capture ­tokens by intercepting these requests. www.computer.org/security

49

Session Management Attacks

Possible Attacks By exploiting the vulnerabilities we just described, attackers can perpetrate attacks such as session sniffing, session prediction, session fixation, cross-site request forgery (CSRF), and HTTP response splitting. For each attack, we describe the enabling vulnerabilities, which attackers must verify before attacking.

Session Sniffing These attacks consist of passively intercepting a session’s data set that’s being transmitted. HTTP packet sniffing. This attack intercepts HTTP

packets. Attackers must locate a sniffer in a machine in the network of the victim or the organization responsible for the Web application. There are four enabling vulnerabilities. First, the area of the website that doesn’t use HTTPS is identifiable. Second, the secure flag isn’t set. Third, the application allows HTTP requests for pages under HTTPS. Finally, the application uses HTTP before authentication. Log sniffing. This attack obtains the token by analyz-

ing log files in the different systems involved in clientserver communication. There are two enabling vulnerabilities. First, the token is transmitted as a URL parameter, in which case it might be recorded in the log files. Second, the token is transmitted as a hidden field, and the server accepts GET requests in place of POST requests. Such a request inversion could be realized by a client-side script. The token will be sent as a URL parameter and could be read in the log file. Cache sniffing. If the attacker accesses the browser or

proxy cache, the attacker could obtain the token in any format containing it (cookie, URL parameter, or hidden field). The two enabling vulnerabilities refer to how the Web application manages the cache. First, directives (Expires:0 and Cache-control:max-age=0 or Cache-Control:no-cache) aren’t in the HTTP response header. Second, the directive CacheControl:private enables the cache only on the machine on which the user is working. This situation creates risks for shared machines (for example, in Internet cafes and university labs). XSS cookie sniffing. If a Web application exposes an

XSS vulnerability,6 an attacker could capture tokens and send them to a specific domain where the attacker can extract them. An exemplar script is Document.location= “http://www. 50

IEEE SECURITY & PRIVACY

attacker.site.com/collectcookie.php? + document.cookie” .

There are two enabling vulnerabilities. First, the Web application is vulnerable to XSS attacks. Second, the HTTPOnly flag isn’t set; in this case, an attacker could read the cookie through an XSS attack.

Session Prediction Even if the Web application doesn’t allow interception of the token and the token-generation algorithm is strong, the attacker can “guess” a token and connect with the website as a legitimate user. Two kinds of attacks are possible. The first is token tampering, if the token is predictable. The second is a brute-force attack that tries different values for the token. The attacker can collect different tokens and analyze their randomness with tools such as the Burp Suite Sequencer (http://portswigger.net/suite). There are two enabling vulnerabilities. The first is an idle time that’s too long (that is, the session doesn’t expire fast enough). The second is flawed or weak implementation of session termination.

Session Fixation Here, the attacker fixes the token before the victim’s authentication.7 The attack has three steps: 1. Session setup. The attacker creates a session on the server (a “trap session”) and receives or creates the token. In some cases, the attacker must keep the session alive (“session maintenance”) by sending requests at regular intervals. 2. Session fixation. The attacker introduces the token into the victim’s browser. 3. Session entrance. The attacker waits for the user to enter the session, at which time the attacker can also enter. Session management mechanisms fall into two categories: • Permissive systems accept new tokens and create a new session. • Strict systems accept only known, previously created tokens. In permissive systems, the attacker chooses a token and uses it. In strict systems, the attacker establishes a session and keeps it alive for the attack’s duration. Session fixation uses different techniques, depending on the mechanism for sending the token. With a URL parameter, the attacker must force the victim to click on a link created ad hoc. With a hidden field, the attacker must leverage XSS vulnerability. With a

Session Management Attacks

cookie, the attacker can exploit other methods: a client-side script that sets the cookie into the browser, an HTML tag with the attribute Set-Cookie, or the response HTTP header Set-Cookie.

Content-Type: text/html Content-Length: 35 Sorry,%20System%20Down

CSRF This attack forces the victim to execute actions in an application in which the victim is authenticated;8 a typical technique uses mail or chat to send the link. This attack could compromise user data. CSRF differs from other attacks mainly in that it aims to accomplish specific actions instead of obtaining session control.

HTTP Response Splitting Some applications use part of the user input to generate the HTTP response header’s values.9 For instance, an application could let the user choose an advanced or standard interface. To select the type of interface, the HTTP response header uses a parameter. If the header uses the parameter interface, the application will send this HTTP response: HTTP/1.1 302 Moved Temporarily Date: Sun, 03 Dec 2005 16:22:19 GMT Location: http://victim.com/main. jsp?interface=advanced

If the application doesn’t control the input, the parameter interface could be enriched with the string %0d%0a, which is the carriage return and line feed (CRLF) sequence for separating different lines. This means that a response could be generated and be interpreted as two different responses. An attacker can exploit this vulnerability to provide fake content in following requests. For instance, suppose an attacker adds to interface this value: advanced%0d%0aContent-Length:%20 0%0d%0a%0d%0aHTTP/1.1%20200%20 OK%0d%0aContentType:%20text/html%0d%0aContentLength:%2035%0d%0a%0d%0aSorry,%20 System%20Down

The HTTP response of an application exposing this vulnerability will be HTTP/1.1 302 Moved Temporarily Date: Sun, 03 Dec 2005 16:22:19 GMT Location: http://victim.com/main. jsp?interface=advanced Content-Length: 0 HTTP/1.1 200 OK

Because the Web cache will consider two different responses, if the attacker sends a second request with /index.html, the Web cache will match this last request with the second response and will store the content. So, all subsequent requests passing from the cache to http://applicazioneweb.test/index.html will receive the message System Down. The second response’s content could be as dangerous as the attacker wishes; for instance, a JavaScript script could steal user cookies. Candidate headers for this attack are Location and Set-Cookie.

Surveying Current Vulnerabilities We surveyed 40 Web applications belonging to wellknown Italian companies or national or regional (but not local) institutions. The sample included websites in nine categories: • mobile telecommunications (5 percent), • e-commerce (15 percent), • e-learning (15 percent), • vertical portals (12 percent), • Web communities (15 percent), • public institutions (10 percent), • email management (13 percent), • e-banking (8 percent), and • other (7 percent). To obtain good external validity for the survey’s conclusions, we selected websites of large, medium, and small organizations for each category. The sample included six Web development ­technologies: • Application service providers (ASP; 27 percent), • Hypertext Preprocessor (PHP; 42 percent), • Java 2 Platform, Enterprise Edition (J2EE; 15 percent), • ColdFusion (8 percent), • Common Gateway Interface (CGI; 5 percent), and • Cocoon (3 percent). A larger sample would have provided a more precise evaluation of differences among the categories in terms of vulnerabilities. However, this limitation didn’t affect our results’ validity because such an evaluation wasn’t our goal. Our goal was to provide a preliminary picture of the state of session management vulnerability (in other words, which vulnerabilities www.computer.org/security

51

Session Management Attacks

Related Work in Session Management

C

oncerning the problem of bypassing HTTPS with HTTP, Collin Jackson and Adam Barth presented ForceHTTPS, a tool that forces the browser to treat HTTPS errors as an attack.1 By setting a ForceHTTPS cookie, the browser behaves as follows: • all non-HTTPS connections are redirected to HTTPS, • all Transport Layer Security (TLS) errors terminate TLS sessions, and • attempts to embed non-HTTPS content into the site fail with network errors.

They propose implementing the Origin header in browsers to replicate the Referer header’s benefits. Adam Kiezun and his colleagues provide a good overview of techniques for detecting cross-site scripting (XSS) vulnerabilities. 5 These techniques include static analysis, dynamic analysis, formal methods, and generators of first- and secondorder XSS attacks. References 1. C. Jackson and A. Barth, “ForceHTTPS: Protecting High-Security Web Sites from Network Attacks,” Proc. 17th Int’l World Wide Web Conf., ACM

Jackson and Barth also described the state of the art regarding this topic. Cross-site request forgery (CSRF) has also recently received much attention. Two tools are of particular interest. Request­ Rodeo is a client-side CSRF mitigation that prevents the site from associating cross-site requests with existing user sessions.2 ­C APTCHAs help identify whether the attacker is displaying a session-dependent secret, in which case the tool requires a validation token to allow the navigation.3 Unfortunately, CAPTCHAs also entail costs due to user-machine interaction and reduced accessibility for blind users. Barth and his colleagues proposed using the HTTP Referer header as a defense against CSRF, especially against CSRF login.4

Press, 2008, pp. 225–233. 2. M. Johns and J. Winter, “RequestRodeo: Client Side Protection against Session Riding,” Proc. OWASP Europe 2006 Conf., 2006; www.informatik. uni-hamburg.de/SVS/papers/2006_owasp_RequestRodeo.pdf. 3. L. von Ahn et al., “Captcha: Using Hard AI Problems for Security,” Proc. Int’l Conf. Theory and Application Cryptographic Techniques, Springer, 2003, pp. 294–311; www.captcha.net/captcha_crypt.pdf. 4. A. Barth, C. Jackson, and J.C. Mitchell, “Robust Defenses for Cross-Site Request Forgery,” Proc. 15th ACM Conf. Computer and Communications Security, ACM Press, 2008, pp. 75–87. 5. A. Kiezun et al., “Automatic Creation of SQL Injection and Cross-Site Scripting Attacks,” Proc. 31st Int’l Conf. Software Eng., IEEE CS Press, 2009, pp. 199–209.

are the most widespread, and how common they are in Web applications). (For information regarding related work, please see the “Related Work in Session Management” sidebar.)

Provus To assess the applications, we used Provus (Process for Detecting Vulnerabilities in Session Management). This process comprises 19 procedures, each assessing a specific vulnerability’s presence (see Table 1). For each procedure, Provus defines the steps for assessing the vulnerability’s presence and lists the necessary tools: browsers, Burp, Paros (www.parosproxy. org), or WebScarab (www.owasp.org/index.php/ Category:OWASP_WebScarab_Project). We have six observations regarding Provus. First, it was semiautomatic. A pen tester analyzed the Web application structure and features using the tools mentioned in the process definition. Second, we performed the analysis ourselves; we didn’t consult any hacker or report on attacks of the sample Web applications. Third, the process doesn’t require source code analysis. Fourth, the analysis is complete because each procedure led exclusively to a binary result: a characteristic is either present or not. The analysis time or depth 52

IEEE SECURITY & PRIVACY

doesn’t affect the result; each procedure explains in detail which Web application characteristics require assessment and how to assess them. For example, the procedure for vulnerability 1 (lack of ciphered protocols) requires • launching the Burp Suite, • setting the URL of the website in the Burp control panel, • disabling the intercept option, and • navigating each website page. If the SSL box is set for some (or all) website pages, the vulnerability isn’t present. If the SSL box isn’t set for any website page, the vulnerability is present. Fifth, we completed the process on each Web application. We successfully performed each procedure on all sites until we obtained a result. Finally, the tests didn’t require accounts on the sites because they assess features that are accessible whether or not the user is logged in.

Results Most sample applications prefer to use just cookies (82 percent). Eight percent use cookies and URL parameters, another 8 percent use URL parameters, and the remaining 2 percent use hidden fields.

Session Management Attacks

Table 1. The vulnerabilities covered by Provus (Process for Detecting Vulnerabilities in Session Management). Vulnerability

Description

1. Lack of ciphered protocols 2. Possibility of bypassing the ciphered protocol 3. Session ID remaining unvaried before and after ­authentication 4. Session ID in cookies but without the secure flag

The application doesn’t use HTTPS. The application allows the use of HTTP in place of HTTPS. After the first authentication, a static session ID is assigned to each user.

Although HTTPS is used, the cookie can also be transmitted on unciphered connections. 5. Session ID in cookies without the HTTPOnly flag The cookie can be read with client-side scripts, through cross-site scripting (XSS) attacks. 6. HTTP replies with the header enabling caching HTTP headers that disable caching aren’t used. 7. Session ID captured in URL parameters The application transmits the session ID with URL parameters. 8. Possibility to bypass POST requests with GET requests The application allows processing of GET requests in place of POST requests. 9. Session ID built with user information The application builds the session ID by composing available user information. 10. A low level of randomness of the session ID The application uses a session ID with low entropy. 11. The possibility to create a valid session ID The application lets users establish a valid session by accepting a session ID that the user created. 12. HTTP requests allow the use of carriage return and The application doesn’t control the use of CRLF characters in the input line feed (CRLF) characters ­parameters. 13. The “remember me” option The application stores the user information in a cookie, allowing automatic authentication for subsequent accesses. 14. Weak session termination The application doesn’t let the user close the session on demand; alternatively, the session termination mechanism is flawed. 15. Simultaneous connections The application allows authentication of two different IP addresses for the same account at the same time. 16. Faulty idle timeout The application keeps the session ID valid even if no new request occurs for a long time. 17. Session ID replay The application allows access to a new session by copying a valid session ID on another browser. 18. Session ID represented by a cookie with the wrong The application uses a cookie as a session ID with a domain scope and path scope and path that are larger than the application’s. 19. Transmission of session ID through cookies The application uses only the cookie to store and transmit the session ID.

Use of HTTPS isn’t widespread: of the 15 percent that use it, 2.5 percent apply it only in protected areas and 12.5 percent apply it in all the website’s pages. Of the Web applications, 5 percent provide the opportunity to bypass HTTPS with HTTP requests. Concerning applications that use cookies, 85 percent failed to properly set the secure flag and 70 percent failed to properly set the HTTPOnly flag. This situation permits cookies to be sent on unencrypted connections, letting the attacker obtain the cookie through an XSS attack. Vulnerability resulting from the incorrect scope of a domain or path is less common (10 percent). The prevalence of session fixation is more severe; 55 percent of the applications don’t generate a new token after authentication. The potential success of attacks in this area is facilitated by the fact that 47.5 percent of the applications allow creation of a valid token to be used in place of a legitimate user.

Vulnerability related to cache use doesn’t appear common; 50 percent of the applications disable the cache, and 30 percent enable it only on the local machine. Only 15 percent include information about the user in the token. We evaluated the level of token randomness with Burp’s utilities: 52.5 percent weren’t deterministic, but 35 percent were guessable, which is worrisome. Two of the most common vulnerabilities are the possibilities to • connect with the same account from different machines at the same time (87.5 percent) and • use the same token to connect with a machine other than the user’s (90 percent). Session termination is well implemented in most applications; it’s a vulnerability in only 10 percent of them. Session duration is a more serious problem, www.computer.org/security

53

Session Management Attacks

Table 2. The presence of vulnerabilities according to the application domain (%).

33 67 33 67 33 67 0 33 33 100 67 0 0 0 100 67 100 0 100 47

0 100 75 100 75 100 0 100 0 25 50 25 50 0 100 75 75 25 100 57

0 50 100 100 100 100 0 50 0 100 100 50 0 0 100 0 100 50 100 58

Average

0 100 40 100 80 60 0 60 20 80 40 0 20 20 80 40 80 0 80 47

Mobile tele– communications

80 0 100 100 60 0 80 60 80 0 20 20 0 40 60 100 20 40 0 48

Public institution

17 83 67 100 100 67 33 17 0 33 50 33 33 0 100 50 100 33 67 52

Others

17 100 83 100 83 83 17 33 0 17 67 0 33 17 100 50 83 17 83 52

Vertical portal

100 33 67 67 100 100 0 67 0 0 33 0 0 0 67 0 100 33 100 46

Email management

E-learning

0 100 50 100 50 100 0 17 17 33 50 0 50 33 100 50 83 0 100 49

E-commerce

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Average

E-banking

Web community

Vulnerability*

Domain

27 70 68 93 76 75 14 49 17 43 53 14 21 12 90 48 82 22 91

Number of applications that are vulnerable to the attack

* For an explanation of the vulnerabilities, see Table 1.

ng

ry TP

sn

iffi

ge HT

at ite

re

qu

es

fix io n

ss Se

tf or

io n

rc e fo

io n

e

at

Br ut

ul

an ip

m

en

Cr

os s

-s

To k

S

co ok

ie

sn

iffi

ng

ng iffi

ng

sn

iffi

ch e Ca

Lo g

sn

XS

HT

TP

pa

ck

et

sn

iffi

ng

40 35 30 25 20 15 10 5 0

Attack type

Figure 1. The prevalence of vulnerabilities in the surveyed Web applications. This figure shows how many sample applications are vulnerable to each attack.

with 45.5 percent allowing more than 30 minutes of inactivity. A few applications (12.5 percent) exhibit CRLF vulnerability, and a scarce minority (7.5 percent) use URL parameters as a unique means of transmission, both of which facilitate log-sniffing at54

IEEE SECURITY & PRIVACY

tacks. Almost half the applications (47.5 percent) serve POST requests by using the GET method. The option “remember me” is used in 27.5 percent of the applications. Almost all the applications (82.5 percent) are vulnerable to CSRF attacks because they exclusively use cookies to transmit tokens. We didn’t consider vulnerabilities concerning systems involved in client-server interaction. Figure 1 illustrates each vulnerability’s prevalence in the applications. Vulnerability to HTTP packet sniffing is the most common because few applications use encrypted protocols. This vulnerability is followed by XSS cookie sniffing and cache sniffing, because few applications use proper session-caching policies and adopt countermeasures against XSS vulnerability. Session fixation and CSRF are at medium prevalence. Brute-force attacks are likely, because tokens have low entropy levels. Possibilities of log sniffing, token manipulation, and HTTP splitting are scarce. Table 2 lists the vulnerabilities’ prevalence by category. Mobile-telecommunications and public-institution Web applications contain the most vulnerabilities. The most robust applications are e-banking, vertical portals, and email management. Security is critical to these businesses, and, as we expected, these applica-

Session Management Attacks

Table 3. The presence of vulnerabilities according to different Web development technologies (%).

Mobile tele– communications

17 50 67 67 83 50 0 67 17 33 33 17 17 0 83 17 67 17 67 40

0 100 100 100 100 100 0 100 0 100 100 0 0 0 100 0 100 0 100 58

11 83 44 89 78 78 6 28 11 28 39 0 33 11 83 61 83 11 78 45

21 75 65 94 88 71 9 58 14 59 60 19 12 11 73 24 88 15 76 49

0 100 75 100 75 100 0 100 0 25 50 25 50 0 100 75 75 25 100 57

0 50 100 100 100 100 0 50 0 100 100 50 0 0 100 0 100 50 100 58

Average

Public institution

0 100 100 100 100 67 0 0 0 100 100 0 0 67 100 33 67 0 100 54

Average

ColdFusion

0 100 0 100 100 0 50 50 50 100 0 100 0 0 50 0 100 50 0 45

Cocoon

Common Gateway Interface

18 91 45 100 55 100 9 64 18 55 45 18 36 0 91 55 100 27 91 54

Hypertext Preprocessor

Application service providers

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Average

Java 2 Platform, Enterprise Edition

Vulnerability*

Technology

27 70 68 93 76 75 14 49 17 43 53 14 21 12 90 48 82 22 91

* For an explanation of the vulnerabilities, see Table 1.

tions’ developers pay much attention to it. However, these applications are still vulnerable. For instance, all e-banking applications have vulnerabilities 1, 5, 6, and 17 (see Table 1), which, if exploited, could entail substantial damage. Vulnerabilities are still too prevalent, especially in critical Web applications such as e-banking and e-commerce (in which identity theft could cause loss of money) and in public-­institution Web applications (in which personal data could be stolen). Table 3 lists the vulnerabilities’ prevalence by technology. The most robust applications were developed with J2EE, whereas those built with PHP, Cold­Fusion, and ASP seem the most vulnerable. Vulnerabilities 2, 4, 5, 15, and 17 are the most widespread. Their presence isn’t due strictly to specific technologies; rather, it highlights the general lack of good practices among Web application designers. Vulnerabilities 1, 7, 9, 14, and 18 are the rarest.

T

he survey’s results suggest that at least three immediate countermeasures are necessary:

• Enforce a culture of secure software engineering in university and industrial training programs.

• Run adequate, frequent penetration-testing sessions. • Include specific utilities and functions for secure session management in Web application development technologies and frameworks. To strengthen session management, Web application designers and developers should take into account five recommendations. First, properly manage HTTPS sections, especially if other portions of a Web application can be visited with HTTP. Second, use adequate directives for caching and cookie transmission. Third, protect Web applications against XSS attacks. Fourth, thoroughly design session termination mechanisms. Finally, reduce the possibility of having multiple tokens for the same user at the same time or of having static user tokens. References 1. Cenzic Web Application Security Trends Report—Q3–Q4, 2009, Cenzic, 2010. 2. C. Soghoian and S. Stamm, “Certified Lies: Detecting and Defeating Government Interception Attacks against SSL,” Social Science Research Network, Apr. 2010; http://files.cloudprivacy.net/ssl-mitm.pdf. 3. “OWASP Top 10 2010 AppSecDC,” Open Web Appliwww.computer.org/security

55

Session Management Attacks

4.

5.

6.

7.

8.

cation Security Project Foundation, Nov. 2009; www. owasp.org/index.php/OWASP_Top_10_2010_App SecDC. D. Stuttard and M. Pinto, The Web Application Hacker’s Handbook: Discovering and Exploiting Security Flaws, John Wiley & Sons, 2008. C. Anley, “Weak Randomness: Part I—Linear Congruential Random Number Generators,” Next Generation Security Software, 2007; www.ngssoftware.com/Libraries/Documents/02_07_Weak_Randomness.sflb.ashx. “Cross Site Scripting,” Web Application Security Consortium, 2009; www.webappsec.org/projects/threat/ classes/cross-site_scripting.shtml. M. Kolšek, “Session Fixation Vulnerability in WebBased Applications,” Acros Security, Dec. 2002; www. acrossecurity.com/papers/session_fi xation.pdf. “OWASP Testing Guide v3,” Open Web Application Security Project Foundation, Nov. 2008; www.owasp. org/index.php/OWASP_Testing_Guide_v3_Table _of_Contents.

stay on the

9. A. Kiezun et al., “Automatic Creation of SQL Injection and Cross-Site Scripting Attacks,” Proc. 31st Int’l Conf. Software Eng., IEEE CS Press, 2009, pp. 199–209. Corrado Aaron Visaggio is an assistant professor of database and software testing at the University of Sannio. His research interests include empirical software engineering, software security, and data privacy. Visaggio has a PhD in computer engineering from the University of Sannio. Contact him at [email protected]. Lorenzo Convertito Blasio is a software engineer at Progesi. His research interest is systems for 3D feature extraction. Blasio has a master’s in computer engineering from the University of Sannio. Contact him at [email protected].

Selected CS articles and columns are also available for free at http://ComputingNow.computer.org.

Cutting Edge

of Artificial Intelligence IEEE Intelligent Systems provides peer-reviewed, cutting-edge articles on the theory and applications of systems that perceive, reason, learn, and act intelligently.

www.computer.org/intelligent 56

IEEE SECURITY & PRIVACY

IEEE

The #1 AI Magazine