raises it’s ugly head

I’ve ran into another small set back. This time it’s called the

Compare the following results:

java -DTAINT_LOGGING=true -DTHROW_EXCEPTION=true -Xbootclasspath/p:build/distributions/SecuRT-1.0-shadow.jar -Dfile.encoding=UTF-8 -ea -cp ~/.gradle/caches/1.10/workerMain/gradle-worker.jar org.owasp.securt.StandaloneTest

Error occurred during initialization of VM
java.lang.InternalError: Could not create SecurityManager:
at sun.misc.Launcher.(
at sun.misc.Launcher.(
at java.lang.ClassLoader.initSystemClassLoader(
at java.lang.ClassLoader.getSystemClassLoader(

and (what I want to happen):

java -DTAINT_LOGGING=true -DTHROW_EXCEPTION=true -Xbootclasspath/p:build/distributions/SecuRT-1.0-shadow.jar -Dfile.encoding=UTF-8 -ea -cp ~/.gradle/caches/1.10/workerMain/gradle-worker.jar org.owasp.securt.StandaloneTest

Exception in thread "main" org.owasp.securt.TaintException: Taint detected
at org.owasp.securt.AbstractTaintUtil.markTaint(
at org.owasp.securt.TaintUtil.checkTaint(
at org.owasp.securt.StandaloneTest.main(

Unfortunately the firsts result happens when you try to run your tests from Gradle. In other words, I have to investigate the relationship between the security.manager and the bootstrapclassloader. Maybe tomorrow will shed some light on a solution.
By the looks of it, I’m not the only one with this problem.

After the silence

I’ve been silent a long time. I know. I’m sorry.
I’ve been very busy with my ordinary work, family and OWASP, so this project had to take a back seat. But that didn’t meant that it was completely forgotten.

As I’ve spoken in my previous post I’m dabbling with Gradle as a built environment, which is quite a relief compared to ant or Maven (although I haveĀ  to admit that I’m reverting back to ant and Ivy as soon as stuff goes a bit wonky). Next to Gradle I’ve started with Scala as well. Which is in some perspective even a nicer language than Java itself (although Java still is my default to-go-to language).

Between my last post and this one I’ve also been trying to check any class that implements the java.sql.Statement interface. as in, I want to identify a taint trace in the next bit of code:

	public void testSQL() {
		String sql = "SELECT * FROM contacts WHERE name='"+getUserName()+"'";

		Connection connection;
		try {
			connection = DriverManager.getConnection("jdbc:hsqldb:mem:mymemdb", "SA", "");
			connection.createStatement().executeUpdate("create table contacts (name varchar(45),email varchar(45),phone varchar(45))");
			System.out.println("[*] Database created");
			Statement statement = null;
			ResultSet resultSet = null;

			statement = connection.createStatement();
			// it should fail here 
			resultSet = statement.executeQuery(sql);

			fail("Should not get here");
		} catch (Exception e) {
			System.err.println("Got an exception! ");

for a long time I had been unsuccessful, soully for the reason that I had my test setup wrong. These last months/weeks have been a learning experience about the bootstrap and the other classloaders. But most of all, I’ve learned that if you define your execution path wrong (as in, having the database jar in the bootclasspath instead of the classpath) it goes wrong.

I only discovered that by reverting back to ant and Ivy and tracking it in more detail.

Next I will clean up my code and recreate it using Gradle and also start testing with other languages. Still have to decide which language I’ll focus on next.
Perhaps I’ve played with Scala long enough to choose it as the next target.

Happy 2014 to you all (and some Gradle and SecuRT to go)

Happy new year to whomever is reading this. May it bring you security and happiness.

Today I pushed my first version onto git after playing with Gradle as my new building environment. The reason that I moved is that I like to have an environment to develop in which is flexible (like ant), but also has build in dependency management (like Maven) all into one (unlike ant combined Ivy). The fact that Maven is not really flexible to the extend that you can’t do stuff like the following:

// after first compilation, build the basic bootstrap classes
task compileJava.doLast {
    javaexec {
        classpath sourceSets.main.runtimeClasspath
        main = generator
        args = [

There are still some issues with Gradle that can be done more neatly or nicely, but for now it compiles, builds and tests the classes that I want. (if you can send me improvement, please do).

Currently I’m working in getting java.sql.Statement checked. As this is an interface you can’t just alter it, but that has to be done in runtime. I have to find a way in finding the correct class and altering that. I know it can be done through a JavaAgent, but for now I don’t want to add more ‘JVM Arguments’ to the command line. I like to keep it ‘simple’ for the intended end user.

So far, look at github and tell me what you think.,