Support Center

Burp Community

See what our users are saying about Burp Suite:

How do I?

New Post View All

Feature Requests

New Post View All

Burp Extensions

New Post View All

Bug Reports

New Post View All
Documentation

Burp Suite Documentation

Take a look at our Documentation section for full details about every Burp Suite tool, function and configuration option.

Full Documentation Contents Burp Projects
Suite Functions Burp Tools
Options Using Burp Suite
Extensibility

Burp Extender

Burp Extender lets you extend the functionality of Burp Suite in numerous ways.

Extensions can be written in Java, Python or Ruby.

API documentation Writing your first Burp Suite extension
Sample extensions View community discussions about Extensibility
Name is required.
Email address is required.
Invalid email address
Answer is required.
Exceeding max length of 5KB

No API stack nor full parameter value when using Infiltrator with a private Collaborator server

Nicolas Grégoire Mar 18, 2017 06:28PM UTC

[Tested with Burp Suite Pro 1.7.19]

I instrument Jenkins 1.580.2 like that:
java -jar ${JENKINS_HOME}/infiltrator.jar --non-interactive --report-parameter-values=true --report-call-stacks=true --target-paths=/path/to/war/

If I use the public Collaborator server, everything is fine. But when I use my own Collaborator server (using a dedicated domain), I _never_ have the call stack or full parameter value (using Scanner or the manual client). Is that a known limitation of private Collaborator servers? Did I miss something when configuring my Collaborator?

Notes:
- the private Collaborator instance uses a self-signed SSL cert + the SMTPS port isn't reachable
- health check is OK, with some warnings
- I think that instrumentation is OK, because the same patched app works well with a public Collaborator

Thanks in advance!


Nicolas Grégoire Mar 19, 2017 10:39AM UTC
Culprit found the culrpit (thanks to Santiago): the Collaborator self-signed cert wasn't trusted by the app, and that was blocking some interactions.

Adding "--use-http=true" at patch time solved the problem. Adding the cert to the local keystore should have work too (untested).

Post Your public answer

Your name
Your email address
Answer