(Quick Reference) # 17 Security Version: 6.0.0 ## Table of Contents # 17 Security Grails is no more or less secure than Java Servlets. However, Java servlets (and hence Grails) are extremely secure and largely immune to common buffer overrun and malformed URL exploits due to the nature of the Java Virtual Machine underpinning the code. Web security problems typically occur due to developer naivety or mistakes, and there is a little Grails can do to avoid common mistakes and make writing secure applications easier to write. #### What Grails Automatically Does Grails has a few built in safety mechanisms by default. All standard database access via GORM domain objects is automatically SQL escaped to prevent SQL injection attacks The default scaffolding templates HTML escape all data fields when displayed Grails link creating tags (link, form, createLink, createLinkTo and others) all use appropriate escaping mechanisms to prevent code injection Grails provides codecs to let you trivially escape data when rendered as HTML, JavaScript and URLs to prevent injection attacks here. ## 17.1 Securing Against Attacks #### SQL injection Hibernate, which is the technology underlying GORM domain classes, automatically escapes data when committing to database so this is not an issue. However it is still possible to write bad dynamic HQL code that uses unchecked request parameters. For example doing the following is vulnerable to HQL injection attacks:
    def vulnerable() {
        def books = Book.find("from Book as b where b.title ='" + params.title + "'")
    }
or the analogous call using a GString:
    def vulnerable() {
        def books = Book.find("from Book as b where b.title ='${params.title}'")
    }
Do not do this. Use named or positional parameters instead to pass in parameters:
    def safe() {
        def books = Book.find("from Book as b where b.title = ?",
                              [params.title])
    }
or
    def safe() {
        def books = Book.find("from Book as b where b.title = :title",
                              [title: params.title])
    }
#### Phishing This really a public relations issue in terms of avoiding hijacking of your branding and a declared communication policy with your customers. Customers need to know how to identify valid emails. #### XSS - cross-site scripting injection It is important that your application verifies as much as possible that incoming requests were originated from your application and not from another site. It is also important to ensure that all data values rendered into views are escaped correctly. For example when rendering to HTML or XHTML you must ensure that people cannot maliciously inject JavaScript or other HTML into data or tags viewed by others. Grails 2.3 and above include special support for automatically encoded data placed into GSP pages. See the documentation on Cross Site Scripting (XSS) prevention for further information. You must also avoid the use of request parameters or data fields for determining the next URL to redirect the user to. If you use a `successURL` parameter for example to determine where to redirect a user to after a successful login, attackers can imitate your login procedure using your own site, and then redirect the user back to their own site once logged in, potentially allowing JavaScript code to then exploit the logged-in account on the site. #### Cross-site request forgery CSRF involves unauthorized commands being transmitted from a user that a website trusts. A typical example would be another website embedding a link to perform an action on your website if the user is still authenticated. The best way to decrease risk against these types of attacks is to use the `useToken` attribute on your forms. See Handling Duplicate Form Submissions for more information on how to use it. An additional measure would be to not use remember-me cookies. #### HTML/URL injection This is where bad data is supplied such that when it is later used to create a link in a page, clicking it will not cause the expected behaviour, and may redirect to another site or alter request parameters. HTML/URL injection is easily handled with the codecs supplied by Grails, and the tag libraries supplied by Grails all use encodeAsURL where appropriate. If you create your own tags that generate URLs you will need to be mindful of doing this too. #### Denial of service Load balancers and other appliances are more likely to be useful here, but there are also issues relating to excessive queries for example where a link is created by an attacker to set the maximum value of a result set so that a query could exceed the memory limits of the server or slow the system down. The solution here is to always sanitize request parameters before passing them to dynamic finders or other GORM query methods:
    int limit = 100
    def safeMax = Math.min(params.max?.toInteger() ?: limit, limit) // limit to 100 results
    return Book.list(max:safeMax)
#### Guessable IDs Many applications use the last part of the URL as an "id" of some object to retrieve from GORM or elsewhere. Especially in the case of GORM these are easily guessable as they are typically sequential integers. Therefore you must assert that the requesting user is allowed to view the object with the requested id before returning the response to the user. Not doing this is "security through obscurity" which is inevitably breached, just like having a default password of "letmein" and so on. You must assume that every unprotected URL is publicly accessible one way or another. ## 17.2 Cross Site Scripting (XSS) Prevention Cross Site Scripting (XSS) attacks are a common attack vector for web applications. They typically involve submitting HTML or Javascript code in a form such that when that code is displayed, the browser does something nasty. It could be as simple as popping up an alert box, or it could be much worse like for example one could access other users session cookies. The solution is to escape all untrusted user input when it is displayed in a page. For example,
    <script>alert('Got ya!');</script>
will become
    &lt;script&gt;alert('Got ya!');&lt;/script&gt;
when rendered, nullifying the effects of the malicious input. By default, Grails plays it safe and escapes all content in `${}` expressions in GSPs. All the standard GSP tags are also safe by default, escaping any relevant attribute values. So what happens when you want to stop Grails from escaping some content? There are valid use cases for putting HTML into the database and rendering it as-is, as long as that content is trusted. In such cases, you can tell Grails that the content is safe as should be rendered raw, i.e. without any escaping:
    <section>${raw(page.content)}</section>
The `raw()` method you see here is available from controllers, tag libraries and GSP pages. XSS prevention is hard and requires a lot of developer attention
| Although Grails plays it safe by default, that is no guarantee that your application will be invulnerable to an XSS-style attack. Such an attack is less likely to succeed than would otherwise be the case, but developers should always be conscious of potential attack vectors and attempt to uncover vulnerabilities in the application during testing. It’s also easy to switch to an unsafe default, thereby increasing the risk of a vulnerability being introduced.
There are more details about the XSS in OWASP - XSS prevention rules and OWASP - Types of Cross-Site Scripting. Types of XSS are: Stored XSS, Reflected XSS and DOM based XSS. DOM based XSS prevention is coming more important because of the popularity of Javascript client side templating and Single Page Apps. Grails codecs are mainly for preventing stored and reflected XSS type of attacks. Grails 2.4 includes HTMLJS codec that assists in preventing some DOM based XSS attacks. It’s difficult to make a solution that works for everyone, and so Grails provides a lot of flexibility with regard to fine-tuning how escaping works, allowing you to keep most of your application safe while switching off default escaping or changing the codec used for pages, tags, page fragments, and more. #### Configuration It is recommended that you review the configuration of a newly created Grails application to garner an understanding of XSS prevention works in Grails. When you tag a cookie with the HttpOnly flag, it tells the browser that this particular cookie should only be accessed by the server. Any attempt to access the cookie from client script is strictly forbidden. This can be configured in the `application.yml` configuration file as seen below:
    server:
        session:
            cookie:
                domain: example.org
                http-only: true
                path: /
                secure: true
GSP features the ability to automatically HTML encode GSP expressions, and as of Grails 2.3 this is the default configuration. The default configuration (found in `application.yml`) for a newly created Grails application can be seen below:
    grails:
        views:
            gsp:
                encoding: UTF-8
                htmlcodec: xml # use xml escaping instead of HTML4 escaping
                codecs:
                    expression: html # escapes values inside ${}
                    scriptlets: html # escapes output from scriptlets in GSPs
                    taglib: none # escapes output from taglibs
                    staticparts: none # escapes output from static template parts
GSP features several codecs that it uses when writing the page to the response. The codecs are configured in the `codecs` block and are described below: `expression` - The expression codec is used to encode any code found within ${..} expressions. The default for newly created application is `html` encoding. `scriptlet` - Used for output from GSP scriplets (<% %>, <%= %> blocks). The default for newly created applications is `html` encoding `taglib` - Used to encode output from GSP tag libraries. The default is `none` for new applications, as typically it is the responsibility of the tag author to define the encoding of a given tag and by specifying `none` Grails remains backwards compatible with older tag libraries. `staticparts` - Used to encode the raw markup output by a GSP page. The default is `none`. #### Double Encoding Prevention Versions of Grails prior to 2.3, included the ability to set the default codec to `html`, however enabling this setting sometimes proved problematic when using existing plugins due to encoding being applied twice (once by the `html` codec and then again if the plugin manually called `encodeAsHTML`). Grails 2.3 includes double encoding prevention so that when an expression is evaluated, it will not encode if the data has already been encoded (Example `${foo.encodeAsHTML()}`). #### Raw Output If you are 100% sure that the value you wish to present on the page has not been received from user input, and you do not wish the value to be encoded then you can use the `raw` method:
    ${raw(book.title)}
The 'raw' method is available in tag libraries, controllers and GSP pages. #### Per Plugin Encoding Grails also features the ability to control the codecs used on a per plugin basis. For example if you have a plugin named `foo` installed, then placing the following configuration in your `application.groovy` will disable encoding for only the `foo` plugin
    foo.grails.views.gsp.codecs.expression = "none"
#### Per Page Encoding You can also control the various codecs used to render a GSP page on a per page basis, using a page directive:
    <%@page expressionCodec="none" %>
#### Per Tag Library Encoding Each tag library created has the opportunity to specify a default codec used to encode output from the tag library using the "defaultEncodeAs" property:
    static defaultEncodeAs = 'html'
Encoding can also be specified on a per tag basis using "encodeAsForTags":
    static encodeAsForTags = [tagName: 'raw']
#### Context Sensitive Encoding Switching Certain tags require certain encodings and Grails features the ability to enable a codec only a certain part of a tag’s execution using the "withCodec" method. Consider for example the "<g:javascript>"" tag which allows you to embed JavaScript code in the page. This tag requires JavaScript encoding, not HTML coding for the execution of the body of the tag (but not for the markup that is output):
    out.println '<script type="text/javascript">'
        withCodec("JavaScript") {
            out << body()
        }
        out.println()
        out.println '</script>'
#### Forced Encoding for Tags If a tag specifies a default encoding that differs from your requirements you can force the encoding for any tag by passing the optional 'encodeAs' attribute:
    <g:message code="foo.bar" encodeAs="JavaScript" />
#### Default Encoding for All Output The default configuration for new applications is fine for most use cases, and backwards compatible with existing plugins and tag libraries. However, you can also make your application even more secure by configuring Grails to always encode all output at the end of a response. This is done using the `filteringCodecForContentType` configuration in `application.groovy`:
    grails.views.gsp.filteringCodecForContentType.'text/html' = 'html'
Note that, if activated, the `staticparts` codec typically needs to be set to `raw` so that static markup is not encoded:
    codecs {
            expression = 'html' // escapes values inside ${}
            scriptlet = 'html' // escapes output from scriptlets in GSPs
            taglib = 'none' // escapes output from taglibs
            staticparts = 'raw' // escapes output from static template parts
        }
## 17.3 Encoding and Decoding Objects Grails supports the concept of dynamic encode/decode methods. A set of standard codecs are bundled with Grails. Grails also supports a simple mechanism for developers to contribute their own codecs that will be recognized at runtime. #### Codec Classes A Grails codec class is one that may contain an encode closure, a decode closure or both. When a Grails application starts up the Grails framework dynamically loads codecs from the `grails-app/utils/` directory. The framework looks under `grails-app/utils/` for class names that end with the convention `Codec`. For example one of the standard codecs that ships with Grails is `HTMLCodec`. If a codec contains an `encode` closure Grails will create a dynamic `encode` method and add that method to the `Object` class with a name representing the codec that defined the encode closure. For example, the `HTMLCodec` class defines an `encode` closure, so Grails attaches it with the name `encodeAsHTML`. The `HTMLCodec` and `URLCodec` classes also define a `decode` closure, so Grails attaches those with the names `decodeHTML` and `decodeURL` respectively. Dynamic codec methods may be invoked from anywhere in a Grails application. For example, consider a case where a report contains a property called 'description' which may contain special characters that must be escaped to be presented in an HTML document. One way to deal with that in a GSP is to encode the description property using the dynamic encode method as shown below:
    ${report.description.encodeAsHTML()}
Decoding is performed using `value.decodeHTML()` syntax. #### Encoder and Decoder interfaces for staticly compiled code A preferred way to use codecs is to use the codecLookup bean to get hold of `Encoder` and `Decoder` instances .
    package org.grails.encoder;

    public interface CodecLookup {
        public Encoder lookupEncoder(String codecName);
        public Decoder lookupDecoder(String codecName);
    }
example of using `CodecLookup` and `Encoder` interface
    import org.grails.encoder.CodecLookup

    class CustomTagLib {
        CodecLookup codecLookup

        def myTag = { Map attrs, body ->
            out << codecLookup.lookupEncoder('HTML').encode(attrs.something)
        }
    }
#### Standard Codecs HTMLCodec This codec performs HTML escaping and unescaping, so that values can be rendered safely in an HTML page without creating any HTML tags or damaging the page layout. For example, given a value "Don’t you know that 2 > 1?" you wouldn’t be able to show this safely within an HTML page because the > will look like it closes a tag, which is especially bad if you render this data within an attribute, such as the value attribute of an input field. Example of usage:
    <input name="comment.message" value="${comment.message.encodeAsHTML()}"/>
| Note that the HTML encoding does not re-encode apostrophe/single quote so you must use double quotes on attribute values to avoid text with apostrophes affecting your page.
HTMLCodec defaults to HTML4 style escaping (legacy HTMLCodec implementation in Grails versions before 2.3.0) which escapes non-ascii characters. You can use plain XML escaping instead of HTML4 escaping by setting this config property in `application.groovy`:
    grails.views.gsp.htmlcodec = 'xml'
XMLCodec This codec performs XML escaping and unescaping. It escapes & , < , > , " , ' , \\\\ , @ , ` , non breaking space (\\\\u00a0), line separator (\\\\u2028) and paragraph separator (\\\\u2029). HTMLJSCodec This codec performs HTML and JS encoding. It is used for preventing some DOM-XSS vulnerabilities. See OWASP - DOM based XSS Prevention Cheat Sheet for guidelines of preventing DOM based XSS attacks. URLCodec URL encoding is required when creating URLs in links or form actions, or any time data is used to create a URL. It prevents illegal characters from getting into the URL and changing its meaning, for example "Apple & Blackberry" is not going to work well as a parameter in a GET request as the ampersand will break parameter parsing. Example of usage:
    <a href="/mycontroller/find?searchKey=${lastSearch.encodeAsURL()}">
    Repeat last search
    </a>
Base64Codec Performs Base64 encode/decode functions. Example of usage:
    Your registration code is: ${user.registrationCode.encodeAsBase64()}
JavaScriptCodec Escapes Strings so they can be used as valid JavaScript strings. For example:
    Element.update('${elementId}',
        '${render(template: "/common/message").encodeAsJavaScript()}')
HexCodec Encodes byte arrays or lists of integers to lowercase hexadecimal strings, and can decode hexadecimal strings into byte arrays. For example:
    Selected colour: #${[255,127,255].encodeAsHex()}
MD5Codec Uses the MD5 algorithm to digest byte arrays or lists of integers, or the bytes of a string (in default system encoding), as a lowercase hexadecimal string. Example of usage:
    Your API Key: ${user.uniqueID.encodeAsMD5()}
MD5BytesCodec Uses the MD5 algorithm to digest byte arrays or lists of integers, or the bytes of a string (in default system encoding), as a byte array. Example of usage:
    byte[] passwordHash = params.password.encodeAsMD5Bytes()
SHA1Codec Uses the SHA1 algorithm to digest byte arrays or lists of integers, or the bytes of a string (in default system encoding), as a lowercase hexadecimal string. Example of usage:
    Your API Key: ${user.uniqueID.encodeAsSHA1()}
SHA1BytesCodec Uses the SHA1 algorithm to digest byte arrays or lists of integers, or the bytes of a string (in default system encoding), as a byte array. Example of usage:
    byte[] passwordHash = params.password.encodeAsSHA1Bytes()
SHA256Codec Uses the SHA256 algorithm to digest byte arrays or lists of integers, or the bytes of a string (in default system encoding), as a lowercase hexadecimal string. Example of usage:
    Your API Key: ${user.uniqueID.encodeAsSHA256()}
SHA256BytesCodec Uses the SHA256 algorithm to digest byte arrays or lists of integers, or the bytes of a string (in default system encoding), as a byte array. Example of usage:
    byte[] passwordHash = params.password.encodeAsSHA256Bytes()
#### Custom Codecs Applications may define their own codecs and Grails will load them along with the standard codecs. A custom codec class must be defined in the `grails-app/utils/` directory and the class name must end with `Codec`. The codec may contain a `static` `encode` closure, a `static` `decode` closure or both. The closure must accept a single argument which will be the object that the dynamic method was invoked on. For Example:
    class PigLatinCodec {
      static encode = { str ->
        // convert the string to pig latin and return the result
      }
    }
With the above codec in place an application could do something like this:
    ${lastName.encodeAsPigLatin()}
## 17.4 Authentication Grails has no default mechanism for authentication as it is possible to implement authentication in many different ways. It is however, easy to implement a simple authentication mechanism using interceptors. This is sufficient for simple use cases but it’s highly preferable to use an established security framework, for example by using the Spring Security or the Shiro plugin. Interceptors let you apply authentication across all controllers or across a URI space. For example you can create a new set of filters in a class called `grails-app/controllers/SecurityInterceptor.groovy` by running:
    grails create-interceptor security
and implement your interception logic there:
    class SecurityInterceptor {

        SecurityInterceptor() {
            matchAll()
            .except(controller:'user', action:'login')
        }

        boolean before() {
            if (!session.user && actionName != "login") {
                redirect(controller: "user", action: "login")
                return false
            }
            return true
        }

    }
Here the interceptor intercepts execution before all actions except `login` are executed, and if there is no user in the session then redirect to the `login` action. The `login` action itself is simple too:
    def login() {
        if (request.get) {
            return // render the login view
        }

        def u = User.findByLogin(params.login)
        if (u) {
            if (u.password == params.password) {
                session.user = u
                redirect(action: "home")
            }
            else {
                render(view: "login", model: [message: "Password incorrect"])
            }
        }
        else {
            render(view: "login", model: [message: "User not found"])
        }
    }
## 17.5 Security Plugins If you need more advanced functionality beyond simple authentication such as authorization, roles etc. then you should consider using the spring security core plugin. ## 17.5.1 Spring Security The Spring Security plugins are built on the Spring Security project which provides a flexible, extensible framework for building all sorts of authentication and authorization schemes. The plugins are modular so you can install just the functionality that you need for your application. The Spring Security plugins are the official security plugins for Grails and are actively maintained and supported. There is a Spring Security Core plugin which supports form-based authentication, encrypted/salted passwords, HTTP Basic authentication, etc. and secondary dependent plugins provide alternate functionality such as ACL support, single sign-on with Jasig CAS, LDAP authentication, Kerberos authentication, and a plugin providing user interface extensions and security workflows. See the Spring Security Core plugin page for basic information and user guide for detailed information. | Quick Reference (hide)