Early Vulnerability Detection for Supporting Secure Programming

I recently finished my master’s degree. Now I am sharing my dissertation so other people can continue the work I started.

Secure programming is the practice of writing programs that are resistant to attacks by malicious people or programs. Programmers of secure software have to be continuously aware of security vulnerabilities when writing their program statements. They also ought to continuously perform actions for preventing or removing vulnerabilities from their programs. In order to support these activities, static analysis techniques have been devised to find vulnerabilities in the source code. However, most of these techniques are built to encourage vulnerability detection a posteriori, only when developers have already fully produced (and compiled) one or more modules of a program. Therefore, this approach, also known as late detection, does not support secure programming but rather encourages posterior security analysis. The lateness of vulnerability detection is also influenced by the high rate of false positives, yielded by pattern matching, the underlying mechanism used by existing static analysis techniques. The goal of this dissertation is twofold. First, we propose to perform continuous detection of security vulnerabilities while the developer is editing each program statement, also known as early detection. Early detection can leverage his knowledge on the context of the code being created, contrary to late detection when developers struggle to recall and fix the intricacies of the vulnerable code they produced from hours to weeks ago. Our continuous vulnerability detector is incorporated into the editor of an integrated software development environment. Second, we explore a technique originally created and commonly used for implementing optimizations on compilers, called data flow analysis, hereinafter referred as DFA. DFA has the ability to follow the path of an object until its origins or to paths where it had its content changed. DFA might be suitable for finding if an object has a vulnerable path. To this end, we have implemented a proof-of-concept Eclipse plugin for continuous vulnerability detection in Java programs. We also performed two empirical studies based on several industry-strength systems to evaluate if the code security can be improved through DFA and early vulnerability detection. Our studies confirmed that: (i) the use of data flow analysis significantly reduces the rate of false positives when compared to existing techniques, without being detrimental to the detector performance, and (ii) early detection improves the awareness among developers and encourages programmers to fix security vulnerabilities promptly.

If you want to read the whole dissertation, you can download it here. I would love to receive your feedback about it.

Early detection; security vulnerability; data flow analysis; secure programming.

Which methods should be considered “Sources”, “Sinks” or “Sanitization” ?

One thing I noticed when I first started testing security applications, was that each one, had their own understanding of what is a security vulnerability and which methods should be verified and flagged as vulnerable. I later found out this page (https://www.owasp.org/index.php/Searching_for_Code_in_J2EE/Java) on OWASP. It contains some methods that should be sanitized but I believe it is not the full list.

So, I have created my own list from what I found on other applications, blogs and etc and I was wondering if you (my reader) could help me make this list perfect. If we manage to do this, I think it would be great to update OWASP page. What do you think ?

With this list of methods I performed an evaluation on 5 applications (BlueBlog, PersonaBlog, WebGoat, Roller and Pebble) using 4 Eclipse plug-ins (ASIDE, CodePro, Lapse+ and ESVD(my plug-in)). I got some very promising results. I am really excited.

Do you think there are methods missing or some of these methods should be removed from the list ?

My plug-in is still a prototype but I am receiving some very good feedback. You can see more on:
01 – early-vulnerability-detection-supporting-secure-programming
02 – https://marketplace.eclipse.org/content/early-security-vulnerability-detector-esvd/

My list of “Sources“, “Sinks” and “Sanitization” methods:

Continue reading Which methods should be considered “Sources”, “Sinks” or “Sanitization” ?

Early Vulnerability Detection for Supporting Secure Programming

Dear reader,

I was wondering if you could spend some minutes of your precious time by helping me. As part of my dissertation entitled “Early Vulnerability Detection for Supporting Secure Programming“, I developed an Eclipse plug-in (still just a prototype) that performs security vulnerability detection while the developer is creating/editing the source code.You can install the plug-in as you usually do when working with Eclipse, however, if you have any doubts on “How to Install the plug-in”, there is a How-To in the attached pdf.

The plug-in’s link:

You can test the plug-in with some of your own projects, however, if you want you can download, import and test a sample project created by me which contains dozens of known security vulnerabilities. More about this project in the attached pdf.

The sample’s link:

I would really appreciate your feedback on regards to ANYTHING. The images used, the text to inform the vulnerabilities, the options provided by the plug-in, the English words, false positives, false negatives and anything else that comes to your mind.

Supported vulnerabilities:

01 – Command Injection
02 – Cookie Poisoning
03 – Cross-Site Scripting (XSS)
04 – HTTP Response Splitting
05 – LDAP Injection
06 – Log Forging
07 – Path Traversal
08 – Reflection Injection
09 – Security Misconfiguration
10 – SQL Injection
11 – XPath Injection

Tutorials about the plug-in.
How to Install the plug-in / User Interface / WebDemo Project

Thank you in advance,
Luciano Sampaio