You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
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.)
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?
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.
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?
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.)
This article gives a great explanation about XSS in general, along with the various types and how to demonstrate them.
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.
That's true. For XSS to work, the back end must not be parsing the input correctly.
The simplest XSS test is to put
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,
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 firstname.lastname@example.org, I can quickly determine that
doesn't meet that pattern and reject it. Which is what Statuspage does.