The Quarkus team released version 2.13.0, a new release that integrates RESTEasy APIs with an integrated control against CSRF attacks, making web applications more resilient against certain types of fraud.
CSRF stands for Cross Site Request Forgery, an attack that can cause an authenticated user to submit requests into one web application while using other tabs or windows within the same browser. Oliver Moradov from BrightSec explains how CSRF attacks work using three simple examples. Attackers decide which web application they want to target, and craft custom GET requests that exchange parameters to actions within the web app using a zero-sized non-displaying image. For POST requests, the hosting web page can leverage JavaScript to create or submit forms to the web application, using a known action and parameters with the harmful form element. When performed, users who are not logged in to the target application will have their CSRF attacks silently fail while users who are logged in will perform the attacker’s custom action via their credentials.
Quarkus' guide explains the feature in a guide for developers to enable CSRF defense. The approach of adding an application-generated token to each request matches best practice defense from OWASP. Quarkus’ automated feature creates a unique token per user that is validated on each incoming request. This token is transparent for the developer, but requires knowledge that cannot be known to any attacker who attempts to attack the web application using CSRF techniques. When present, this defense causes CSRF attacks to fail.
The CSRF defense comes alongside many other security-positive decisions by the Quarkus team that make it possible for developers to produce secure applications without requiring complex security decisions. In December 2021, Quarkus developer Max Rydahl Anderson clarified that Quarkus was unaffected by Log4Shell. By decreasing the scope of external dependencies needed to develop with Quarkus, the framework minimizes the opportunity for CVEs to appear through transitive dependencies. Anderson further clarified that some composition analyzers that attempt to locate Log4J via vile scanning could erroneously categorize Quarkus as vulnerable when it is not. Due to transitive dependencies of some integrations, applications could pull in log4j-core using a version which was allegedly vulnerable. However this was a false positive with many scanners, because the code was never actually invoked.
Another secure-by-default feature of Quarkus comes from its integration with Panache, an overlay for database access via Hibernate ORM. By modeling tables using Java objects with JPA Entity annotations and using an active record pattern rather than queries, Panache minimizes the opportunity for SQL Injection attacks. Unlike applications where SQL or HQL queries are coded, Panache favors an API through inheritance of the PanacheEntity or PanacheRepository classes that cleanly separate code and data for a higher level of security with easier development.
Developers interested in other security defenses and capabilities of the Quarkus framework can consult the dedicated Quarkus Security page. The page goes beyond standard authentication/authorization features of web applications to include development configuration and implementation guidance that can secure applications from many different vectors.