Why does Atlassian allow and store XSS exploits in User Profile names?

Hi, can anyone help explain why Atlassian allows user profiles to contain live stored XSS javascript exploits?

image

Using the Atlassian API to access user profile information returns unfiltered user names that may contain exploits, be it for display, a picklist or report. It seems Atlassian would block thousands of XSS exploits by filtering user names before storing what are clearly hacks…

Understand that as app developers we have to be diligent and not trust data entered by end users into the apps. But the user name… ?

Chris

The same problem exists for Project name :upside_down_face:

This is true for many fields. The policy is that the purification should be done on rendering, not as part of the CRUD operation. Both Atlassian and app developers should always purify any value retrieved from the Atlassian API.

2 Likes

before our switch to react, it was a nightmare to always think about the manual escapes. If not done already I would recomment to use it or something similar.
By the way, is the comment/description field sanitized on atlassian side? (renderedFields)

XSS exploits can come from everywhere. Even from entity properties because people can modify them via the Entity Property tool. So you should always take care of this when rendering

1 Like