By: Mehdi Mirakhorli (@MehdiMirakhorli), Associate Editor
Software engineers face a constantly growing pressure to build secure software by design, where systems have to be designed from the ground up to be secure and resistant to attacks. To achieve this goal, security architects work with various stakeholders to identify security requirements and adopt appropriate architectural solutions to address these requirements. These architectural solutions are often based on security tactics. Security tactics as reusable solutions to satisfy security quality attributes regarding resisting attacks (e.g., tactic “Authenticate Actors”), detecting attacks (e.g., tactic “Detect Intrusion”), reacting to attacks (e.g., tactic “Revoke Access”), and recovering from attacks (e.g., tactic “Audit”). Despite the significant efforts that go into designing secure systems, security can slowly erode because of ongoing maintenance activities. Incorrect implementation of security tactics or the deterioration of security tactics during coding and maintenance activities can result in vulnerabilities in the security architecture of the system, thus compromising key security requirements. We refer to these vulnerabilities as tactical vulnerabilities.
The code snippet in Listing 1 from a J2EE web application shows an example of such tactical vulnerabilities which is the incorrect implementation of the “Manage User Sessions” tactic. The correct implementation of this tactic in a web application would allow the system to keep track of users that are currently authenticated (including permissions they hold). However, in the given code snippet, the application authenticates users with LoginContext.login() without first calling HttpSession.invalidate() to invalidate any existing session. This enables attackers to fixate (i.e., find or set) another user’s session identifier (e.g., by inducing a user to initiate a session using the session identifier provided by the attacker). Once the user authenticates him/herself with this forged session identifier, the attacker would be able to hijack or steal his/her authenticated session. Although architects have used the “Manage User Sessions” tactic in the architecture design of the web application, the developers have failed to implement it correctly, resulting in a tactical vulnerability that can be exploited for session fixation attacks.
Recent empirical studies of security vulnerabilities have neglected the architectural context, including design decisions such as tactics and patterns. They mostly focus on studying and understanding coding issues related to the management of data structures and variables (e.g., buffer overflow/over-read).
Goal of This StudyHere, I’d like to report an in-depth case study of software vulnerabilities associated with architectural security tactics across three large-scale open-source systems (Chromium, PHP, and Thunderbird). In this blog post, I only present the results, the scientific process and systematic approach used to make the conclusions can be found in our research article here.
Common Tactical Vulnerabilities
Table I lists the root causes (i.e., vulnerability types) of tactical vulnerabilities in each of the three studied systems, the related architecture tactics, as well as the total number of CVEs caused by the given vulnerability type.
While Chromium, PHP, and Thunderbird have adopted a wide range of architectural tactics to secure the systems by design, a remarkable number of vulnerabilities discovered in these systems are due to incorrect implementations of these tactics.
- While Chromium, PHP, and Thunderbird have adopted a wide range of architectural tactics to secure the systems by design, a remarkable number of vulnerabilities discovered in these systems are due to incorrect implementations of these tactics
- Improper Input Validation (CWE-20) and Improper
Access Control (CWE-284) are the most occurring root causes for security vulnerabilities in Chromium, PHP, and Thunderbird.
- Vulnerabilities in the three studied systems are mostly related to tactics “Validate Inputs” and “Authorize Actors” for resisting attacks.
- Security of studied projects was compromised by reusing or importing vulnerable versions of third-party libraries. In the case of Chromium, such vulnerabilities occurred 106 times, while in Thunderbird and PHP, 7 and 8 times, respectively.
- Tactical and non-tactical vulnerabilities have a similar distribution over time and releases, even though the absolute numbers of tactical and non-tactical vulnerabilities differ.
- When fixing tactical vulnerabilities, there is no statistically higher or lower code churn compared to fixing non-tactical vulnerabilities.
- When fixing tactical vulnerabilities, the number of affected files is not statistically significantly higher or lower compared to fixing non-tactical vulnerabilities.
Understanding Software Vulnerabilities Related to Architectural Security Tactics: An Empirical Investigation of Chromium, PHP and Thunderbird In 2017 IEEE International Conference on Software Architecture (ICSA), 2017.