Aug 112016
 

BurpFor my daily work as a pentester and especially during my recently taken OSCP exam PortSwigger’s Burp Suite was and still is an invaluable tool. Beside many other things it allows one to intercept web traffic between one’s browser and a web server. Thereby web request can be reviewed or even modified. You can check out the homepage for more details.

However, under OS X there are two quirks that drive me crazy. Both are not directly related to Burp itself, but to the fact that it is distributed as a Java Archive (jar).

burp_jar1The first is, JARs are simply not considered first-class applications any more. That means they can’t be pinned to the Dock (the part to the right of the spacer simply does not count!) and they are categorized not as Applications but within the Developer section.

The second issue is that the generic JAR icon is used. As I’m often running more than one Java process it is impossible to differ them only from looking at the Dock.

To fix this issues I built Burp.app: A small AppleScript wrapper around the original Burp Java Archive. It smells, feels and behaves more like a native OS X application but still runs the unmodified JAR in the background.

Simply download the latest version from Github and put it into the Applications folder. Then download the lastest available Burp version and drop it onto Burp.app. Thereby this version is wrapped into the application. This process can also be used to update the currently wrapped version. After that you can delete the JAR and enjoy your new OS X version of Burp.

The following screenshot shows Burp.app in fully glory.

Screen Shot 2016-08-11 at 18.08.49

I already actively used Burp.app for more than a year. However, if you encounter any bugs or if you have any suggestions just let me know using the comments below.

Apr 102015
 

We are using Acunetix’s Web Vulnerability Scanner to help us automatically test web applications for SQL injection, cross-site scripting and other vulnerabilities. To scan login protected areas the Web Vulnerability Scanner features the so called Login Sequence Recorder. It basically recordes all the HTTP requests necessary to login and replays them whenever the current user session was terminated.

This works great as long as there is no CAPTCHA and no CSRF token. If any of those two is used we have to manually take action by using another feature called Manual Intervention. It basically opens a web browser window with the current site’s login already preloaded and you are requested to proceed manually until the user session is successfully reestablished. This is quite annoying as you have to re-login several hundred times if the application aggressively terminates user sessions.

With Sikuli we can now automate the scan even with CSRF secured logins. Check out this video to get a rough overview about what Sikuli is all about. We will use it to script the necessary mouse and keyboard actions needed for logging into the web application and execute them everytime the user session is destroyed.

Below is a workflow I used for my last vulnerability scan: At first we wait for the Manual Intervention window to appear and then we click into the username field and type the corresponding name. We repeat this actions for the password. Then we submit the form and wait until the login vanished. Finally, we close the window by clicking Done. Thereby we created a new user session and the scan continues. By using this workflow you can completely automate the login of CSRF protected web applications.

Sikuli Workflow