Burp plugin: Failed to determine the scan type

[mleg...@waratek.com]

Hi all,

as a test, after installing and running the bodgeit vulnerable app (https://github.com/psiinon/bodgeit), threadfix and burp with the threadfix burp plugin, I wanted to generate a URL attack surface.

Then, I followed the directions at https://github.com/psiinon/bodgeit/

After inserting the threadfix url, the api key and selecting the project (previously associated with the github source code URL) selecting "import from threadfix"
I was asked to specify username and password several times for different jsp pages (login.jsp, register.jsp etc.). So I did specify those that allow the login of a test user.

Then under "spider" I see "Requests made: 108; Bytes transferred: 317.585" and under "target-sitemap" there's all the url from the bodgeit instance i'm running with all the get and post requests.

For a long while the amount of requests made does not change so I suppose the spider has finished working. However, when I then click on "export scan" I get a popup saying:

"The upload failed. The response code was 200 and the error message was Failed to determine the scan type"

which is weird cause 200 is the HTTP code for OK. Anyway even when I go into threadfix and check whether anything has been uploaded despite the error, I don't find anything. From catalina.out all I get is:

"INFO [http-bio-8686-exec-6] ApplicationRestController.uploadScan(272) | Received REST request to upload a scan to application 3."

as soon as i click on "export scan" and nothing is logged after that (it's the last line).

Why is the scan export not working? Any help would be very appreciated. Thank you so much!

All the best,
Myriam

[mleg...@waratek.com]

I'm using Threadfix 2.2.8 on port 8686 with Burp Suite Professional 1.6.20 on port 8080 and on my localhost where there's OpenJDK 1.7.0_25 running.

I access Bodgeit that runs on a remote machine on Tomcat 7 and port 8080.

[Mac Collins]

Hi Myriam,

Uploading a scan from Burp to ThreadFix requires the scanner module from
Burp Suite Professional. After spidering, you must conduct a scan so that
Burp has issues.Our plugin should detect whether a scan has been conducted
and display an error at that point instead of allowing the user to submit
a scan anyway. I've filed a couple issues to address this in the actual
tool and in the documentation.

https://github.com/denimgroup/threadfix/issues/1219

https://github.com/denimgroup/threadfix/issues/1220


Thanks,
Mac

On 6/30/15, 10:57 AM, "thre...@googlegroups.com on behalf of
mleg...@waratek.com" <thre...@googlegroups.com on behalf of

>--
>You received this message because you are subscribed to the Google Groups
>"ThreadFix" group.
>To unsubscribe from this group and stop receiving emails from it, send an
>email to threadfix+...@googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

[mleg...@waratek.com]

Hi Mac,

thanks a million, it works now!

However, does this mean that Threadfix uses the URL attack surface that Burp generates? I'm asking cause I had thought that Threadfix generated its own attack surface (that's why I hadn't expect to run Burp scanner directly).

Thanks,
Myriam

[opensamm....@gmail.com]

Burp uses the attack surface to get a better spider/crawl of an application and therefore - hopefully - a more thorough scan. This potentially allows Burp to find more vulnerabilities.

Those vulnerabilities can then, optionally, be exported into ThreadFix for management (conversion to bug tracker tickets, etc) Or they just leave you with a better Burp scan than you would have had otherwise.

So - the Burp plugin can be used independently of a ThreadFix server installation. Or Burp can be used in conjunction with ThreadFix for management of vulnerabilities found by Burp.

We probably don't do a great job of explaining these two potentially-related, but not-necessarily-related use cases in the Burp plugin docs (and UI) so we're looking to tighten that up.

Thanks,

Dan