Rocket Uniface User Forum

 View Only
Back to Uniface Main Page

Best practices for using WRD 7.0 and Samesite cookie support with Uniface

By Ray Sullivan posted 03-01-2023 15:10

  

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.

Supporting the SameSite cookies improves the security of your Web applications and helps you protect your application from some types of cross-site request forgery (CSRF) attacks.

Jakarta Servlet 6.0 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 Web Application Servers like Tomcat 10.1. If you're a developer, keep reading to learn how to implement a cookie using the SameSite cookie attribute in ProcScript. 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, this 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 javax to 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:

  • We're updated Servlet 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 com.compuware to com.rocketsoftware

Servlet 6.0 support

Although the Servlet 6.0 specification (See [R6]) was finalized in May 2022, 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:

  • The package name changed from javax .servlet to jakarta.servlet
  • It requires Java runtime of Java 11 or later (not Java 8)
  • The new Cookie API makes it possible to handle the newly added attribute

The WRD 7.0 update supports Servlet 6.0 Web servers like Tomcat 10.1 ( [R7] ). Users of Servlet 4.0 Web servers (like Tomcat 9) can only use WRD 6.x.

SameSite cookie support

One of the main new features introduced in WRD 7.0 is SameSite Cookie support.

For a Web application developer, the SameSite attribute of an HTTP cookie allows you to declare if their cookie should be restricted to a first-party or same-site context (See [R5]).

This feature can help you defend against some types of cross-site request forgery (CSRF) attacks, improving the security of your 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 a user with the name user1 performs the following step via a web browser:

  1. 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
...
set-cookie: usessionid=xlakdjflakdlaadlk

...


    As a result, the cookie usessionid=xlakdjflakdlaadlka will be set at the client browser side.

  2. To set the email address, user1 submits an HTTP request to https://www.example.com like the following:

    POST /uniface/wrd/setemail
Content-Type: application/x-www-form-urlencoded
cookies: usessionid=xlakdjflakdlaadlka

email=user1@example.com
  3. The web application receives this request and authorizes the user by validating the cookie usessionid.
    If validation is successful, the email will be updated with the new value user1@example.com in the database.

  4. At this moment, user1 receives a phishing email with phishing link to http://www.examplex.com/foo. When the user clicks the link, it returns a page with a submit button like this:

    <form method="POST" action="https://www.example.com/uniface/wrd/setemail">
      <input name="email" type="text" value="hacker1@somewhere.com" hidden/>
      <input type="submit" value="Submit">
    </form>
    After the user clicks the submit button, this page will send an HTTP request to https://www.example.com/uniface/wrd/setemail with the cookie: usessionid=xlakdjflakdlaadlka, because there is no constraint on cross-site requests. As a result, this request will pass the server-side validation with the correct usessionid cookie, and the email will now be updated with the email of the hacker, allowing the hacker to do all sorts of stuff using this account..

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 usessionid cookie has the SameSite attribute with the value set to Lax, the browser will follow the standard on SameSite cookies. When the value is Lax it will block this cookie from being sent to any cross-site URL (with a different address from the URL of the current page). Without 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:

  1. First, you need to migrate your Web application's web.xml by replacing all old packages named com.compuware with the new package name com.rocketsoftware
  2. Then, update your configuration for servlet to com.rocketsoftware.uniface.urd.WRDServlet , and add a new init-param DEFAULTSAMESITE with value LAX 
        <init-param>
       <param-name>DEFAULTSAMESITE</param-name>
       <param-value>LAX</param-value>
    </init-param>

    With 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 protect your application from some types of cross-site request forgery (CSRF) attacks.

  3. If you need to 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, you'll need to 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 navigates 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.

Here is an example of setting the SameSite cookie attribute in ProcScript:

variables
  string vCookieName, vCookieContent
endvariables
  vCookieName="Cookie4"
  ;Set Cookie value
  vCookieContent="%%(vCookieName)_SS_Lax"
  ;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.

References


#tofp

0 comments
28 views

Permalink