Cross-Site Request Forgery (CSRF) in version 6.2

[Dadisi Sanyika]

Howdy!

We were trying to implement and our security team up an issue:

###

# Description

Cross-Site Request Forgery (CSRF or XSRF), is a type of attack that occurs when a user loads or interacts with a malicious Web site, email, blog, instant message, or program, by loading an image or clicking a link. This causes a user's Web browser to perform an unwanted action on a trusted site for which the user is currently authenticated, in another tab or in another window. CSRF attacks specifically target state-changing requests, not theft of data, since the attacker has no way to see the response to the forged request. 

For example, if an administrator is social engineered into landing on a page controlled by an attacker or clicking a link submitted by an attacker that POST's a request to the application under administration, the attacker could trick the user into adding or deleting data, adding users or altering permissions. This is usually done without the victim's knowledge.

The following endpoints within the application perform state-changing actions without protecting against CSRF:

* `/issues/bulk_change`

* `/project/create_event`

* `/project/delete_event`

* `/project/delete_snapshot_history`

* `/project/update_event`

* `/project/update_version`

# Remediation

CSRF protection is intended to prevent state-altering requests that do not originate from the application itself. 

All non-idempotent actions should require a nonce generated by the server to accompany the request. This is to ensure the user intended to perform the action by requiring the source of the action to be provided by the server.

Please use your web framework's built in Anti-CSRF solution to prevent this attack.

Alternatively, an easy way to prevent this is to have every page rendered with a couple of additional hidden variables:

  

    var1 = hmac_sha256(secret, "timestamp+session_id+additional_metadata")

    var2 = timestamp

On the backend you take the timestamp and validate it by creating an hmac of the server side secret with the timestamp. If valid and the time has not passed you can allow the request to continue.

This allows you to set expiration on pages and authenticate their creation so CSRF attacks are mitigated. It should not be possible to use the same valid token twice.

Alternatively, all sensitive actions should require the user to re-authenticate by entering their password again.

# Proof of Concept

1. Log in as an administrator user at https://sonarqube-dev/sessions/new

2. Browse to https://sonarqube-dev/project/update_version?sid=19&version_name=CSRF+PoC1&commit=Save and observe that the February 28 snapshot now has "CSRF PoC1" in the version column.

3. Browse to https://sonarqube-dev/project/update_version?sid=19&version_name=CSRF+PoC2&commit=Save and observe that the February 28 snapshot now has "CSRF PoC2" in the version column.

####

Is there a way to work around this in the configuration or properties file?

[Fabrice Bellingard]

Hi Dadisi,

indeed, those WS were the last ones implemented on the legacy architecture (based on Ruby-on-Rails). SonarQube 6.3 fixes all this.

Best regards,

Fabrice BELLINGARD | SonarSource SonarQube & SonarLint Product Manager http://sonarsource.com

--
You received this message because you are subscribed to the Google Groups "SonarQube" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sonarqube+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/sonarqube/aa43bc15-de17-4d37-8131-59c7e809c13d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.