Not a bug XSS vulnerability in jQuery version used in XF 1.5

First and foremost, if you ever believe there to be an exploitable security issue in any part of the software, then you must never report it in public for the protection of other customers.

That said, I don't believe this is exploitable in normal use of the XF software:
Affected versions of the package are vulnerable to Cross-site Scripting (XSS) attacks when a cross-domain ajax request is performed without the dataType option causing text/javascript responses to be executed.
Click to expand...
In the default software, we don't perform cross-domain AJAX requests, and in any case all AJAX requests performed through our built in wrapper always set the dataType.

Although add-ons can and may deviate from this, if there is an exploitable issue then it should be reported (in private!) to the relevant author for them to address it.
 
I understand the public disclosure aspect. I actually thought about reporting privately, but:
  • I couldn't find any guidelines on how to report security vulnerabilities in XF
  • It was not necessarily a support request, so I didn't use that channel either (and members with no active license won't be able to use it any way)
  • I did not see a sub-forum with permissions set in a way that only the thread poster and staff can see the content of related threads
  • The exploit was publicly disclosed three years ago
Add-ons are certainly a weak point where this might happen. It is quite likely for add-ons or custom modifications by admins to fetch data from various external HTTP APIs. It is not unlikely for naive XF add-on developers and admins to unintentionally become target of this exploit. In my opinion, the software should be secure by default, as much as possible, rather than offloading undocumented responsibility downstream. If a non-breaking updated jQuery version exists then it should be used instead.
 
We provide all the tools for a developer to write code safely by way of a well written and security-minded framework. Using the standard framework functions for such things as AJAX requests, this is a non-issue.

Just like using the standard approaches to escaping user generated content, input and writing database queries.

Despite those features, we can’t totally prevent people deviating from them and creating XSS or SQL injection vectors in the process.

So it really is, like anything else, just a case of continuing to set a good example in our own code and if there are any add ons which can be exploited by this issue (which frankly I think will be very few to none) then they should be contacted on a per case basis.
 
Back
Top Bottom