We are running vulnerability scans on our systems. I can see a few XSS vulnerabilities being reported, such as CVE-2020-14173. Let me quote:

The file upload feature in Atlassian Jira Server and Data Center in affected versions allows remote attackers to inject arbitrary HTML or JavaScript via a cross site scripting (XSS) vulnerability. The affected versions are before version 8.5.4, from version 8.6.0 before 8.6.2, and from version 8.7.0 before 8.7.1.

If this is a internal (not exposed to the Internet) system could I safely assume that the severity for such vulnerability could be decreased? I mean, if a bad actor has already gained an initial foothold, I could imagine that he would use other techniques to escalate privileges.

Are my assumptions valid?

  • "... not exposed to the Internet ..." - maybe not directly. But it is pretty common that the same browser is used to access internet and intranet. In this case cross-site attacks like reflected XSS or CSRF can be used to attack intranet application by simple visiting a malicious site on the internet. Dec 9 '20 at 9:29
  • But for an reflected XSS attack to work the application must take some input from an HTTP request and embed that input into the immediate response in an unsafe way. So the attacker would have to know the exact pramaters to pass via the HTTP request. How would one guess information like the fqdn to be used in the url ? Regarding CSRF, that would have to mean that there's a CSRF vulnerability as well, but there's none AFAIAC. Or am I wrrong ? Please let me know. Thank you.
    – cyzczy
    Dec 9 '20 at 9:42
  • 1
    "How would one guess information like the fqdn to be used in the url ..." - simply guessing often helps, i.e. using things like jira.example.com. Also, jira and confluence leak the HTTP referer by default when linking to external sites, so these information might also be find in local server log files of somebody who reported a bug or similar to the vendor and included a description in their own website. Dec 9 '20 at 9:48
  • Thank you @SteffenUllrich Please allow me to ask you this. Could one then use such criteria at least to prioritize vulnerabilities ? I mean if I get a report with ~+2k vulnerabilities I somehow need to address them (most likely not all at once).
    – cyzczy
    Dec 9 '20 at 10:23
  • 1
    Of course the information that the site is not reachable directly but only indirectly should be taken into account when evaluating the concrete risk - which is then used to prioritize vulnerabilities. But just this fact alone is irrelevant. Instead the related mitigating factors need to be evaluated (i.e. target hostname easily available to attacker or not, maybe sanitizing of cross-site access within internal proxy etc) on how much they actually reduce the risk. Dec 9 '20 at 10:31

Well, having a service internal facing only does limit the scope of who can abuse said vulnerability. (It goes from the whole world to a quite limited subset of users with acces to your intranet)

So just like if an exploit requires a valid admin login or not impacts its severity, so does this.

But you must also consider that xss are initiated from anywhere, so unless you got dedicated tools your browser can become a relay.

But remember that gaining access to your intranet is often easier than you think (it takes 1 compromised device after all), so it’s still the best idea to patch ASAP.

Not the answer you're looking for? Browse other questions tagged or ask your own question.