which versions are you using (SonarQube, Scanner, Plugin, and any relevant extension) - 7.9.1
what are you trying to achieve - less XSRF/CSRF failure log output in our bitbucket server logs
what have you tried so far to achieve this - attempted to find the source code for the bitbucket server integration on github and was not able to find it.
Hi,
We have a deployment of sonarqube 7.9.1 linked to bitbucket server and providing code analysis insights. One issue we are seeing is that seemingly DELETE requests from sonarqube cause XSRF/CSRF warnings to be logged in our bitbucket server instance like so
REDACTED “DELETE /rest/insights/1.0/projects/<PROJECT_REDACTED>/repos/<REPOSITORY_REDACTED>/commits/<COMMIT_REDACTED>/reports/com.sonarsource.sonarqube/annotations HTTP/1.1” c.a.p.r.c.s.j.XsrfResourceFilter XSRF failure not being enforced for request: https://REDACTED/rest/insights/1.0/projects//<PROJECT_REDACTED>/repos/<REPOSITORY_REDACTED>/commits//<COMMIT_REDACTED>/reports/com.sonarsource.sonarqube/annotations , origin: null , referrer: null, method: DELETE
We were wondering if it would be possible to set a x-atlassian-token: no-check header as per https://developer.atlassian.com/server/jira/platform/form-token-handling/ in order to avoid encountering this error (it may also be possible to set a content-type of say application/json instead of using the atlassian specific header token). Thank you in advance.
I was able to reproduce your problem. Let me add few comments about it:
That’s normal, PR decoration is a commercial feature so it is not part of the open source code
even though you do well by handling them, these are warnings so they do not prevent the feature to work
I think this can happen in several scenario but the one I think here is that: your BB server is reached by SQ using another URL than the one defined in BB Server settings, hence it’s not trusted, right? In that case, configure SQ to use the right URL is the way to go.
SonarQube can’t do that, as it’s introducing a vulnerability. If you want to do that, you can have a proxy which adds the header before reaching BB.
Generally speaking, if you want to fix these warnings, you should make sure that the check done by BB is evaluated to true, not to remove the check itself. Here you redacted most of the data so it’s hard to understand what exactly happened, but as mentioned I guess SQ does not reach BB with its public URL.
SonarQube can’t do that, as it’s introducing a vulnerability. If you want to do that, you can have a proxy which adds the header before reaching BB.
I work at Atlassian on the product security team and I will happily explain why adding a x-atlassian-token: no-check header to the request that SQ sends to Bitbucket Server is not a security vulnerability. In short that header offers a way for scripts and/or api users to indicate to the Atlassian Rest Cross Site Request Forgery (CSRF) protection code that they do not need to provide a CSRF token value[0]. As SQ is an api user it can specify a “non-simple” content type[1], in this case application/json, or the x-atlassian-token: no-check header to indicate that the request is a non-simple request & that it should pass CSRF checks.
I can provide further information if that would be helpful .
Hi @david_b,
Thanks for raising the issue and suggesting options how to fix it! I’ve opened a ticket to track this: SONAR-13371. We will add x-atlassian-token: no-check header, seems like a better option than adding Content-Type to a DELETE request without content.
.