Created by Ming Zhu
We are happy to announce to our Uniface Web Application developers that the next Uniface release will include an updated Web Request Dispatcher (WRD), version 7.0. WRD 7.0 will support the SameSite cookie, and the latest standard Jakarta Servlet 6.0.
improves the security of your Web applications and helps you protect your application from some of cross-site request forgery (CSRF) attacks.
support enables you to deploy your Web application to Web application servers that support the latest standard Jakarta Servlet 6.0, for example, Apache Tomcat 10.1.
In this blog, we focus on the new features of WRD 7.0. And later in a separated blog, you can find how to install and configure the WRD 7.0 on Apache Tomcat 10.1.
If you're a system manager, this blog post will show you how to configure WRD 7.0 with Servlet 6.0-compliant like Tomcat 10.1. If you're a developer, keep reading to learn how to implement a cookie using the SameSite . And, if you're a security manager, you'll learn how to configure WRD 7.0 to support the default value of the SameSite cookie for Uniface Web Applications. Finally, post shows you an example of a CSRF attack as well as how to use the SameSite cookie to defend against it.
WRD 7.0 release
The Uniface Web Request Dispatcher (WRD) is used to deploy Uniface web applications. WRD is a Java Servlet that is responsible for brokering requests and maintaining connections between web servers and the Uniface Router.
WRD is implemented based on the Java Servlet standard which is a part of the JavaEE (Java Enterprise Edition) standard ([R9]). It runs inside a JavaEE web container within a JavaEE-compliant web server like Tomcat.
As of the Java Servlet 5.0 specification, the standard JavaEE has been renamed to JakartaEE (with the root namespace changing from
jakarta). Version 5 also introduced a breaking change and is incompatible with Uniface WRD 6.4 and earlier. To support the updated namespace and the SameSite cookie attribute, Uniface is releasing the new WRD version 7.0 that is compliant with the Servlet 6.0 standards.
WRD 7.0, includes the following major changes:
- support from JavaEE Servlet 4.0 to Jakarta Servlet 6.0
- We've added a new feature to support the SameSite cookie attribute, for improved Web application security
- We've updated the package name from
Servlet 6.0 support
Although the Servlet 6.0 specification (See [R6]) was finalized in , the first stable and usable release of a reference implementation for it was Tomcat 10.1.0 in September 2022. It contains the following major update when compared with Servlet 4.0:
- It requires Java runtime of Java 11 or later (not Java 8)
- The new Cookie makes it possible to handle the newly added attribute
SameSite cookie support
One of the main new introduced in WRD 7.0 is SameSite Cookie support.
For a Web application developer, the SameSite attribute cookie allows to declare if their cookie should be restricted to a first-party or same-site context (See [R5]).
This feature can against some types of cross-site request forgery (CSRF) attacks, the security of Web applications.
Example of a CSRF attack
Let's look at a typical CSRF attack scenario.
Suppose there is a web application at https://www.example.com/uniface, and user with the name user1 performs the following step via a web browser:
After the user (named user1) logs in successfully to https://www.example.com/unifac, the web application response will look like this:
HTTP/2 200 OK
As a result, the cookie usessionid=xlakdjflakdlaadlka will be set at the client browser side.
email address, user1 submits an HTTP request to https://www.example.com like the following:
- The web application this request and the user by the cookie usessionid.
If validation is successful, the email will be updated with the new value firstname.lastname@example.org in the .
At this moment, user1 receives a phishing email with phishing link to http://www.examplex.com/foo the user the link, it returns page with a submit button like this:
After the user the submit button, this page will send HTTP request to https://www.example.com/uniface/wrd/setemail with the cookie: usessionid=xlakdjflakdlaadlka, because there is no on cross-site . As a result, this request will pass with the correct
How to use the SameSite cookie to defend against this CSRF attack
At step 1 above, set the usessionid cookie with attribute SameSite=Lax:
set-cookie: usessionid=xlakdjflakdlaadlka; SameSite=Lax
Later in step 4, because the cookie has the attribute with the value set to Lax, the browser will follow the standard on SameSite the value is Lax it will block this cookie from being sent to any cross-site URL (with a different from the URL of the current page). ithout a valid usessionid cookie, this request cannot pass the application validation, and the attack will fail
Migration to WRD 7.0 and configuration of the default value of the SameSite cookie attribute
To migrate to WRD 7.0, we suggest users take the following steps:
- First, to migrate your Web application's web.xml by replacing all old packages named with the new package name
- Then, update your configuration for , and add a new init-param DEFAULTSAMESITE with value LAX
this setting, the SameSite attribute with the value set to LAX will be added to all cookies in the user's Uniface Web application. This will from some types of cross-site request forgery (CSRF) attacks.
- If add the SameSite attribute to system cookies like JSESSIONID, then update the configuration of your Servlet-6.0 compatible Web server. For example, in Tomcat 10.1, add the following element <CookieProcessor sameSiteCookies="LAX"/> inside the <Context> of your context configuration file By default, it should be located at tomcat10.1_folder\conf\Catalina\localhost\uniface.xml (See [R5] for details)
Cookies with SameSite=LAX are not sent on normal cross-site subrequests (for example to load images or frames into a third-party site) but are sent when a user to the original site (i.e., when following a link). See [R2], [R3], [R4] for details.
This migration suggestion should meet the most general needs of users of the existing application. For more precise configuration details, please see the related topics in Uniface library 10.4 ([R8] and related).
Setting the SameSite cookie attribute in ProcScript
Based on your business logic, in some cases, you may need to specify the value of the SameSite cookie for each cookie in your application. This can be implemented in ProcScript. Just like any other supported cookie attributes, you can do it via the COOKIESOUT webinfo channel.
is an example of setting the SameSite cookie attribute in ProcScript:
string vCookieName, vCookieContent
;Set Cookie value
;Add Cookie attributes
putitem/id vCookieContent, "SameSite", "LAX"
;Publish Cookie to response
putitem/id $webinfo("COOKIESOUT"), vCookieName, vCookieContent
See [R1] for details.
Take actions to secure your Web application
In summary, we strongly suggest that you migrate your Web application to WRD 7.0, and start using the SameSite cookie feature to secure your Web application.
For new Web applications in development, we suggest you redesign the usage of cookies and add the SameSite cookie attribute to all of the cookies in your application, based on your business logic.
For your existing Web applications, migrate WRD to version 7.0 and configure it with a secured default value of the SameSite cookie attribute. If necessary, re-code your ProcScript to set individual cookies.
As we have shown above, this will improve the security of your Uniface Web application.