Burp Suite User Forum

Create new post

JUnit test with Burp Extensions

t1n | Last updated: Sep 14, 2015 03:48PM UTC

Hi, I'm developing a Burp Extension and want to add some testing. Is there a way to create IHttpRequestResponse objects manual? Or retrieve callbacks during a JUnit test, without starting Burp. I do not really know what to do. Thanks for your help!

PortSwigger Agent | Last updated: Sep 15, 2015 11:28AM UTC

All of the custom objects used in the Burp API are interface types, like IHttpRequestResponse. For test purposes you can either: - Create your own class that implements any required interface - Use a mocking framework like Mockito to mock the required object You can do this with the callbacks object itself, so you can use a fake or mock instance of Burp in your tests.

Anthony | Last updated: Aug 17, 2023 04:20PM UTC

This seems like a crazy amount of overhead for writing simple test cases. I'm trying to create a list of HttpRequestResponse objects with the Montoya API to double-check that my passive scans work correctly with the expected objects. I can't use the static constructors of any objects since the MontoyaObjectFactory is null until the extension is added to burp. Is there any other recommended solution?

Hannah, PortSwigger Agent | Last updated: Aug 18, 2023 12:25PM UTC


You shouldn't need the MontoyaApi object to create HttpRequestResponses - you can just create these as needed.

For example:
void givenAnHttpRequestResponseThenRunAPassiveScanCheck()
    HttpRequest request = HttpRequest.httpRequest("GET / HTTP/1.1\r\nHost: portswigger-labs.net\r\n\r\n");
    HttpResponse response = HttpResponse.httpResponse("test");

    HttpRequestResponse requestResponse = HttpRequestResponse.httpRequestResponse(request, response);

    List<AuditIssue> expectedAuditIssueList = List.of(AuditIssue.auditIssue(

    ScanCheck scanCheck = new MyScanCheck();
    AuditResult result = scanCheck.passiveAudit(requestResponse);


Anthony | Last updated: Aug 18, 2023 03:25PM UTC

Thanks for the response, Hannah! I appreciate the support. I think I might be missing something since that's basically what I have for a JUnit test right now. The static constructor for HttpRequest calls the FACTORY object. ``` package burp.api.montoya.http.message.requests; import static burp.api.montoya.internal.ObjectFactoryLocator.FACTORY; static HttpRequest httpRequest(String request) { return FACTORY.httpRequest(request); } ``` Which I found here. ``` package burp.api.montoya.internal; public class ObjectFactoryLocator { /** * This is initialized when your extension is loaded. */ public static MontoyaObjectFactory FACTORY = null; } ``` When I try to use the static constructor like the example you shared, I receive a null error since FACTORY isn't initialized in the test. That's how I ended up here lol. What do you think, am I just missing something?

Hannah, PortSwigger Agent | Last updated: Aug 18, 2023 03:53PM UTC

Could you drop us an email at support@portswigger.net with your code, so we can take a look in some more detail, please? Alternatively, if you have a link to your GitHub that would be useful.

Anthony | Last updated: Aug 18, 2023 05:32PM UTC

Thank you, I sent an email with a GitHub repo and pictures of the error. Just for reference, this is the error I'm getting java.lang.NullPointerException: Cannot invoke "burp.api.montoya.internal.MontoyaObjectFactory.httpRequest(String)" because "burp.api.montoya.internal.ObjectFactoryLocator.FACTORY" is null Thanks for the help!

Anthony | Last updated: Oct 06, 2023 02:45PM UTC

For others trying to go down the same path as I was. It's best to create functions that take in Java standard objects like Strings, Lists, etc. compared to passing in the API's objects since those would require you to mock out that object. Here was Hannah's point of view: It looks like, rather than testing your own functionality, you are testing Burp's. Rather than testing the full passiveAudit method, we would recommend isolating your code (the contents of the "if" statement) and testing that instead. For example, extracting it to a method that takes String values for "header.name()" and "header.value()" would make it a lot easier to test. ``` private boolean verifier(String name, String value) { return commonWebServerHeaders.contains(name) && !value.isBlank() && !allowedServerValues.contains(value); } ``` Due to the amount of mocking required, the current test compares a mocked object to a mocked object.

f1nl0wt3ch | Last updated: Feb 20, 2024 01:33PM UTC

Hi @Anthony! I am facing the same issue with you. How you overcome this problem? In case I wanna make a true call to test my function, how could we solve this?

Hannah, PortSwigger Agent | Last updated: Feb 20, 2024 05:11PM UTC

The best way to truly test functions in your extension would be to create a test extension that you can load into Burp and use to test functionality. For example, implement a button that runs a specific test when you click it. This means that you won't have to mock out the API functionality. Alternatively, as mentioned before, split out your functionality from the functionality contained within Burp's API, so that you can test your own behavior.

f1nl0wt3ch | Last updated: Feb 20, 2024 08:48PM UTC

Hi Hannah! Thank you for your helps. I misunderstood that, the Http interface is used to access to the Intruder. It doesn't suite to my case. After reading your documentation again about the API and replace by java.net.Http from JDK. Finally I got my function working and am able to test the logic.

Hannah, PortSwigger Agent | Last updated: Feb 21, 2024 10:42AM UTC

If you provide us with some more context around the functionality you are trying to achieve, we may be able to suggest some ideas for you to consider. Generally speaking, we would not advise using Java's networking libraries, and using Burp's instead, as this means that any configured rules in Burp like upstream proxy servers will be respected. Additionally, using Burp's networking libraries means that you can view your outgoing requests and responses generated by your extension in the Logger tab for better troubleshooting. Feel free to drop us an email at support@portswigger.net.

You must be an existing, logged-in customer to reply to a thread. Please email us for additional support.