The Burp Suite User Forum was discontinued on the 1st November 2024.

Burp Suite User Forum

For support requests, go to the Support Center. To discuss with other Burp users, head to our Discord page.

SUPPORT CENTER DISCORD

Is Burp Infiltrator working?

Jeff | Last updated: Dec 11, 2016 11:00PM UTC

I think I'm using Burp Infiltrator correctly but I don't believe that I'm not seeing any Infiltrator results in the Issues. I'm testing against the WebBank vulnerable demo project (https://github.com/pentestingforfunandprofit/webbank) and from an Active Scan get 'Certain' SQL Injection, Xpath Injection, XXE, XML Injection, DNS and HTTP collaborator interaction, etc. but no Infiltrator results in those that I can see. When I run infiltrator, it processes all the jars, wars, and classes in the target dir and nothing is recompiled before it runs. Am I looking in the wrong spot for Infiltrator results? Could none of the sinks really be in there (I'm infiltrator generated using 1.7.13). Best case, could someone clone webbank and try it with Infiltrator to see if you get better results?

PortSwigger Agent | Last updated: Dec 12, 2016 10:04AM UTC

When you run the Infiltrator installer on your application bytecode, do you see modifications being made to the actual class files within the relevant JAR/WAR files? It might be worth unpacking the archives before and after you run the Infiltrator installer, to compare individual files and confirm that the patching process is working correctly. Also, do you see any errors or other relevant output during the patching process?

Burp User | Last updated: Dec 12, 2016 12:02PM UTC

No errors, just all the processing lines. I see the net.portswigger.infiltrator classes inside the war too. Not sure where I should be looking for any of the other instrumentation it makes.

PortSwigger Agent | Last updated: Dec 13, 2016 10:45AM UTC

We are currently investigating this issue and will update you soon.

PortSwigger Agent | Last updated: Dec 13, 2016 11:13AM UTC

In order to use Burp Infiltrator with JSP applications one needs to take a few additional considerations into account. In this particular case you are looking at an application that can be built and deployed using Maven, more specifically it uses the Jetty plugin to run local instances. Jetty in turn uses Jasper as its default JSP implementation. Note that different JSP implementations support different features and may behave differently, but we will stick to Jasper as an example of what you may find in a real world application. The first thing one needs to know is that JSPs get translated into servlets that are behaviourally equivalent. That is to say, they get translated into Java code that is then compiled into bytecode, which is what Burp Infiltrator works with. The moment in which a particular JSP gets translated and compiled depends on the way the application is built: One way to do this is to trigger the process on demand and cache the resulting bytecode until a change is made to the JSP. In this case you won't be able to use Infiltrator because the app has to be instrumented before it is deployed. Nevertheless, applications are not expected to change often in production and so it is quite common for JSPs to be precompiled before deployment. Luckily, WebBank uses the Jetty JSPC Maven plugin to precompile its JSPs which results in bytecode being generated beforehand. On the other hand WebBank uses JSTL which provides a set of methods to deal with SQL transactions, string formatting and XML processing, hence the type of issues that Burp finds when you run the active scan. JSTL sinks have not yet been added to Burp Infiltrator and they'll make a great addition in one of the next releases!

PortSwigger Agent | Last updated: Dec 13, 2016 03:03PM UTC

Let us know if you identify any other data that is relevant. We're going to work on improving Infiltrator's handling of this type of application, and we expect to have some updates available within the coming weeks.

Burp User | Last updated: Dec 13, 2016 04:27PM UTC