Root Cause Analysis of Session Management and

Broken Authentication Vulnerabilities

Daniel Huluka
DSV, Stockholm University
Department of Computer and System Sciences
Stockholm, Sweden
huluka@kth.se
Oliver Popov
DSV, Stockholm University
Department of Computer and Systems Sciences
Stockholm, Sweden
popov@dsv.su.se
AbstractWhile there are numerous approaches to secure
web applications as one of the most prevalent ways to
harness the potential of the Internet, attackers almost daily
come up with new attempts to exploit various
vulnerabilities and compromise data found on the Net.
One of the possible venues to attain sustainable solutions is
to follow strategic approaches based on detailed analysis
and understanding of problems rather than some of the
common tactical and often reactive methods. The aim of
the paper is to explore employment of Root Cause Analysis
(RCA) in session management and broken authentication
vulnerabilities and how it can be utilized to improve some
security aspects of web applications. By employing RCA,
we were able to identify 11 root causes of session
management vulnerabilities and 9 root causes of broken
authentication vulnerabilities. In addition, the approach
provided a detailed, almost macroscopic, view of the
vulnerabilities, which consequently led to effective
solutions that can minimize the recurrence of attacks on
web applications.
Keywords- Vulnerabilities, Session Management, Broken
Authentication, Root Cause Analysis (RCA)
I. INTRODUCTION
Web applications include and cover a number of services
such as commercial transactions and mail exchange. The
deployment of applications via web has many benefits, for
instance (1) it increases the reach of application owners to the
intended users, and (2) reduces the maintenance and
deployment costs [1]. The wide acceptance and usability of
web applications however has brought them into the focus of
cyber attacks of various sorts. The statistics shows a rapid
evolution in the number of Internet attacks, particularly in the
realm of web applications [2, 3].
This is not surprising at all, considering the exponential
growth of variety web applications in almost every sector of
the contemporary society. The most prominent sectors are the
banking industry, education and the associated institutions,
health and medical centers, varieties of business organizations,
government institutions where web based applications are the
primary means of automating daily core activities or upgrading
the existing solutions.
Despite numerous attempts to counter attacks,
vulnerabilities are frequently found in most web applications
[4]. Hence, we suggest a move or even a paradigm shift from
tactical to strategic approach by changing reactive security to
proactive security through issue analysis, risk analysis and in
general quite holistic models. Basically, we are trying to follow
up on the assertion posited by McGraw that the only way I see
the security conundrum getting solved is be confronting the
problem and not the symptoms of the problem [5].
RCA has a proven record as an effective problem analysis
method in different knowledge domains that may range from
handling customer complaints on a limited products line to
critical infrastructures such as risk analysis in nuclear power
plants [6].
We feel that the inherent potential of RCA is somehow
ignored relative to computer and information security. Usually,
it has been reduced to certain applications in the analysis of
very few specific attacks on computer networks and data
centers [7, 8].
Our research focuses on the application of RCA to identify
root causes of Session Management and Broken Authentication
Vulnerabilities and eventually come up with solutions that shall
minimize the recurrence of these vulnerabilities in web
applications.
The rest of the paper is organized as follows: in the next
section we present the state of the art in RCA and security. A
fairly detailed explanation of web applications and their
vulnerabilities is presented in section III. The discussion of
how RCA can be applied to identify causes of web application
vulnerabilities is placed in Section IV. The results of the study
along showed in Section V, are combined with the suggested
solutions or recommendations to counter Session Management
and Broken Authentication Vulnerabilities. The paper ends
with Section VI, which addresses the possible directions for
future work and the overall conclusions.
II. RELATEDWORK
The research suggests RCA of Session Management and
Broken Authentication Vulnerabilities based on extensive
background study and following the principles and
methodology of Apollo RCA. As pointed out in [9] one must
understand the root causes of attacks to find solutions that
make web services safer. The experience indicates that RCA is
This research was supported by Department of Computer and System
Sciences, DSV, Stockholm University, Sweden

World Congress on Internet Security (WorldCIS-2012)
978-1-908320-04/9/$25.002012 IEEE 82
an acceptable and useful approach in attack incident analysis
in large IP Networks and huge data centers [10]. Notable
examples of the later include the investigation of a SQL
Slammer worm infection in a multinational enterprise [11],
classifying web attacks and vulnerabilities [9], and analyzing
attacks on Honey Pots [12].
The post-incident RCA of digital incidents (digital post
mortems) in a large complex investigation of SQL Slammer
worm used End-to-End Digital Investigation (EEDI) and
Digital Investigation Process Language (DIPL), yet another
instances of the implementation of the approach presented in
[11]. As shown in the investigation processes there is close
relationship and actually some overlaps with the Digital
Forensic Research Workshop (DFRWS) investigation
framework. However, from the results it can be seen that the
investigation process lacks further break down of the causes.
The analysis process in [12] starts by collecting data (that
deals with the geographical localization of packets, logs,
known blacklist of IP addresses and other important features)
from the honeypot to come up with very few port sequences
and focusing on those port sequences as the possible root
causes of attacks.
The application of RCA in identifying problems in
computer networks is discussed in [9, 10, 12]. Additional work
is required to identify causes of problems in the web
applications such as the generic and high level research
presented in [7, 8].
III. WEB APPLICATIONS AND VULNERABILITIES
A. Web Applications Evolution
Initially, websites were static and the interactions between
users and web servers were very limited. The implementation
of dynamic websites through server side scripts made it
possible to dynamically generate web pages for interactions
between users and web servers. The reliance on the HTTP
protocol is one thing common from the initial static web sites
until the latest Web 2.0 and AJAX based web applications.
These advancements in web applications are most commonly
backed by the Model, View and Control (MVC) architecture.
The applications built on this architecture, indicate a huge
increase [5] in the code base (in the executable space) even in
cases where the source code is small and it has an impact in
Secure Software Engineering practices.
Despite higher advancement in the bare web technology, one
notable change in the original protocol is S-HTTP (Secure
HTTP), a secure message-oriented communications protocol,
designed to coexist with the HTTP messaging model and to be
easily integrated with HTTP applications [13].
B. Web Application Vulnerabilities
Vulnerability is an occurrence of a weakness within a piece of
software, which can be explored and used by a party to cause
(1) the software to modify or access unintended data, (2)
interrupt proper execution, or (3) perform incorrect actions
that were not specifically granted to the party who uses the
weakness [14]. Vulnerabilities may exist on a system without
affecting it; however, once exploited, attackers may start
taking advantage of the discovery.
The classification of web application vulnerabilities is the first
step to better understand the problems related to
vulnerabilities and their eventual mitigation and/or
elimination. The notable classifications schemas are: OWASP
Top 10 [15]; McGraws 7 Vulnerability categories [5];
CWE/SANS 25 Top Most Dangerous Vulnerabilities [16] and
Howard Michael (et. al) Deadly sins of software security [17].
The Web Application Security Consortium has also published
another classification scheme in January 2010 [14].
C. The OWASP Top 10 List of Vulnerabilities
As per OWASPs definition [15], vulnerability is a hole or a
weakness in the application, which can be a design flaw or an
implementation bug. There are ten major categories of
vulnerabilities identified by OWASP in its 2010 release
x A1-Injection,
x A2-Cross Site Scripting (XSS),
x A3-Broken Authentication and Session Management,
x A4-Insecure Direct Object References
x A5-Cross Site Request Forgery (CSRF)
x A6-Security Misconfiguration
x A7-Insecure Cryptographic Storage
x A8-Failure to Restrict URL Access
x A9- Insufficient Transport Layer Protection and
x A10-Unvalidated Redirects and Forwards.
In this research, RCA is applied on A3 (or Session
Management and Broken Authentication vulnerabilities). Mc
Graw [5] has raised some complexity issues on the
classification schemes: OWASP Top 10 and The 19 Deadly
sins of Software security. He shows how the categories of
both schemes can fit into his seven categories to deal with their
complexities. In this case the Session Management and Broken
Authentication vulnerabilities of the OWASP 10 exactly fit
within the Time and State and Security Feature categories
of the 7 lists by Mc Graw. Hence, our selection from the
OWASP classification scheme is not affected by the problems
pointed out by Mc. Graw.
IV. RCA OF WEB-APPLICATION VULNERABILITIES
A. RCA Methods and Tools
There are a number of RCA tools and methods. In [18], four
major RCA methods have been identified: Five Whys,
Ishikawa Fish bone diagram, Apollo, Management Oversight
and Risk Tree (MORT), and Fault Tree Analysis. There were
some comparisons among the RCA methods and tools [19,

World Congress on Internet Security (WorldCIS-2012)
978-1-908320-04/9/$25.002012 IEEE 83
20]; however, it was hardly possible to point out a particular
tool or method as being the best one.
We selected Reality Charting Root Cause analysis software as
an approved tool for the implementation of the Apollo RCA
methodology which is one of the commonly used RCA
methods in different domains [19]. It is a simple causal
process tool whereby one (1) asks why the (defined) problem
occurs, (2) answers the question with at least two causes then
(3) examines each previous cause until there are no more
causes attributable to the last identified causes. The search for
the unknown shall be repeated several times until a complete
cause and effect chart, called a Reality chart, is created that
shows all the identified causes and their inter-relationships
with immediate effects as well as the main problem.
The cause identification is a repetitive process that continues
until we are not able to find any more causes for a cause; and
it may sometimes be difficult to stop the cause identification
process. In Apollo RCA [19] three major rules are suggested
to avoid an infinite loop.
1. The leverage point principle
2. The Pareto principle (20-80 rule)
3. The span-of-control or sphere-of-influence principle
The leverage point principle requires the consideration of cost
and impact of the problem in decision making. The second
principle involves comparative analysis or weighing of causes
to discern and differentiate the vital causes from the trivial
ones. The third stopping criterion, span of control or sphere of
influence principle is inherent to the nature and scope of the
problem and the stakeholders involved. There is no need to
weigh causes or to have comparisons that require huge
volumes of data and measurement metrics.
The frame of reference is the core point considered in the
RCA process. For instance, in this research the identification
of causes for one particular web application vulnerability may
go to the basic hardware architecture of a computer or even
beyond. However, root causes are specific underlying causes
that can reasonably be identified [20] and our focus is on
identifying root causes whose suggested solution should not
go beyond the scope of web application development or
directly related entities such as browsers and web servers.
The causes are then attached to solutions that can prevent
recurrence and meet specific goals and objectives [20]. The
solutions are evaluated against the four requirements listed in
the Reality Charting tool:
Does this solution prevent recurrence?
Is the solution within your control?
Does this solution meet your goals?
Does this solution cause other unacceptable problems
that you are aware of?
Depending on the response given, the suggested solution may
or may not be included in the list of final solutions. Those
placed on the final list are qualified to overcome the problem
at its root.
B. How to apply RCA on web application vulnerabilities
RCA can be applied on a specific incident which is
commonly referred as Post-Incident Root Cause Analysis
[10]. Post-Incident RCA is very common in identification of
problems related to device failures, production problems,
frauds, and active network related attacks [11]. The second
approach is to analyze general problems based on knowledge
of the domain and understanding of the common characteristics
of similar problems, while using specific incident information
as an add-on reference and supporting argument in the analysis.
This approach is our choice of preference as it covers a broad
range of the problem domain and the research doesnt basically
focus on a specific attack incident.
There is also lack of sufficient and dependable data that
comes from security incidents [3] in web application
vulnerabilities and attack incidents., so the qualitative data that
comes from background analysis is the main source for the
analysis.
V. RESULTS AND DISCUSSION
This section lists the identified root causes followed by
detailed discussion and list of suggested solutions. The RCA
of Session Management Vulnerabilities is done in two
categories: Session Hijacking and Session Fixation. While the
RCA of Broken Authentication vulnerabilities follows one
problem line.
A. Root causes of Session Management Vulnerabilities
and Suggested Solutions
Root Causes of Session Hijacking
1. Usage of guessable session ID.
2. Absence of detection mechanism for repeated
guessing trial either with brute-force or systematic
methods.
3. Unable to detect repeated guessing trials while there
is a mechanism in place..
4. Weak cryptography: a weakness in the cryptography
algorithm or a weakness in the way a strong cryptographic
algorithm is used.
5. Limitation of HTTP: the statelessness of the protocol
or lack of any inherent or integrated state management
mechanism.
6. Insecure session handling methods.
7. Solution misuse: the misconfiguration or improper
use of basically strong solutions
8. Weakness in the Inactive session management
technique.
Root Causes of Session Fixation
1. Permissive Server: a server that accepts client
generated session IDs
2. Session management type in use.

World Congress on Internet Security (WorldCIS-2012)
978-1-908320-04/9/$25.002012 IEEE 84
3. Reuse of session identifiers: generating same session
identifiers twice or more for different sessions of the same
or different clients.
Problem Discussion and Suggested Solutions
Session Management has become very important as the
interactions of users are getting more dynamic and complex
cross web sites. Nevertheless, they still depend on the stateless
protocol HTTP, which lacks strong session handling capability
to induce usage of various solutions that may further
compromise the security of systems. To strengthen security we
suggest the use of cookies, enforcement of the same origin
policy for the cookies, and usage of SSL for any traffic
comprising of session IDs and credentials. The other
weaknesses identified usually occur within the implemented
solutions that attempt to secure the session identifier
(examples include guessable session-id, cryptographically
weak protection, insecure session handling mechanisms, and
others). These add-on solutions essentially try to protect the
sensitive information, but they fail to do that in a proper way.
The root causes (1) Usage of Guessable Session ID and (2)
Re-use of session ID, show lack of clear understanding of
the solution implemented by the programmers. With the fast
increase in computational power (the processor performance
and memory capacity), its becoming feasible to brute force
very large text strings in micro seconds. Another closely
related cause that shows lack of understanding is Permissive
Server for client generated session IDs. In order to deal with
these root causes, we suggest (1) the deployment of
cryptographically strong random number generators to
generate session IDs and (2) session IDs should always be
generated by servers.
Lack of attention to details is also a common characteristic
among the causes - Insecure session handling methods
exemplified by hiding session-ID on hidden forms and
Inactive session management weakness. A problem that still
needs further research is lack of reliable repeated trial
identification mechanism. Currently, in all IP networks, source
identification is used, however with the possibility of IP
spoofing attackers may try to brute force session IDs via
repeated trials.
B. Root Causes of Broken Authentication Vulnerabilities
and Suggested Solutions
1. Lack of metrics: absence of well-developed metrics
that can assist in making the right decision in the selection
of security mechanisms.
2. Lack of security knowledge among programmers to
apply information and communication security mechanisms
to their solutions.
3. Wrong decisions or compromises: both designers and
programmers are prone to wrong decisions due to lack of
metrics and security knowledge.
4. Use of self-developed modules instead of well tested
and thoroughly analyzed modules for security services such
as authentication.
5. Storing user credentials with other application data.
6. Guessing Attempts: allowing repeated guessing
attempts.
7. Level of user data in the system: the level of
information the system knows/holds about users.
8. Lack of security awareness among users.
9. Stringent requirements set to strengthen security
might be unrealistic and very difficult to be meet by users.
Problem Discussion and Suggested Solutions
The design and implementation of authentication modules
shall take into consideration both technical and human issues.
Implementing an authentication system with very strong
security features may be cost prohibitive and infringe on and
hinder usability. The level of security required for one
particular system is hardly known as the discipline of security
lacks proper metrics; which actually implies that it difficult to
measure whether or not a particular solution has attained the
required or even the desired level of security.
When password based authentication mechanisms are
considered, the ability of human users to remember long and
complex passwords is a well-known limitation. Quite often, it
is possible to persuade users to avoid using weak passwords.
However, due to the increase in the number of systems
available to a single user that he may log-in, users may prefer
to re-use passwords or use a rather memorable password that
is easily guessable. Either way of attempting to satisfy
password requirements makes systems vulnerable.
More work is needed in designing and providing users with
memorable, yet strong passwords via pass phrases, pass faces
or user selected digital objects. Another important approach is
the single-sign-on (SSO) authentication that reliefs users from
the burden of remembering too many passwords.
The protection of authentication data does not stop with the
process of authentication. Preserving the sessions of
authenticated users and the long-term management of users
credentials are important issues. Proper attention should be
given in studying and understanding how the authentication
system handles numerous requests whenever the application is
being executed. In order to deal with such requirements,
readymade authentication modules are better than developing
new ones. Readymade authentication modules within the web
application frameworks are usually tested by large user and
developer communities; that makes them more reliable.
During password guessing attempts authentication systems
shall not give information about the specific mistakes on each
attempt and also have ways to lock the account or to use
CAPTCHA, when there is a repeated failed login attempt.
Purely technical solutions towards the security of web
applications from broken authentication problems are the
usage of S-HTTP during authentication and cryptographically
protecting user credentials (for instance by using hashing or
encryption). These solutions protect authentication data but
the solution creates communication overhead and need further
optimization.

World Congress on Internet Security (WorldCIS-2012)
978-1-908320-04/9/$25.002012 IEEE 85
VI. CONCLUSION
This research has demonstrated that Root Cause Analysis is an
important methodology in identifying problems related to web
application vulnerabilities.
The suggested solutions for the two web application
vulnerabilities are effective in the sense that they have a clear
and well defined relationship with the major problem. Since
the application of RCA is a novel approach in resolving the
web application security related vulnerabilities, further work is
required to analyze the methodology with respect to
completeness by addressing vulnerabilities that are not
covered here. Additionally, formal validation and verification
of RCA methods and tools would also increase the reliability
and dependability of RCA to the alignment between Security
and various ICT applications that are crucial for the proper
functioning of the Internet based world.
ACKNOWLEDGMENT
H. M. G. and M. thanks.
REFERENCES
[1] Teodoro, N.; Serrao, C.; , "Web application security: Improving
critical web-based applications quality through in-depth security
analysis," Information Society (i-Society), 2011 International
Conference on , vol., no., pp.457-462, 27-29 June 2011
[2] http://www.sans.org/top-cyber-security-risks, Access Date: Feb
21, 2010
[3] Web Application Security Trends Report Q1, Q2, Q3 and Q4
2009, CENZIC
[4] Bau, Jason; Bursztein, Elie; Gupta, Divij; Mitchell, John; ,"State
of the Art: Automated Black-Box Web Application
Vulnerability Testing," Security and Privacy (SP), 2010 IEEE
Symposium on , vol., no., pp.332-345, 16-19 May 2010
[5] Gary McGraw, Software Security: Building Security In , ISBN-
10: 0-321-35670-5,Pearson Education INC, 2006
[6] Goodman, G.; West, G., Jr.; Schoenfeld, I.; , "Criteria for review
of root-cause analysis programs," Human Factors and Power
Plants, 1997. 'Global Perspectives of Human Factors in Power
Generation'., Proceedings of the 1997 IEEE Sixth Conference
on , vol., no., pp.2/1-2/6, 8-13 Jun 1997
[7] Byers, D.; Ardi, S.; Shahmehri, N.; Duma, C.; , "Modeling
Software VulnerabilitiesWith Vulnerability Cause
Graphs," Software Maintenance, 2006. ICSM '06. 22nd IEEE
International Conference on , vol., no., pp.411-422, 24-27 Sept.
2006
[8] C.W. Johnson, Using Violation and Vulnerability Analysis to
Understand the Root- Causes of Complex Security Incidents,
Dept. of Computing Science, University of Glasgow, Scotland
[9] Jeongseok Seo; Han-Sung Kim; Sanghyun Cho; Sungdeok Cha;
, "Web server attack categorization based on root causes and
their locations," Information Technology: Coding and
Computing, 2004. Proceedings. ITCC 2004. International
Conference on , vol.1, no., pp. 90- 96 Vol.1, 5-7 April 2004
[10] Banerjee, D.; Madduri, V.R.; Srivatsa, M.; , "A Framework for
Distributed Monitoring and Root Cause Analysis for Large IP
Networks," Reliable Distributed Systems, 2009. SRDS '09. 28th
IEEE International Symposium on , vol., no., pp.246-255, 27-30
Sept. 2009
[11] Peter Stephenson, Modeling of Post-Incident Root Cause
Analysis, International Journal of Digital Evidence, Vol. 2, Issue
2, Michigan University, USA, 2003
[12] F. Pouget, M. Dacier, Honeypot-based Forensics, Institut
Eurecom, France,
[13] E. Rescorla, A. Schiffman, The Secure HyperText Transfer
Protocol, Internet Draft, IETF, 1998
[14] Web Application Security Consortium (WASC) Threat
Classification, Version 2, 2010
[15] OWASP Top10 2010, The Ten Most Critical Web Application
Security Risks, 2010
[16] Common Weakness Enumeration (CWE),
http://www.cve.mitre.org Access Date: March 10, 2010
[17] Michael Howard, David LeBlanc, John Viega, 19 Deadly Sins
of Software Security: Programming Flaws and How to Fix
Them (Security One-off)
[18] Anthony Mark Doggett, A Statistical Comparison of 3 Root
Cause Analysis Tools, Journal of Industrial Technology, Vol.
20, No. 2, 2004
[19] Dean L. Gano, Comparison of Common Root Cause Analysis
Tools and Methods, from the book Apollo Root Cause Analysis,
3
rd
Ed. , 2007
[20] James J. Rooney, Lee N. Vanden Heuvel, Root Cause Analysis
for Beginners, Quality Progress Discussion Board, 2004.

World Congress on Internet Security (WorldCIS-2012)
978-1-908320-04/9/$25.002012 IEEE 86