Published on Oct 19, 2022
Quarks has released version 2.13.0, a new release that combines RESTEasy APIs with an integrated control against CSRF attacks, thus increasing the resilience of web applications against certain types of fraud.
CSRF stands for Cross-Site Request Forgery, an attack in which an authenticated user submits requests to one web application while using other tabs or windows in the same browser. Using three simple examples, Oliver Moradov from BrightSec explains how CSRF attacks work. Using a zero-sized non-displaying image, attackers craft custom GET requests that exchange parameters to actions within the web application. In the case of POST requests, the hosting web page can leverage JavaScript to create or submit forms to the web application, using a known action and parameters. As a result, users who are not logged in to the target application will have their CSRF attacks silently fail, while logged-in users will execute the attacker’s custom action.
Quarks provides a guide to enable CSRF defence in a guide for developers. An application-generated token is added to each request as part of OWASP’s best practice defence. Quarkus’ automated feature creates a unique token for each user, which is validated upon each incoming request. While this token is transparent to the developer, it requires knowledge that cannot be known by any attacker who attempts to attack the web application using CSRF techniques. This defence prevents CSRF attacks from succeeding when it is present.
As part of the Quarkus team’s security-positive decisions, the CSRF defence is one of many that makes it possible for developers to create secure applications without having to make complex security decisions. Quarks developer Max Rydahl Anderson clarified in December 2021 that Quarkus was not affected by Log4Shell. The framework minimises the opportunity for CVEs to appear due to transitive dependencies by reducing the scope of external dependencies required to develop with Quarks. Furthermore, Anderson clarified that some composition analysers that use vile scanning to find Log4J might erroneously classify Quarkus as vulnerable. Applications were able to pull in log4j-core using a version which was allegedly vulnerable due to transitive dependencies of some integrations. As a result, this was a false positive with many scanners, since the code was never actually executed.
The integration between Quarkus and Panache, an overlay for Hibernate ORM, is another secure-by-default feature of Quarkus. Using Java objects with JPA Entity annotations and active record patterns rather than queries, Panache minimises SQL Injection attacks by modeling tables using Java objects with JPA Entity annotations. Unlike applications in which SQL or HQL queries are coded, Panache favors an API through inheritance of PanacheEntity and PanacheRepository classes, which provide a higher level of security and make development more straightforward.
For developers interested in other security defenses and capabilities of Quarkus, please refer to the dedicated Quarkus Security page. This page provides development configuration and implementation guidance that can secure applications from a variety of vectors in addition to the standard authentication and authorisation features of web applications.
