This article is a part of our Vulnerability Database (back to index)
Cross-Site Request Forgery occurrences in Che
A flaw was found in Eclipse Che in versions prior to 7.14.0 that impacts CodeReady Workspaces. When configured with cookies authentication, Theia IDE doesn't properly set the SameSite value, allowing a Cross-Site Request Forgery (CSRF) and consequently allowing a cross-site WebSocket hijack on Theia IDE. This flaw allows an attacker to gain full access to the victim's workspace through the /services endpoint. To perform a successful attack, the attacker conducts a Man-in-the-middle attack (MITM) and tricks the victim into executing a request via an untrusted link, which performs the CSRF and the Socket hijack. The highest threat from this vulnerability is to confidentiality, integrity, as well as system availability. (2020-12-14, CVE-2020-14368)
For Eclipse Che versions 6.16 to 7.3.0, with both authentication and TLS disabled, visiting a malicious web site could trigger the start of an arbitrary Che workspace. Che with no authentication and no TLS is not usually deployed on a public network but is often used for local installations (e.g. on personal laptops). In that case, even if the Che API is not exposed externally, some javascript running in the local browser is able to send requests to it. (2019-12-19, CVE-2019-17633)
Why Cross-Site Request Forgery can be dangerous
The absence of Anti-CSRF tokens may lead to a Cross-Site Request Forgery attack that can result in executing a specific application action as another logged in user, e.g. steal their account by changing their email and password or silently adding a new admin user account when executed from the administrator account.
The attacker may copy one of your web application forms, e.g. email/password change form.
The webpage will contain a form with the exact set of fields as the original application but with input values already provided and the submit button replaced with a Javascript code causing auto-submission. When the page is accessed the form will be immediately submitted and page contents replaced with a valid content or a redirect to your original application.
One of your application users who is already logged in can be then tricked to navigate to such malicious page e.g. by clicking a link in a phishing email, and the pre-populated form content will be submitted to your application like it would be submitted by your user.