Process Innovations For Security Vulnerability Prevention In Open Source Web Applications

09 Aug 2023 - 17:03 | Version 9 | UnknownUser

Goal

Design and evaluate practices to introduce non-trivial code changes into open source projects to prevent common security weaknesses in web applications.

Structure

Analysis of weaknesses/vulnerabilities/attacks under discussion (SQLIA/XSS)
Analysis and discussion of common mitigations (data model driven development and ad-hoc approaches)
Design of a evolutionary practices to introduce security weakness mitigations into open source web application projects
- Application of the practices to fix inline SQL use in Wordpress
- (Application of the practices to inline SQL in another project or XSS weaknesses in Wordpress)
- Discussion of generalization of the practices for other types of vulnerabilities
- (Discussion of generalization of the practices for non-security related code changes)

Prose

Web applications are on the rise. Lightweight, ubiquitous alternatives to classical desktop counterparts, social networks or completely new application concepts are gaining popularity and market share. But the rise in popularity is matched with a rise in reports of security-related incidents. My thesis is about introducing security-enhancing changes into open source projects.

Most web application weaknesses are well understood, at least the popular ones. Nevertheless, the 2007 OWASP report of the top 10 web application vulnerabilities ranked SQL Injection Attacks (SQLIA) and Cross-Site Scripting (XSS) as the top two.

My diploma thesis will give an analysis of the threats of SQLIA and XSS and the technical background. I will then present the most common mitigations found in use.

Good mitigations exist for SQLIA and XSS weaknesses, but they have to be used thoroughly throughout the code. To prevent vulnerabilities, potentially dangerous data may only be used through known safe means. In practice, many vulnerabilities enabling SQLIA, XSS, or similar attacks, result from the inconsequential use of prevention measures. It is therefore important to abstract known good practices and only access data throughout these abstractions.

Open source projects usually use an evolutionary, iterative approach to development. Security fixes are often ad-hoc fixes that fix the immediate problem area but don't eliminate the underlying general problem. It is especially hard for open source projects to make large scale changes to existing code or even to change the application architecture. Many effective vulnerabiliy preventions -- like the above-mentioned abstraction of known good access methods -- rely on certain architectural properties, making them harder to adopt for open source projects.

I will discuss a practice to gradually introduce non-trivial code changes to benefit application security into open source projects. Non-trivial changes in this discussion are code changes which are not isolated to one location but need to be applied throughout the code. My approach is based on annotations and code reviews and should improve motivation (to fix things), awareness (of the existence of problems), and metrics ("how far are we in the overall code change?"). I will then propose that technique to one (or, time permits, more) open source project(s) for improving one specific aspect of their security architecture.

The section on further research will include thoughts on how to generalize the technique to other security-related changes and other types of non-trivial changes in open source projects.