CodeMagi Blogs

Running Multiple Burp Suite Instances

If using the OSX application version of Burp Suite, you can launch multiple instances using the following command: 

open -n -a "Burp Suite Professional"

Burp Suite Passive Scanning

I recently had an interesting discussion regarding when Burp Suite actually runs its passive scan tests. It turns out that passive scanning is only done in certain instances and NOT on every singe response as I had previously imagined. Here are the conditions under which passive scan checks are run: 

  • First request of an active scan
  • Proxy requests
  • Any time 'Do a passive scan' is selected from the context menu

Passive scans are not run: 

  • On every active scan response
  • On Repeater responses
  • On Intruder responses
  • On Sequencer responses
  • On Spider responses
This is a pretty huge gap as far as I am concerned -Especially for active scanner responses where fuzzing is more likely to throw an error message that can be picked up by my Error Message Checks extension, or reveal server information that can be picked up by Software Version Checks.

I have updated Error Message Checks to scan responses during Active Scan, and I will soon be adding selectable capability to passively scan responses for other tools as well. 

 

PreparedStatement performance

Whenever I teach secure coding I always tell students that in addition to protecting you from SQL Injection, using PreparedStatement also gives you a performance improvement since the JDBC driver pre-compiles the SQL execution plan and re-uses it again and again. Very often I get the follow up question, "How much performance improvement?". I wanted a definitive answer, so I did a little test: 

I found of list of the 5,163 most popular first names, with their percentage, cumulative percentage, and rank and created a table in PostgreSQL: 

testdb=# \d test_table;
                                  Table "public.test_table"
   Column   |         Type          |                        Modifiers                       
------------+-----------------------+---------------------------------------------------------
id         | bigint                | not null default nextval('test_table_id_seq'::regclass)
name       | character varying(32) |
 percent    | double precision      |
 cumulative | double precision      |
 rank       | integer               |
Indexes:
    "test_table_pkey" PRIMARY KEY, btree (id)

First I tried concatenated SQL:

for (int i = 0; i < insertData.getNumRows(); i++) {
    String sql = " INSERT INTO test_table (name, percent, cumulative, rank) VALUES ('" + insertData.getItem(i, 0) +
            "', " + insertData.getFloat(i, 1) + ", " + insertData.getFloat(i, 2) + ", " + insertData.getInteger(i, 3) + ")";
 
    Statement stmt = conn.createStatement();
    stmt.executeUpdate(sql);
}

I tried re-using a single PreparedStatement many times:

String sql = " INSERT INTO test_table (name, percent, cumulative, rank) VALUES (?, ?, ?, ?)";
PreparedStatement stmt = conn.prepareStatement(sql);
 
for (int i = 0; i < insertData.getNumRows(); i++) {
    stmt.setObject(1, insertData.getItem(i, 0));
    stmt.setObject(2, insertData.getFloat(i, 1));
    stmt.setObject(3, insertData.getFloat(i, 2));
    stmt.setObject(4, insertData.getInteger(i, 3));
    stmt.executeUpdate();
}

Finally, for comparison I tried using a PreparedStatement that was initialized inside of the for loop: 

for (int i = 0; i < insertData.getNumRows(); i++) {
    PreparedStatement stmt2 = conn.prepareStatement(sql);
    stmt2.setObject(1, insertData.getItem(i, 0));
    stmt2.setObject(2, insertData.getFloat(i, 1));
    stmt2.setObject(3, insertData.getFloat(i, 2));
    stmt2.setObject(4, insertData.getInteger(i, 3));
    stmt2.executeUpdate();
}

The results show that:

INSERTED 5163 concatenated in 3437
INSERTED 5163 prepared (re-used) in 2373
INSERTED 5163 prepared (per-iteration) in 3043

Re-using a single PreparedStatement multiple times is 44% faster than using concatenated SQL, and 28% faster than a new PreparedStatement per iteration. Even per-iteration PreparedStatement beats concatenated SQL by 13%. Re-using a single PreparedStatement is clearly the way to go for performance (and security).

Note that this is for Postgres –other JDBC drivers might use different strategies for caching execution plans.

Customizing Burp Suite - AppSec USA 2105 Presentation

My OWASP AppSec USA 2015 presentation with Monika Morrow, Customizing Burp Suite - Getting the Most out of Burp Extensions is now on SlideShare:

http://www.slideshare.net/AugustDetlefsen/appsec-usa-2015-customizing-burp-suite

This lecture gives pentesters and security tool developers an overview of the APIs available to extend the Burp Suite intercepting proxy. Using open-source examples developed by the authors we illustrate a number of key areas for anyone wishing to create extensions:

  • Passive scanning
  • Active scanning
  • Identifying insertion points
  • Request modification
  • Customizing the Burp GUI

The presentation includes code samples and links to actual open source Burp Suite plugins developed by the author.