Automated Burp Security Scanning with BDD-Security

If you’ve been following along with the previous set of posts about the BDD-Security framework, you’ll know that it relies on Selenium scripts to navigate the application. Wouldn’t it be great if you could use that existing navigation code to populate Burp scanner, then perform the security scan and have the results integrated in the BDD reporting? Read on to find out how 🙂

BDD-Security makes use of the resty-burp tool to communicate programmatically with Burp. You’ll need to have resty-burp downloaded and installed, together with a licensed commercial version of Burp scanner in order to perform the automated scanning. Resty-burp is a maven project so is started with the usual:

mvn exec:java

If you prefer you can even run Burp and resty-burp on a different host than BDD-Security, just update the IP address in the burp section of the config.xml file.

With that out the way, we can get on with configuring the BDD-Security side of things. In the previous post we added 3 short methods to the TeamMentorWSApplication class:
– listUsers()
– createArticle()
– and createUser()

They were created to perform the authorisation tests, but we can re-use them for burp scanning. Since the admin user is permitted to call all of those methods we’ll wrap them all into a single method and annotate it with the @SecurityScan annotation:

public void adminWorkflow() {

You can annotate any number of methods with @SecurityScan, and they’ll also be used for burp scanning- the only requirement is that they don’t have parameters.

We can now run the automated_scanning.story and inspect the results.

Most of the tests pass, but Burp reports two potential XML injection vulnerabilities.

At this point, we would manually inspect these issues to see whether they’re real or false positives. In this case, they’re false positives so we can add exceptions so that they don’t show up in future test runs by modifying the filterIssue method in net.continuumsecurity.reporting.BurpAnalyser:

public ScanIssueBean filterIssue(ScanIssueBean issue) {"Start Burp Issue filtering:");
	if ("Session token in URL".equalsIgnoreCase(issue.getIssueName())) {
		//If the session ID is not in the URL, then this is a false positive
		if (Utils.extractSessionIDName(issue.getIssueDetail()) == null) {"session IDs not found in the burp detail, filterIssue() returning null. "+issue.getIssueDetail());
			return null;
	if ("Cookie without HttpOnly flag set".equalsIgnoreCase(issue.getIssueName())) {
		//This test is already defined in the session management scenario"HttpOnly issue found, ignoring as it's already defined in a BDD test");
		return null;
    if (issue.getIssueDetail().contains("xmlns XML attribute appears to be vulnerable to XML injection")) {"Ignoring xmlns XML attribute false positive");
        return null;
    if (issue.getIssueDetail().contains("The xmlns:soap XML attribute appears to be vulnerable to XML injection")) {"Ignoring xmlns:soap attribute xml inj false positive");
        return null;
    }  "Stop Burp Issue filtering.");
	return issue;

The last 2 “if” statements are used to ignore these XML issues. Re-running the scan will show that all the scenarios in the automated_scanning.story pass.

This entry was posted in UnitTests, WebServices and tagged , . Bookmark the permalink.

4 Responses to Automated Burp Security Scanning with BDD-Security

  1. Thanks Stephen. This is clearer now and what you mentioned last time about NOT needing an EC makes sense. A developer [Mr.D] can simply run the ‘automated scanning story’ and look at the results. Now each bit in the story (LDAP,XML blah) is explained in english so he knows what the story is doing and can understand the results better.

    Now as you mention say the app is vulnerable to XML Injection. Now Mr. D looks at it and thinks… Ohh Xml Injection…not good; I need to protect against it. Now what though? As in, he knows how to use Burp, he knows how to interpret the results (its easier now due to the English writing) and now needs to find out WHERE (could be multiple) the vulnerability lies…and WHAT to write to mitigate it. Does BDD help here as well? If Thanks.

    • stephendv says:

      I think at the point that Burp starts reporting vulnerabilities, it may mean that the developer will need to contact a security person to determine if the risk is real or not. Depending on their familiarity with security, some developers may be able to inspect XSS and SQL inj vulnerabilities reported by Burp themselves- but for XML injection and some of the less well known issues, they may need to ask for a security specialists help.

      As for the question of how to fix the vulnerability, he could consult TeamMentor! 😉 Each scenario can have any number of “@” tags associated with it, currently most of them have a @Reference tag which is a URL to a WASC article describing the flaw. So if the developer is using TeamMentor, they could add @Reference tags that point to teammentor articles.

      In terms of the process, it could go something like:
      – Dev runs BDD-sec, and sees an issue reported by Burp that they don’t understand.
      – Dev contacts security specialist to inspect it
      – Security specialist determines if it’s real or a false positive and then edits the BurpAnalyser if it’s the latter, so that it doesn’t show up again.
      – If it’s a real issue, the dev consults the URL in the @Reference tag and figures out how to fix the flaw (or asks the security specialist)
      – Dev can continue to run the BDD-Sec tests after every build to re-check any new code

      • Yeah. Makes sense. So if I were to sum up in 1 line…would…

        “BDD helps a developer understand the risks his application is exposed to more clearly; before OR after development, than if we was given a PDF report with categorized vulnerabilities by a security specialist who only breaks things”

        …… make sense? Coz its best used as early in the dev life cycle as possible…before things are even broken. What would you say?

  2. stephendv says:

    Yeah, that about sums it up. 🙂

    I would say though, that a PDF report from a knowledgeable application security expert will usually be “clearer” than a set of BDD-Security tests. The difference is that it’s not really feasible for that expert to perform a manual test and issue a new PDF report after every build of the application.

    That’s where an automated framework shines: continuous and affordable security testing.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s