Docs

Docs

Common Vulnerabilities

Dealing with vulnerabilities, such as SQL injection, cross-site request forgery, and Java serialization.

SQL Injections

Since Hilla is a backend-agnostic UI framework, it doesn’t deal directly with backend access. Instead, the choice of backend framework (for example, Spring Data) is left to the developer. Hilla doesn’t provide mitigation for SQL injections. This is left to the backend provider and developer.

However, SQL injections can be completely blocked in Hilla applications by following the data validation and escaping guidelines (see the XSS section), as well as standard secure database access practices.

Most providers have their own ways of dealing with injections out of the box and we recommend that developers follow these guides. However, if the developer uses pure JDBC, they will have to deal with injection risks themselves. Here is an example of pure JDBC, demonstrating SQL-injection mitigation using the value from a Text Field in a prepared statement:

class ValueChangedView extends LitElement {
  render() {
    return html`
      <vaadin-text-field label="Your name" @value-changed="${this.nameChanged}"></vaadin-text-field>
    `;
  }

  private nameChanged(event: CustomEvent) {
    nameEndpoint.updateName(event.detail.value)
  }
}

Cross-Site Request Forgery (CSRF / XSRF)

All requests between the client and the server have a user-session-specific CSRF token included. All communication between the server and the client is handled by Vaadin, so you don’t need to remember to include and verify the CSRF tokens manually.

The CSRF token is passed inside the JSON message in the request body:

Sending xhr message to server:
{"csrfToken":"0bd61cf8-0231-455b-b39a-434f054352c5","rpc":[{"type":"mSync","node":5,"feature":1,"property":"invalid","value":false},{"type":"publishedEventHandler","node":9,"templateEventMethodName":"confirmUpdate","templateEventMethodArgs":[0]}],"syncId":0,"clientId":0}

When Vaadin services requests, the CSRF token is passed in the X-CSRF-Token HTTP header:

X-CSRF-Token: 0bd61cf8-0231-455b-b39a-434f054352c5

The CSRF token mechanism can be overridden on the server, for example to enable repeatable load test scripts using Gatling or similar tools. This is strongly discouraged when running in production.

Java Serialization Vulnerability

A general security issue has been identified in programming language mechanics where the language allows execution of code that comes from serialized objects. The Java language isn’t immune to this; as a non-exhaustive list, at least the Java Serialization framework, RMI, JMX and JMS features are vulnerable to the issue.

If the application is set up to deserialize Java objects (for example, using the libraries above), an attacker can feed the system a malicious payload that gets deserialized into Java objects. The attacker can then execute arbitrary code using specific language features (such as reflection).

Vaadin has published a security alert for this vulnerability.

The vulnerability cannot be fixed in Vaadin. Developers need to mitigate the risk using methods described in the alert appendices.