Content-Security-Policy HTTP header

[Myron A. Semack]

A third party vulnerability scan of our domain found an issue with our public status page due a missing CSP HTTP header.  Are there any plans by Atlassian to add this header?

(I know I can add the header via a META tag, but that would require upgrading my plan.  Seems like I should not have to pay extra for basic XSS protection in 2021.)

[egranty]

There is a kind of "scriptless XSS": CSSAR (a technique for reading tag attributes with CSS selectors), SVG keylogger using <svg> and <set> tags, Reading attributes with CSS, SVG and scrollbars in WebKit.

There are at least 7 ways how to inject scripts into web page, and 6 of those do not require any input fields.

May be it's better to provide possibility to publish Content Security Policy than relying on invulnerability web app?

[chare]

It might be a god idea, so maybe Atlassian will add it.

I think my bigger issue is before getting excited about issues on a vulnerability report, there needs to be some effort to validate the vulnerability exists and can be exploited.  I have seen too much of that over the years. Hopefully someone from Atlassian will jump in and comment on adding CSP.

[Myron A. Semack]

@chare 

I think the bigger issue is your argument boils down to: "You only need that header if there is a vulnerability in the app, and don't worry we don't have any."

Security is about defense in depth.  What if tomorrow one of the Atlassian devs commits a code change that makes it vulnerable to XSS?

[chare]

I can see how my comment would be interpreted as such.  I am not saying it shouldn't be acted upon.  In a recent security assessment I was involved in, the penetration testers said they found a vulnerability.  they went on to say they used  a tool to find the issue, but 50 hours of man effort to exploit it.  and then they admitted the data they got (which was a list of file names) still yielded no data because they couldn't circumvent the other controls.  So - yes -defense in depth.  If Atlassian adds it to the Free plan, great.  If they don't or won't, then...  my point is that I have seen too many vulnerability scans show vulnerabilities where the issue couldn't be exploited for other means. No flame war here, my intention was a cautionary comment only.  I won't be upset if Atlassian adds it to the free plan.  (By the way, I do not work for Atlassian.)

[Myron A. Semack]

Totally understand it's not an actual vulnerability.  It was a warning in the audit that lowered the score.

[chare]

Fair enough.  That just wan't clear I the original post. good discussion though.  It will be interesting to see if Atlassian decides to add this header to the free plan, even if they don't add META capabilities.  I agree it would be a good idea.  

[chare]

For XSS to be effective, there has to be some way of injecting the XSS into the code.  The public status page has no fields where the user can enter text which would then be executed by the Javascript on the page.

This article gives a great explanation about XSS in general, along with the various types and how to demonstrate them.

Cross Site Scripting (XSS) Attack Tutorial With Examples, Types & Prevention 

Because there are no input fields to interact with, the XSS risk is significantly reduced.  Just because there is no CSP header doesn't mean the page is vulnerable to XSS; only that there is no header.  If your third-party assessment found specific XSS attack vendors which they exploited, that is a different issue.

Chris

[Myron A. Semack]

What about the subscribe to updates button?  There are input fields for email/SMS/etc.

[chare]

That's true.  For XSS to work, the back end must not be parsing the input correctly. 

The simplest XSS test is to put 

<script>alert(‘XSS’)</script>

in the text field.  If you submit the data and you get an alert back, then your site is at least vulnerable to reflected XSS.   However, with the subscribe to button,

returns this:

even if you go through this verification, there is a brief message displayed indicating you have to enter a valid email address.  

Just because the report says there is a vulnerability doesn't mean you have a valid attack vector.  The primary reason for XSS working is because the developer doesn't do input validation.  For example, by looking for a pattern like abcdefg@domain.com, I can quickly determine that 

<script>alert(‘XSS’)</script>

doesn't meet that pattern and reject it.  Which is what Statuspage does.

Chris