BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Quarkus Defends REST APIs against Attack

Quarkus Defends REST APIs against Attack

Bookmarks

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.

About the Author

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • I didn't get the vulnerable to Log4Shell argument

    by Shai Almog,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Are they saying that since they don't use Log4J that's why they weren't vulnerable?

    That's a pretty weak argument. Had they been around for a couple of decades it's very likely they would have used it. As a newer framework they can boast fewer dependencies and legacy but that isn't an inherent security benefit.

  • Panache

    by Marc Schlegel,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    After some people of our team introduced Panache over a year ago we finally ditched it. Panache is extremely invasive to your codebase (we used the PanacheRepository not the ActiveRecords stuff since it is hard to use in tests). Everywhere people used persistAndFlush to "save" the entity which was completely unnecessary due to the enclosing JTA transaction. The lack of IDE support in the Panache query strings also was a reason not to use it anymore.

    Just following DDD repository approach works for all our services. Load the aggregate and traverse from there...no complex HQL queries are needed.

  • Re: I didn't get the vulnerable to Log4Shell argument

    by Erik Costlow,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The fact that they do not use log4j is not news on its own. The part that merits attention is the fact that analyzers were falsely reporting it as vulnerable when a conscious decision was made to not use it.

  • Re: Panache

    by Erik Costlow,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    Thanks Marc. If you have a write-up or blog on your usage, I'd be interested to take a look. I happen to like Panache ActiveRecord but your point on save vs. transaction enclosure is a good one.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT