Research Academy
My account Customers About Blog Careers Legal Contact Resellers
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

Hard-to-read HTML pages such as Extender and Documentation

dudez | Last updated: Nov 11, 2016 07:23PM UTC

I just noticed that most of the internally-accessible BurpSuite documentation isn't being shown correctly on my installation, as well as the Extender tool is difficult to read since the HTML source code is shown instead. Does anyone else see this behavior? I'm also attaching two screenshots to better explain what i mean. The Extender tool: http://imgur.com/nwW46yu The internal docs: http://imgur.com/jT4cAj9

Burp User | Last updated: Nov 13, 2016 06:40PM UTC

Not sure why, but exporting user/proj options, recreating the project and reapplying the same settings solved the issue.

Burp User | Last updated: Nov 17, 2016 10:59PM UTC

After some time working within the new project i have this issue again: not all HTML windows are affected, but the Extender and the documentation windows definitely yes. I'm not sure this can be related with the extensions installed since i didn't even enabled nor disabled one since rebuilding the project, i'm running the latest version in Kali (rolling) with Oracle Java 1.8.0_92-b13. Any clues or ever seen something similar happen to you?

PortSwigger Agent | Last updated: Nov 18, 2016 09:17AM UTC

This might be an issue with the platform or Java installation. Burp uses a native Swing text control and tells it the content is HTML. It's strange that the behavior is inconsistent. Let us know if you identify anything that reliably triggers the problem and we'll try to reproduce.

Burp User | Last updated: Nov 18, 2016 09:54PM UTC

I tried to run BurpSuite (updated to 1.7.12) in a terminal to try catch any interesting exception, and i caught some. I tried to disable every extension and started/closed Burp multiple times consecutively to see if the behavior changed. I noticed whenever i created a temporary project no exception was thrown, while reloading that aforementioned project always led to exception in stack trace #1 being thrown, with variations such as #2 and #3, so i'm pasting them for you to see on pastebin to keep this thread readable, this may help to pinpoint the problem in a better way: Stack trace #1: http://pastebin.com/nA2kyVXc Stack trace #2: http://pastebin.com/PyzLEUt9 Stack trace #3: http://pastebin.com/VMnqCRm3 The third stack trace was taken when i tried to switch theme (from Nimbus to Metal) to see if it had any effect: other than spitting out an additional exception it didn't change the HTML behavior. Also note that a temporary project never exhibits the problem nor it generate any stack traces, both projects share the same set of user/proj options. I may send you my .burp project file to help you replicate the problem locally if you agree, but it would be better to do this in some private form.

Burp User | Last updated: Nov 18, 2016 10:38PM UTC