My goal with the String meta-data is actually very simple. It should be designed in such a way that all developers/testers that are using the JVM can use it. Sort of copied from the ZAP policy “It is designed to be used by people with a wide range of security experience and as such is ideal for developers and functional testers who are new to penetration testing as well as being a useful addition to an experienced pen testers toolbox.”
The end result should be easy to use and non intrusive to existing code. For this reason I’ve started to focus on the option of customisation. If I manage to adapt the Core classes of Java in such a way that I can do taint tracing, I can create a version in which security tests can be run simultaneously to unit and integration tests.
By allowing that the security testing is executed during unit and/or integration tests that would mean that ‘ordinary’ developers can perform these tests without those pesky security testers. And by changing the base classes themselves, it would mean that the test would be non intrusive to the actual code created by the developers in the first place.
The changed base classes should not be used in production systems, but if I manage with this, perhaps those production systems would be a bit more secure.
As described in my previous post, I want to add meta-data to a String in Java. This meta-data should be used for example to mark a String as tainted (contains not validated text) from a security perspective. Unfortunately it isn’t as simple as it sounds as the Java String class has various ‘exit-points’ for it’s value, a.k.a. just marking the String class might not be enough.
We (Dinis Cruz and me) have a couple of options to investigate:
1. Customize the String class and add the taint mark to it. This means that a custom bootstrap is needed to be able to use the adapted String class.
2. Using AOP and try to make a note of the char array within the class and follow that.
3. Use JNI or JNA and mark the char array in a way.
4. Add information to the char array in memory to indicate that it contains tainted data.
There maybe other options, but we’re not aware of those (yet).
I do know that it will add tremendous value to a security test if we can demonstrate if tainted data flows through the application. This is the basis of a potential vulnerability, and if we can demonstrate this to the developers it might be mitigated before it can be abused.
Lets see if we can make this work.
The AppSec conference in Hamburg just stopped and I’m already busy again. But this time it’s not only with the CTF that I host for OWASP, but also with a new – at least I hope it’s new – idea.
And that is to improve the security position of Java. The idea is to add meta-data (like a taint flag) to the String class and by doing so manage to get source-sink tracing possible. I’m not doing this alone, but together with Dinis Cruz we’re looking into this possibility. Not to make a production alteration, but as an additional scenario during testing.
As John Willander already said, the String class is way too open for abuse. Let’s find an easier way to check this and by doing so improve the code quality.
There is nothing wrong with being ambitious.