22. Security with Wicket

Security is one of the most important non-functional requirements we must implement in our applications. This is particularly true for enterprise applications as they usually support multiple concurrent users, and therefore they need to have an access control policy.

In this chapter we will explore the security infrastructure provided by Wicket and we will learn how to use it to implement authentication and authorizations in our web applications.

22.1. Authentication

The first step in implementing a security policy is assigning a trusted identity to our users, which means that we must authenticate them. Web applications usually adopt a form-based authentication with a login form that asks user for a unique username and the relative password:

Wicket supports form-based authentication with session class AuthenticatedWebSession and application class AuthenticatedWebApplication, both placed inside package org.apache.wicket.authroles.authentication.

22.1.1. AuthenticatedWebSession

Class AuthenticatedWebSession comes with the following set of public methods to manage user authentication:

• authenticate(String username, String password): this is an abstract method that must be implemented by every subclass of AuthenticatedWebSession. It should contain the actual code that checks for user’s identity. It returns a boolean value which is true if authentication has succeeded or false otherwise.

• signIn(String username, String password): this method internally calls authenticate and set the flag signedIn to true if authentication succeeds.

• isSignedIn():getter method for flag signedIn.

• invalidate(): sets the flag signedIn to false and invalidates session.

• signOut(): an alias of invalidate().

Another abstract method we must implement when we use AuthenticatedWebSession is getRoles which is inherited from parent class AbstractAuthenticatedWebSession. This method can be ignored for now as it will be discussed later when we will talk about role-based authorization.

22.1.2. AuthenticatedWebApplication

Class AuthenticatedWebApplication provides the following methods to support form-based authentication:

• getWebSessionClass(): abstract method that returns the session class to use for this application. The returned class must be a subclass of AbstractAuthenticatedWebSession.

• getSignInPageClass(): abstract method that returns the page to use as sign in page when a user must be authenticated.

• restartResponseAtSignInPage(): forces the current response to restart at the sign in page. After we have used this method to redirect a user, we can make her/him return to the original page calling Component‘s method continueToOriginalDestination().

The other methods implemented inside AuthenticatedWebApplication will be introduced when we talk about authorization.

22.1.3. A basic example of authentication

Project BasicAuthenticationExample is a basic example of form-based authentication implemented with classes AuthenticatedWebSession and AuthenticatedWebApplication.

The homepage of the project contains only a link to page AuthenticatedPage which can be accessed only if user is signed in. The code of AuthenticatedPage is this following:

public class AuthenticatedPage extends WebPage {
   @Override
   protected void onConfigure() {
      super.onConfigure();
      AuthenticatedWebApplication app = (AuthenticatedWebApplication)Application.get();
      //if user is not signed in, redirect him to sign in page
      if(!AuthenticatedWebSession.get().isSignedIn())
         app.restartResponseAtSignInPage();
   }
   @Override
   protected void onInitialize() {
      super.onInitialize();
      add(new BookmarkablePageLink<Void>("goToHomePage", getApplication().getHomePage()));
      add(new Link<Void>("logOut") {
         @Override
         public void onClick() {
            AuthenticatedWebSession.get().invalidate();
            setResponsePage(getApplication().getHomePage());
         }
      });
   }
}

Page AuthenticatedPage checks inside onConfigure if user is signed in and if not, it redirects her/him to the sign in page with method restartResponseAtSignInPage. The page contains also a link to the homepage and another link that signs out user.

The sign in page is implemented in class SignInPage and contains the form used to authenticate users:

public class SignInPage extends WebPage {
   private String username;
   private String password;
   @Override
   protected void onInitialize() {
      super.onInitialize();
      StatelessForm<Void> form = new StatelessForm<Void>("form") {
         @Override
         protected void onSubmit() {
            if(Strings.isEmpty(username))
               return;
            boolean authResult = AuthenticatedWebSession.get().signIn(username, password);
            //if authentication succeeds redirect user to the requested page
            if(authResult)
               continueToOriginalDestination();
         }
      };
      form.setModel(new CompoundPropertyModel(this));
      form.add(new TextField("username"));
      form.add(new PasswordTextField("password"));
      add(form);
   }
}

The form is responsible for handling user authentication inside its method onSubmit(). The username and password are passed to AuthenticatedWebSession‘s method signIn(username, password) and if authentication succeeds, the user is redirected to the original page with method continueToOriginalDestination.

The session class and the application class used in the project are reported here:

Session class:

public class BasicAuthenticationSession extends AuthenticatedWebSession {
        public BasicAuthenticationSession(Request request) {
                super(request);
        }
        @Override
        public boolean authenticate(String username, String password) {
              //user is authenticated if both username and password are equal to 'wicketer'
                return username.equals(password) && username.equals("wicketer");
        }
        @Override
        public Roles getRoles() {
                return new Roles();
        }
}

Application class:

public class WicketApplication extends AuthenticatedWebApplication {
        @Override
        public Class<HomePage> getHomePage(){
                return HomePage.class;
        }
        @Override
        protected Class<? extends AbstractAuthenticatedWebSession> getWebSessionClass(){
                return BasicAuthenticationSession.class;
        }
        @Override
        protected Class<? extends WebPage> getSignInPageClass() {
                return SignInPage.class;
        }
}

The authentication logic inside authenticate has been kept quite trivial in order to make the code as clean as possible. Please note also that session class must have a constructor that accepts an instance of class Request.

22.1.4. Redirecting user to an intermediate page

Method restartResponseAtSignInPage is an example of redirecting user to an intermediate page before allowing him to access to the requested page. This method internally throws exception org.apache.wicket.RestartResponseAtInterceptPageException which saves the URL and the parameters of the requested page into session metadata and then redirects user to the page passed as constructor parameter (the sign in page).

Component’s method redirectToInterceptPage(Page) works in much the same way as restartResponseAtSignInPage but it allows us to specify which page to use as intermediate page:

    redirectToInterceptPage(intermediatePage);

22.2. Authorizations

The authorization support provided by Wicket is built around the concept of authorization strategy which is represented by interface IAuthorizationStrategy (in package org.apache.wicket.authorization):

public interface IAuthorizationStrategy {
 //interface methods
 <T extends IRequestableComponent> boolean isInstantiationAuthorized(Class<T> componentClass);
 boolean isActionAuthorized(Component component, Action action);
 //default authorization strategy that allows everything
 public static final IAuthorizationStrategy ALLOW_ALL = new IAuthorizationStrategy()
 {
  @Override
  public <T extends IRequestableComponent> boolean isInstantiationAuthorized(final Class<T> c)
  {
    return true;
  }
  @Override
  public boolean isActionAuthorized(Component c, Action action)
  {
    return true;
  }
 };
}

This interface defines two methods:

• isInstantiationAuthorized() checks if user is allowed to instantiate a given component.

• isActionAuthorized() checks if user is authorized to perform a given action on a component’s instance. The standard actions checked by this method are defined into class Action and are Action.ENABLE and Action.RENDER.

Inside IAuthorizationStrategy we can also find a default implementation of the interface (called ALLOW_ALL) that allows everyone to instantiate every component and perform every possible action on it. This is the default strategy adopted by class Application.

To change the authorization strategy in use we must register the desired implementation into security settings (class SecuritySettings) during initialization phase with method setAuthorization Strategy:

  //Application class code...
  @Override
  public void init()
  {
    super.init();
    getSecuritySettings().
    setAuthorizationStrategy(myAuthorizationStrategy);
  }
//...

If we want to combine the action of two or more authorization strategies we can chain them with strategy CompoundAuthorizationStrategy which implements composite pattern for authorization strategies.

Most of the times we won’t need to implement an IAuthorizationStrategy from scratch as Wicket already comes with a set of built-in strategies. In the next paragraphs we will see some of these strategies that can be used to implement an effective and flexible security policy.

22.2.1. SimplePageAuthorizationStrategy

Abstract class SimplePageAuthorizationStrategy (in package org.apache.wicket.authorization.strategies.page) is a strategy that checks user authorizations calling abstract method isAuthorized only for those pages that are subclasses of a given supertype. If isAuthorized returns false, the user is redirected to the sign in page specified as second constructor parameter:

SimplePageAuthorizationStrategy authorizationStrategy = new SimplePageAuthorizationStrategy(
                                                  PageClassToCheck.class, SignInPage.class)
{
  protected boolean isAuthorized()
  {
    //Authentication code...
  }
};

By default SimplePageAuthorizationStrategy checks for permissions only on pages. If we want to change this behavior and check also other kinds of components, we must override method isActionAuthorized() and implement our custom logic inside it.

22.2.2. Role-based strategies

At the end of paragraph 22.1 we have introduced AbstractAuthenticatedWebSession’s method getRoles() which is provided to support role-based authorization returning the set of roles granted to the current user.

In Wicket roles are simple strings like “BASIC_USER” or “ADMIN” (they don’t need to be capitalized) and they are handled with class org.apache.wicket.authroles.authorization.strategies.role.Roles. This class extends standard HashSet collection adding some functionalities to check whether the set contains one or more roles. Class Roles already defines roles Roles.USER and Roles.ADMIN.

The session class in the following example returns a custom “SIGNED_IN” role for every authenticated user and it adds an Roles.ADMIN role if username is equal to superuser:

class BasicAuthenticationRolesSession extends AuthenticatedWebSession {
        private String userName;
        public BasicAuthenticationRolesSession(Request request) {
                super(request);
        }
        @Override
        public boolean authenticate(String username, String password) {
                boolean authResult= false;
                authResult = //some authentication logic...
                if(authResult)
                        userName = username;
                return authResult;
        }
        @Override
        public Roles getRoles() {
                Roles resultRoles = new Roles();
                if(isSignedIn())
                        resultRoles.add("SIGNED_IN");
                if(userName.equals("superuser"))
                        resultRoles.add(Roles.ADMIN);
                return resultRoles;
        }
}

Roles can be adopted to apply security restrictions on our pages and components. This can be done using one of the two built-in authorization strategies that extend super class AbstractRoleAuthorizationStrategyWicket: MetaDataRoleAuthorizationStrategy and AnnotationsRoleAuthorizationStrategy

The difference between these two strategies is that MetaDataRoleAuthorizationStrategy handles role-based authorizations with Wicket metadata while AnnotationsRoleAuthorizationStrategy uses Java annotations.

The code that we will see in the next examples is for illustrative purpose only. If our application class inherits from AuthenticatedWebApplication we won’t need to configure anything to use these two strategies.

Using roles with metadata

Strategy MetaDataRoleAuthorizationStrategy uses application and components metadata to implement role-based authorizations. The class defines a set of static methods authorize that can be used to specify which roles are allowed to instantiate a component and which roles can perform a given action on a component.

The following code snippet reports both application and session classes from project MetaDataRolesStrategyExample and illustrates how to use MetaDataRoleAuthorizationStrategy to allow access to a given page (AdminOnlyPage) only to ADMIN role:

Application class:

public class WicketApplication extends AuthenticatedWebApplication {
   @Override
   public Class<? extends WebPage> getHomePage(){
      return HomePage.class;
   }
   @Override
   protected Class<? extends AbstractAuthenticatedWebSession> getWebSessionClass() {
      return BasicAuthenticationSession.class;
   }
   @Override
   protected Class<? extends WebPage> getSignInPageClass() {
      return SignInPage.class;
   }
   @Override
   public void init(){
      getSecuritySettings().setAuthorizationStrategy(new MetaDataRoleAuthorizationStrategy(this));
      MetaDataRoleAuthorizationStrategy.authorize(AdminOnlyPage.class, Roles.ADMIN);
   }
}

Session class:

public class BasicAuthenticationSession extends AuthenticatedWebSession {
   private String username;
   public BasicAuthenticationSession(Request request) {
      super(request);
   }
   @Override
   public boolean authenticate(String username, String password) {
      //user is authenticated if username and password are equal
     boolean authResult = username.equals(password);
      if(authResult)
         this.username = username;
      return authResult;
   }
   public Roles getRoles() {
      Roles resultRoles = new Roles();
      //if user is signed in add the relative role
      if(isSignedIn())
         resultRoles.add("SIGNED_IN");
      //if username is equal to 'superuser' add the ADMIN role
      if(username!= null && username.equals("superuser"))
         resultRoles.add(Roles.ADMIN);
      return resultRoles;
   }
   @Override
   public void signOut() {
      super.signOut();
      username = null;
   }
}

The code that instantiates MetaDataRoleAuthorizationStrategy and set it as application’s strategy is inside application class method init().

Any subclass of AbstractRoleAuthorizationStrategyWicket needs an implementation of interface IRoleCheckingStrategy to be instantiated. For this purpose in the code above we used the application class itself because its base class AuthenticatedWebApplication already implements interface IRoleCheckingStrategy. By default AuthenticatedWebApplication checks for authorizations using the roles returned by the current AbstractAuthenticatedWebSession. As final step inside init we grant the access to page AdminOnlyPage to ADMIN role calling method authorize.

The code from session class has three interesting methods. The first is authenticate() which considers as valid credentials every pair of username and password having the same value. The second notable method is getRoles() which returns role SIGNED_IN if user is authenticated and it adds role ADMIN if username is equal to superuser. Finally, we have method signOut() which has been overridden in order to clean the username field used internally to generate roles.

Now if we run the project and we try to access to AdminOnlyPage from the home page without having the ADMIN role, we will be redirected to the default access-denied page used by Wicket:

The access-denied page can be customized using method setAccessDeniedPage(Class<? extends Page>) of setting class ApplicationSettings:

   //Application class code...
   @Override
   public void init(){
      getApplicationSettings().setAccessDeniedPage(
                        MyCustomAccessDeniedPage.class);
   }

Just like custom “Page expired” page (see chapter 8.2.5), also custom “Access denied” page must be bookmarkable.

Using roles with annotations

Strategy AnnotationsRoleAuthorizationStrategy relies on two built-in annotations to handle role-based authorizations. These annotations are AuthorizeInstantiation and AuthorizeAction. As their names suggest the first annotation specifies which roles are allowed to instantiate the annotated component while the second must be used to indicate which roles are allowed to perform a specific action on the annotated component.

In the following example we use annotations to make a page accessible only to signed-in users and to enable it only if user has the ADMIN role:

@AuthorizeInstantiation("SIGNED_IN")
@AuthorizeAction(action = "ENABLE", roles = {"ADMIN"})
public class MyPage extends WebPage {
   //Page class code...
}

Remember that when a component is not enabled, user can render it but he can neither click on its links nor interact with its forms.

Example project AnnotationsRolesStrategyExample is a revisited version of MetaDataRolesStrategyExample where we use AnnotationsRoleAuthorizationStrategy as authorization strategy. To ensure that page AdminOnlyPage is accessible only to ADMIN role we have used the following annotation:

@AuthorizeInstantiation("ADMIN")
public class AdminOnlyPage extends WebPage {
    //Page class code...
}

22.2.3. Catching an unauthorized component instantiation

Interface IUnauthorizedComponentInstantiationListener (in package org.apache.wicket.authorization) is provided to give the chance to handle the case in which a user tries to instantiate a component without having the permissions to do it. The method defined inside this interface is onUnauthorizedInstantiation(Component) and it is executed whenever a user attempts to execute an unauthorized instantiation.

This listener must be registered into application’s security settings with method setUnauthorizedComponentInstantiationListener defined by setting class SecuritySettings. In the following code snippet we register a listener that redirect user to a warning page if he tries to do a not-allowed instantiation:

public class WicketApplication extends AuthenticatedWebApplication{
     //Application code...
     @Override
     public void init(){
        getSecuritySettings().setUnauthorizedComponentInstantiationListener(
                        new IUnauthorizedComponentInstantiationListener() {
            @Override
            public void onUnauthorizedInstantiation(Component component) {
                component.setResponsePage(AuthWarningPage.class);
            }
        });
     }
}

In addition to interface IRoleCheckingStrategy, class AuthenticatedWebApplication implements also IUnauthorizedComponentInstantiationListener and registers itself as listener for unauthorized instantiations.

By default AuthenticatedWebApplication redirects users to sign-in page if they are not signed-in and they try to instantiate a restricted component. Otherwise, if users are already signed in but they are not allowed to instantiate a given component, an UnauthorizedInstantiationException will be thrown.

22.2.4. Strategy RoleAuthorizationStrategy

Class RoleAuthorizationStrategy is a compound strategy that combines both MetaDataRoleAuthorizationStrategy and AnnotationsRoleAuthorizationStrategy.

This is the strategy used internally by AuthenticatedWebApplication.

22.3. Using HTTPS protocol

HTTPS is the standard technology adopted on Internet to create a secure communication channel between web applications and their users.

In Wicket we can easily protect our pages with HTTPS mounting a special request mapper called HttpsMapper and using annotation RequireHttps with those pages we want to serve over this protocol. Both these two entities are in package org.apache.wicket.protocol.https.

HttpsMapper wraps an existing mapper and redirects incoming requests to HTTPS if the related response must render a page annotated with RequireHttps. Most of the times the wrapped mapper will be the root one, just like we saw before for CryptoMapper in paragraph 10.6.

Another parameter needed to build a HttpsMapper is an instance of class HttpsConfig. This class allows us to specify which ports must be used for HTTPS and HTTP. By default the port numbers used by these two protocols are respectively 443 and 80.

The following code is taken from project HttpsProtocolExample and illustrates how to enable HTTPS in our applications:

//Application class code...
@Override
public void init(){
   setRootRequestMapper(new HttpsMapper(getRootRequestMapper(),
                                       new HttpsConfig(8080, 8443)));
}

Now we can use annotation RequireHttps to specify which pages must be served using HTTPS:

@RequireHttps
public class HomePage extends WebPage {
    public HomePage(final PageParameters parameters) {
            super(parameters);
    }
}

If we want to protect many pages with HTTPS without adding annotation RequireHttps to each of them, we can annotate a marker interface or a base page class and implement/extend it in any page we want to make secure:

// Marker interface:
@RequireHttps
public interface IMarker {
}
// Base class:
@RequireHttps
public class BaseClass extends WebPage {
//Page code...
}
// Secure page inheriting from BaseClass:
public class HttpsPage extends BaseClass {
//Page code...
}
// Secure page implementing IMarker:
public class HttpsPage implements IMarker {
//Page code...
}

22.4. URLs encryption in detail

In chapter 10.6 we have seen how to encrypt URLs using CryptoMapper request mapper. To encrypt/decrypt page URLs CryptoMapper uses an instance of org.apache.wicket.util.crypt.ICrypt interface:

public interface ICrypt
{
        String encryptUrlSafe(final String plainText);
        String decryptUrlSafe(final String encryptedText);
        ...
}

The default implementation for this interface is class org.apache.wicket.util.crypt.SunJceCrypt. It provides password-based cryptography using PBEWithMD5AndDES algorithm coming with the standard security providers in the Java Runtime Environment.

By using CryptoMapper(IRequestMapper wrappedMapper, Application application) constructor the mapper will use the configured org.apache.wicket.util.crypt.ICryptFactory from org.apache.wicket.settings.SecuritySettings.getCryptFactory(). To use a stronger cryptography mechanism there are the following options:

• The first option is to use constructor CryptoMapper(IRequestMapper wrappedMapper, Supplier cryptProvider) and give it an implementation of java.util.function.Supplier that returns a custom org.apache.wicket.util.crypt.ICrypt.

• The second option is to register a cipher factory at application level with method setCryptFactory(ICryptFactory cryptFactory) of class SecuritySettings:

@Override
public void init() {
        super.init();
        getSecuritySettings().setCryptFactory(new SomeCryptFactory());
        setRootRequestMapper(new CryptoMapper(getRootRequestMapper(), this));
}

Since version 6.19.0 Wicket uses org.apache.wicket.core.util.crypt.KeyInSessionSunJceCryptFactory as a default factory for ICrypt objects. This factory generates a unique key for each user that is stored in her HTTP session. This way it helps to protect the application against CSRF) for each user of the application. The url itself serves as encrypted token_Prevention_Cheat_Sheet#Encrypted_Token_Pattern)

22.5. CSRF protection

CryptoMapper helps preventing CSRF attacks by making the urls impossible to be guessed by an attacker but still there is some theoretical chance this to happen.

To further help against this kind of vulnerability Wicket provides CsrfPreventionRequestCycleListener - a IRequestCycleListener that forbids requests made from a different origin. By default only actions are forbidden, i.e. a request coming from different origin cannot execute Link.onClick() or submit forms (Form.onSubmit()). Any request to render pages are still allowed so Wicket pages could be easily embedded in other applications.

MyApplication.java

  @Override
 protected void init() {
  super.init();
  getRequestCycleListeners().add(new CsrfPreventionRequestCycleListener());
  // ...
 }

CsrfPreventionRequestCycleListener is highly configurable. It allows to define a whitelist of allowed origins via addAcceptedOrigin(String acceptedOrigin), to enable/disable it dynamically by overriding isEnabled(), to define different kind of actions when a request is rejected or allowed, to set custom error message and code for the rejected requests.

CsrfPreventionRequestCycleListener is not an alternative to CryptoMapper! Both of them could be used separately or in tandem to prevent CSRF attacks depending on the application requirements.

22.6. Content Security Policy (CSP)

In Wicket 9 support for a Content Security Policy (or CSP) has been added. CSP is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks. These attacks are used for everything from data theft to site defacement to distribution of malware. See MDN for more information on CSP.

The default CSP set by Wicket is very strict. It requires all scripts and stylesheets to be rendered with a nonce. Wicket will automatically attach the nonce to all header contributions that support this (i.e. subclasses of the AbstractCspHeaderItem class). Images, fonts and (i)frames are allowed from self, the current host. All other resources are blocked. This includes any inline styling or Javascript (such as an onclick attribute). The exact CSP is:

Content-Security-Policy: default-src 'none'; script-src 'strict-dynamic' 'nonce-XYZ'; style-src 'nonce-XYZ'; img-src 'self'; connect-src 'self'; font-src 'self'; manifest-src 'self'; child-src 'self'; frame-src 'self'; base-uri 'self';

In developer mode, the CSP is extended with a reporting directive that reports violations at a special endpoint in the application that logs the violation. This is conveniant while developing an application, but care should be taken when this is enabled on production. The cspviolation endpoint must be an open endpoint and all data sent to that URL will end up in the logs. To prevent the server log from filling the disk, make sure the org.apache.wicket.csp.ReportCSPViolationMapper logger has a limit on its disk usage.

22.6.1. Configuring the Content Security Policy

The Content Security Policy is managed by the ContentSecurityPolicySettings that can be accessed via WebApplication.getCspSettings(). This class maintains two instances of CSPHeaderConfiguration, each of which contains the directives for the CSP HTTP headers Content-Security-Policy and Content-Security-Policy-Report-Only. The first header defines the policies that are actually enforced by the browser, whereas the second header defines a policy for which the browser will only report violations. Note that violations can also be reported on the enforced policy and that reporting requires a report-uri directive.

For applications that cannot adhere to a CSP, the CSP can be disabled with the following call in your Application class:

  @Override
 protected void init() {
  super.init();
  getCspSettings().blocking().disabled();
  // ...
 }

As mentioned before, Wicket uses a very strict CSP by default. This preset can be selected with the following code:

  getCspSettings().blocking().strict();

A thrid preset is available that allows unsafe inline Javascript and styling and the use of unsafe eval. As can be inferred from the names, use of unsafe is not recommended. It removes the most important protection offered by CSP. However, older applications may not be ready to apply a strict CSP. For those applications, CSPHeaderConfiguration.unsafeInline() can be a starting point for the path to a strict CSP.

CSPHeaderConfiguration defines several methods to tune the Content Security Policy for your application. Additional sources can be whitelisted for certain via the add(CSPDirective, …​) methods. For example, the code below whitelists images rendered via a data: url, fonts loaded from https://maxcdn.bootstrapcdn.com and a single CSS file.

  getCspSettings().blocking()
      .add(CSPDirective.IMG_SRC, "data:")
      .add(CSPDirective.FONT_SRC, "https://maxcdn.bootstrapcdn.com")
      .add(CSPDirective.STYLE_SRC,
           "https://maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css");

22.6.2. Guidelines for strict CSP support

To comply to the strict CSP set by default, you’ll need to follow a few rules. Most importantly, you cannot use inline styling or Javascript. This includes:

• style attributes in the markup or via an AttributeModifier.

• Inline event handlers, such as onclick or onsubmit, in the markup or via an AttributeModifier.

• Including stylesheets directly from the markup without whitelisting them.

• Including Javascript directly from the markup. Whitelisting is not possible due to the strict-dynamic rule.

• Rendering style attributes from Javascript in dynamically generated markup. Modifying the style DOM property is still possible.

• Load other resources from external domains without whitelisting them.

For most of these restrictions Wicket provides alternative solutions that do work with a strict CSP. First of all, replace all inline styling with proper stylesheets and use CSS selectors to target the elements in the DOM. Replace the AttributeModifier with a style attribute for one with the class attribute. For Javascripts that manipulate the style attribute, you may have to update the script to use the DOM property instead.

When a component includes a stylesheet directly from the markup as seen below, there are two possible solutions:

<?xml version="1.0" encoding="UTF-8"?>
<html xmlns:wicket="http://wicket.apache.org">
<head>
  <link rel="stylesheet"
    href="https://maxcdn.bootstrapcdn.com/font-awesome/4.3.0/css/font-awesome.min.css" />
</head>
<body>...</body>
</html>

The first solution is to whitelist the stylesheet, as seen above. The second solution is to move the stylesheet to a header contribution in renderHead. This will allow Wicket to render the required nonce attribute. For Javascript resources, this is the only possible solution:

 @Override
 public void renderHead(IHeaderResponse response) {
   super.renderHead(response);
   response.render(CssHeaderItem.forReference(
       new CssResourceReference(MyComponent.class, "mycomponent.css")));
 }

When your component relies on inline event handlers, such as onclick or onsubmit, you can convert these to an OnEventHeaderItem. Again, this will allow Wicket to add the required nonce attribute.

 @Override
 public void renderHead(IHeaderResponse response) {
   super.renderHead(response);
   response.render(OnEventHeaderItem.forComponent(this, "submit",
       "return confirm('Do you really want to submit?')"));
 }

22.7. Package Resource Guard

Wicket internally uses an entity called package resource guard to protect package resources from external access. This entity is an implementation of interface org.apache.wicket.markup.html.IPackageResourceGuard.

By default Wicket applications use as package resource guard class SecurePackageResourceGuard, which allows to access only to the following file extensions (grouped by type):

To modify the set of allowed files formats we can add one or more patterns with method addPattern(String). The rules to write a pattern are the following:

• patterns start with either a “+” or a “-“ In the first case the pattern will add one or more file to the set while starting a pattern with a “-” we exclude all the files matching the given pattern. For example pattern “-web.xml” excludes all web.xml files in all directories.

• wildcard character “*” is supported as placeholder for zero or more characters. For example pattern “+\*.mp4” adds all the mp4 files inside all directories.

• subdirectories are supported as well. For example pattern “+documents/*.pdf” adds all pdf files under “documents” directory. Character “\*” can be used with directories to specify a nesting level. For example “+documents/*/\*.pdf” adds all pdf files placed one level below “documents” directory.

• a double wildcard character “*\*” indicates zero or more subdirectories. For example pattern “+documents/*\*/\*.pdf” adds all pdf files placed inside “documents” directory or inside any of its subdirectories.

Patterns that allow to access to every file with a given extensions (such as “+\*.pdf”) should be always avoided in favour of more restrictive expressions that contain a directory structure:

//Application class code...
@Override
public void init()
{
      IPackageResourceGuard packageResourceGuard = application.getResourceSettings()
                                                   .getPackageResourceGuard();
      if (packageResourceGuard instanceof SecurePackageResourceGuard)
      {
         SecurePackageResourceGuard guard = (SecurePackageResourceGuard) packageResourceGuard;
         //Allow to access only to pdf files placed in the “public” directory.
         guard.addPattern("+public/*.pdf");
      }
}

22.8. External Security Checks

Since Mozilla released their site to check if web pages have security issues named Mozilla Observatory a few things which can be done to get a high grade within this ranking without using further frameworks.

Add a request cycle listener to your web application and adjust the headers to fit your requirements:

@Override
protected void init()
{
   super.init();
   getRequestCycleListeners().add(new AbstractRequestCycleListener(){
      @Override
      public void onEndRequest(RequestCycle cycle)
      {
         WebResponse response = (WebResponse) cycle.getResponse();
         response.setHeader("X-XSS-Protection", "1; mode=block");
         response.setHeader("Strict-Transport-Security", "max-age=31536000; includeSubDomains; preload");
         response.setHeader("X-Content-Type-Options", "nosniff");
         response.setHeader("X-Frame-Options", "sameorigin");
         response.setHeader("Content-Security-Policy", "default-src https:");
      }
   });
}

Add this configuration to your web.xml (or let your server redirect to https):

<?xml version="1.0" encoding="UTF-8"?>
<security-constraint>
    <web-resource-collection>
        <web-resource-name>Entire Application</web-resource-name>
        <url-pattern>/*</url-pattern>
    </web-resource-collection>
    <user-data-constraint>
        <transport-guarantee>CONFIDENTIAL</transport-guarantee>
    </user-data-constraint>
</security-constraint>

After this changes you have to check if your web application continues to work because it fits the requirements given with these headers. For example that resources could not be requested from other domains anymore.

22.9. Summary

In this chapter we have seen the components and the mechanisms that allow us to implement security policies in our Wicket-based applications. Wicket comes with an out of the box support for both authorization and authentication.

The central element of authorization mechanism is the interface IAuthorizationStrategy which decouples our components from any detail about security strategy. The implementations of this interface must decide if a user is allowed to instantiate a given page or component and if she/he can perform a given action on it.

Wicket natively supports role-based authorizations with strategies MetaDataRoleAuthorizationStrategy and AnnotationsRoleAuthorizationStrategy. The difference between these two strategies is that the first offers a programmatic approach for role handling while the second promotes a declarative approach using built-in annotations.

After having explored how Wicket internally implements authentication and authorization, we continued with how to configure our applications to support HTTPS and how to specify which pages must be served over this protocol.

We’ve explored the protection Wicket offers against CSRF attacks with URL encryption and the CsrfPreventionRequestCycleListener. This was followed by an explanation of the Content Security Policy used by Wicket and how to tune this for your application.

In the last paragraph we have seen how Wicket protects package resources with a guard entity that allows us to decide which package resources can be accessed from users.