Database gets into a knot after scanning about benchmarkjava

[davewichers]

Can you be more specific about how it �gets in a knot¹. Why don¹t you reply
to me off list at [email protected].

We have not scene this behavior and would like to �fix¹ the Benchmark so it
doesn¹t do this if at all possible.

We could also provide a �hidden¹ reset link like you suggest. We¹d hide it
so scanners don¹t try to attack that URL too. But I¹d like to try to
eliminate the cause of the problem in the first place if there is indeed a
problem.

What tool were you scanning the Benchmark with?

-Dave

From: ElColmo [email protected]
Reply-To: OWASP/Benchmark
<reply+004c5b05e94db160af1c2a1cdc1708c35f7dbce00d39f8b692cf00000001121157dc9
[email protected]>
Date: Wednesday, September 16, 2015 at 12:16 PM
To: OWASP/Benchmark [email protected]
Subject: [Benchmark] Database gets into a knot after scanning (#10)

The Hypersonic database behind the scenes gets in a knot when it's actively
tested with vulnerability assessment tools. This makes it impossible to
dynamically detect or exploit even obvious SQL Injection vulnerabilities
(using either manual or automated techniques), in some cases.

What I suggest is needed is a URL that the tester can request to "normalise"
the database periodically (in between test cases, for instance). Note that
re-starting the Tomcat instance has this effect, by virtue of re-creating
the HSQL database from scratch (using the code in
src/main/java/org/owasp/benchmark/helpers/DatabaseHelper.java), but this is
an extremely heavyweight approach, and is not suitable for integrating into
an automated vulnerability assessment test of a scanner.

�
Reply to this email directly or view it on GitHub
https://github.com/OWASP/Benchmark/issues/10 .

[ElColmo]

I annotated some of the code, and have some more details. Some of the URLs, when requested, appear to "lock up". For instance "/benchmark/BenchmarkTest02633" becomes completely non-responsive after scanning.

The cause appears to be the call to prepareStatement:

java.sql.PreparedStatement statement = connection.prepareStatement( sql,
java.sql.Statement.RETURN_GENERATED_KEYS );

After a period of scanning, this method call doesn't return (at least, not within a few minutes). I'm not sure I see the advantage of using a prepared statement in this case anyway, since the point is to make a specific parameter SQL injectable.

My test call is the following:
time curl -k "https://localhost:8443/benchmark/BenchmarkTest02633?password=ZAP&username=ZAP&vector=bar"

I've modified the source code to "/src/main/java/org/owasp/benchmark/testcode/BenchmarkTest02633.java", as follows, to see the results noted above in the Benchmark console:

...
String sql = "SELECT * from USERS where USERNAME=? and PASSWORD='"+ bar +"'";
System.out.println("BenchmarkTest02633: SQL statement is ["+ sql + "]");

            try {
                    System.out.println("BenchmarkTest02633: Getting connection");
                    java.sql.Connection connection = org.owasp.benchmark.helpers.DatabaseHelper.getSqlConnection();
                    System.out.println("BenchmarkTest02633: Got connection: "+ connection);
                    java.sql.PreparedStatement statement = connection.prepareStatement( sql,
                        java.sql.Statement.RETURN_GENERATED_KEYS );
                    System.out.println("BenchmarkTest02633: Got statement");
                        statement.setString(1, "foo");
                    System.out.println("BenchmarkTest02633: Parameter set");
                    statement.execute();
                    System.out.println("BenchmarkTest02633: Executed statement");
        org.owasp.benchmark.helpers.DatabaseHelper.printResults(statement, sql, response);
            } catch (java.sql.SQLException e) {
                    System.out.println("BenchmarkTest02633: Exception");
                    e.printStackTrace();

                    if (org.owasp.benchmark.helpers.DatabaseHelper.hideSQLErrors) {
                    response.getWriter().println("Error processing request.");
                    return;
            }
                    else throw new ServletException(e);
            }

...

[davewichers]

I believe this has been fixed long ago. If you see this behavior again, please open a new ticket.