Selenium for Web App Pentesting

There is a uptick in brute force attacks as related to web applications. The Web Hacking Incident Database keeps track of many attacks, and compiles the results; they show that insufficient anti-automation (which includes DoS attacks, but I won’t be covering that today) are the number one cause of web site incidents.
Using brute force methods are an old standby, and many of the attack proxies offer fantastic brute force abilities. But I always find myself wanting more control, the ability to tweak things, and more intelligent functionality. Unfortunately most of these apps are pretty rigid in the actions they can perform–if the developer didn’t think of what you want to do you are out of luck. In these cases it isn’t so uncommon to find myself writing code in PERL, shell, PHP, Javascript, and whatever else I find I need to pull off a specific test case.
Some web apps are really complex, or occasionally someone even develops an application with good session management designed to resist attack. I recently came across an application that did just this. The login page invalidated the user’s session, and deleted the cookies each time the page was loaded (assuming a login failure.) In addition to this, it had CSRF protections in place, so the form had nonce values, which were tied to the session (no reuse.) If the session and nonce weren’t validated the application threw a security warning and didn’t process the attempted login. Performing a successful brute force attack against this setup poses a few challenges. And neither ZAP nor Burpsuite were meeting my needs (still love em though.)
This is where Selenium comes in very useful. Selenium is a test framework, mostly used by developers and QA test folks. It has very good potential for pen-testing too. It is designed so that you can create a customized brute force attack script in just minutes, that would have otherwise taken hours to accomplish. It runs it through a full featured web browser (usually FireFox, but has other hooks too) so that stuff like tracking application state, nonces, sessions, properly setting referrers and the myriad other crazy dependencies that can arise in a complex web application are handled seamlessly. Basically it allows you to automate a web browser.
I’ll give a quick demo on BackTrack Linux (Ubuntu based.) Here is the overview:

Record a sample login in Firefox, add some conditional checks to test for failure.

Export the test case as a PERL script.

Modify your exported PERL script to your liking.

Run the script through the Selenium server.

Step 1:

If your FireFox browser isn’t configured to allow add-on installation from unknown sources, you can just right click the XPI file and select “save as”. Once it’s downloaded you can manually add it from the mozilla add-ons screen.

Just for demonstration purposes, I’ll do a very simple test against wordpress. The goal of this specific attack is to see if I can determine the existence of a login name based upon the message received after a failed login.
First through the Selenium-IDE add-on I record a failed login for a valid username, and setup a condition that tests for the resulting error message. You do this by opening the add-on from the “tools” menu, and then login. Once the login has failed, you select some text that is presented and add a test (assertTextPresent,) that’s pretty easy.
Open Selenium-IDE and ensure that you are recording.
Perform the login, and select the text that indicates the login was unsuccessful.
Run the test case to ensure it does what you want.
Now, export the test case as a PERL script.
Here is the generated script:

This is a very simple example. Like I mentioned before, Selenium is really only necessary when you are up against some serious session management that you really need a full browser for. It’s slower than say Burp suite’s repeater, or just shell scripting curl. But, it’s pretty cool when you can still perform timing attacks against an application that uses session validating and nonces to make it difficult.