JFreeChart version 1.0.19 contains an error in its handling of special characters in the OverLIBToolTipTagFragmentGenerator, which can be used to mount an HTML injection attack against an application which uses this class.
I recently completed an upgrade from the venerable 1.0.9 to 1.0.19. After the upgrade, a chart that was working fine in 1.0.9 was no longer working in 1.0.19. Investigation revealed that OverLIBToolTipTagFragmentGenerator was generating invalid HTML.
In version 1.0.9, the OverLIBToolTipTagFragmentGenerator included the following line:
ImageMapUtilities.htmlEscape(toolTipText)
In version 1.0.19, this is now
ImageMapUtilities.javascriptEscape(toolTipText)
From the change log, it seems that this change was made to correct the handling of single quotes. But unfortunately, it breaks the handling of double quotes. If the tooltip text contains a double quote, the resulting HTML will look like this:
onMouseOver="return overlib('Includes\"Quote');"
Embedded javascript aside, this code is trying to provide a value for the HTML onMouseOver attribute. If you look at the syntax rules for XML and/or HTML, you will realize that when an attribute is enclosed in double quotes (as the onMouseOver attribute is here), any double-quotes inside the attribute must be written as " . The simple backslash above does not prevent the double-quote character from terminating the HTML attribute, so web browsers parse the onMouseOver attribute to have the value:
return overlib('Includes\
Since this is invalid javascript, no tooltip is generated. If we are lucky, the remaining portion of the tooltip will be treated by the HTML parser as unexpected garbage and discarded. But in the worst case, a malicious attacker could exploit this bug to create an HTML injection attack against a web application that is using OverLIBToolTipTagFragmentGenerator.
I welcome others to weigh in with opinions, but I believe the correct logic for this line would be:
ImageMapUtilities.htmlEscape(ImageMapUtilities.javascriptEscape(toolTipText))
In my own tests on a Windows computer, the resulting HTML appears to be handled correctly in Firefox, Chrome, and Internet Explorer 11.