Getting Started with Burp - Part 5: The Intruder Tab

Burp Intruder is a powerful tool that allows you to automate both canned and customized attacks against web applications. If you are using Burp Community Edition, Intruder has time constraints on it that limit its usefulness. With that said, even a restricted version of Intruder is useful. If you want the un-throttled version of this tool, however, you will need to pony up some dough and buy the Burp Suite Professional.

Burp Intruder has a number of configuration options and it can be used to perform many different types of attacks. In the future, I will try to put out a post that covers some more advanced uses of Intruder. For the purposes of this post, however, we will perform a basic test against or JuiceShop instance that is hosted at Heroku. You can learn more about the Intruder tab at I highly recommend spending time reviewing this page, as it provides a great deal of information about some of the more advanced features of this tool.
  1. With your browser running through Burp Suite, go to Try to log in with any properly formatted email address and password.

    Warning: if you enter a single quote, you will find that the login form is vulnerable to SQL injection. Avoid doing so for the time being, as we will be using Burp Intruder to identify that vulnerability.

  2. In Burp, click the History tab found inside the Proxy tab.

  3. Find one of the POST entries hat contains Right-click on the entry and click “Add to scope.”

  4. In the window that appears, choose “Show only in-scope items.” This will eliminate any other out-of-scope requests and responses from showing up in the history.

  5. Find the form POST from step 3 in the proxy history. Once found, right-click it and choose “Send to Intruder."

  6. Click on the Intruder tab. You will see a new tab with the JuiceShop URL listed in the Target sub-tab.

  7. Click the Positions sub-tab. Notice that some of the parameters or highlighted and enclosed in ‘§’ symbols. These are the parameters that Intruder will attempt to attack. Highlight each parameter except for email, and then click the Clear button. Leave the email parameter enclosed in the ‘§’ symbols.

  8. Click the Payloads sub-tab. We will want to try to use a SQL injection payload list. For the purposes of this exercise, download the file to Load it into the Payload Options window.

  9. Click the Options sub-tab and review the options there. At this time, do not make any changes. Click the Start Attack button when finished.

  10. The attack runs. Longer attacks would be throttled in the Community Edition of Burp, but for our purposes this works fine. Notice the results: there are a number of 401 responses as well as some 500 responses. What do these mean?

  11. Click on one of the 500 responses and look at the server response. Note that a SQL error was returned. This indicates that the application is most likely vulnerable to SQL injection. Try a few of the attempts in the login screen. Do any work?

  12. Try the username 1’ or 1=1 --. What happens?

  13. This is an example of SQL Injection authentication bypass. Why did it log us in as the administrator and not some other account?


Post a Comment

Popular posts from this blog

OWASP ZAP Tutorial - Part 2: Crawling

OWASP ZAP Tutorial - Part 1: Intercepting Traffic

OWASP ZAP Tutorial - Part 3: Scanning