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

Sharing Eclipse preferences with your teammates

If you write Java code and works with Eclipse, you probably know that Eclipse allows you to change many of its default preferences, but once you’ve done that you will not want to do it again and again every time you change a computer or when there is a new teammate on your team, right?

Well, Eclipse allows you to export and import these preferences helping you not waste time.

To export you need to do the following:

Continue reading Sharing Eclipse preferences with your teammates

Security vulnerabilities: should they be early detected?


Whether you are a developer and/or just a normal user, if I ask you: What is a good software? What are the first thoughts that come to your mind? “Easy to use”, “Fast”, “Easy to update”. Am I right? Well, you probably thought about these ones because they are easy to spot, if a software is slow to perform a task or the “send” button is nowhere to be found, anyone can noticed that, but what about security? Can you tell if a software is secure and no one can hack it?

According to the OWASP, these are The Ten Most Critical Web Application Security Risks.

  1. (SQL/Command) Injection;
  2. Broken Authentication and Session Management;
  3. Cross-Site Scripting (XSS);
  4. Insecure Direct Object References;
  5. Security Misconfiguration;
  6. Sensitive Data Exposure;
  7. Missing Function Level Access Control;
  8. Cross-Site Request Forgery (CSRF);
  9. Using Known Vulnerable Components;
  10. Unvalidated Redirects and Forwards;

Continue reading Security vulnerabilities: should they be early detected?