You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 22 Next »

Tapestry has a number of security features designed to harden your application against unwanted intrusion and denial of service.

Error formatting macro: contentbylabel: com.atlassian.confluence.api.service.exceptions.BadRequestException: Could not parse cql : null

HTTPS-only Pages

Main Article: HTTPS

Tapestry provides several annotations and configuration settings that you can use to ensure that all access to certain pages (or all pages) occurs only via the encrypted HTTPS protocol. See HTTPS for details.

Controlling Page Access

JumpStart Demo:
Protecting Pages

For simple access control needs, you can contribute a ComponentRequestFilter with your custom logic that decides which pages should be accessed by which users.

For more advanced needs see the Security Framework Integration section below.

White-listed Pages

Pages whose component classes are annotated with @WhitelistAccessOnly will only be displayed to users (clients) that are on the whitelist. By default the whitelist consists only of clients whose fully-qualified domain name is "localhost" (or the IP address equivalent, 127.0.0.1 or 0:0:0:0:0:0:0:1), but you can customize this by contributing to the ClientWhitelist service in your application's module class (usually AppModule.java):

AppModule.java (partial) – simple inline example
    @Contribute(ClientWhitelist.class)
    public static void provideWhitelistAnalyzer(OrderedConfiguration<WhitelistAnalyzer> configuration)
    {
        configuration.add("MyCustomAnalyzer", new WhitelistAnalyzer()
        {
            public boolean isRequestOnWhitelist(Request request)
            {
                // add your custom logic here and return true or false
                return true;
            }
        }, "before:*");
    }

 

Sometimes, in production, a firewall or proxy may make it look like the client web browser originates from localhost, with the consequence that whitelisted pages may be visible to all users. See the Security FAQ for how to deal with this.

Asset Security

Main Article: Assets

Tapestry serves assets (static content such as CSS files, images, and JavaScript, many of which are on the classpath alongside your compiled class files) to the client. Because of this, great care has gone into ensuring that certain file types cannot be served to the client. By default, file ending with ".class', ".tml" and ".properties" can be served to the client only if the request includes the file's MD5 checksum. As you would expect, that blacklist can be extended. See Asset Security for more information.

Protecting Serialized Object Data on the Client

As of version 5.3.6, Tapestry integrates a hash-based message authentication code (HMAC) into serialized Java object data that it sends to the client (generally, this means the t:formdata hidden field used by the Form component). This ensures that the hidden binary object data is guaranteed to be unaltered when it returns to the server upon form (or AJAX) submission. The HMAC pass phrase is set using the tapestry.hmac-passphrase configuration symbol. If you don't set that value, you'll see a warning message in the browser, like this: 

The symbol 'tapestry.hmac-passphrase' has not been configured. This is used to configure hash-based message authentication of Tapestry data stored in forms, or in the URL. You application is less secure, and more vulnerable to denial-of-service attacks, when this symbol is not configured.

The solution is to set the tapestry.hmac-passphrase to some value (any fixed, private string, such as 30 to 40 random-looking characters, will do) in your application's module class (usually AppModule.java).

Cross Site Request Forgery (CSRF)

Cross Site Request Forgery is a type of security vulnerability in which legitimate, authorized users may be made to unwittingly submit malicious requests to your web application.

Tapestry-csrf-protection is a 3rd party module that has several features for preventing CSRF attacks. It protects all component event handlers (event links, forms, etc.) by adding a CSRF token to event links and adds a CSRF token as a hidden field to all forms. Tokens are generated on a per-session basis.

Security Framework Integration

Tapestry does not lock you into a specific authentication/authorization implementation. Instead, there are integration modules available for the more popular open source Java security frameworks, namely Apache Shiro (formerly JSecurity) and Spring Security (formerly Acegi Security). Spring Security is the more popular of the two (because of Spring's popularity), whereas Shiro is widely regarded as the more flexible choice.

Additional information:

 

  • No labels