Grails - Security Encoding By Default

De openkb
Aller à : Navigation, rechercher

Sommaire

Questions

http://grails.org/doc/latest/guide/security.html http://grails.org/doc/latest/guide/security.html

I also saw that there is an encodeAsHTML method that I can call to encode on the way back down to the client. Wouldn t I want to do this before it went into the database so that I only have to encode once? Thanks!

Answers

User Input

The idea of "sanitizing your inputs" (or pre-encoding or pre-escaping) your content is a terrible one. It does not actually protect you when you really need it, and leads to all sorts of design headaches. Even PHP finally dumped the technique.

It s always better to handle the data via proper APIs correctly, which eliminates the risk. For example, SQL injections is absolutely eliminated using prepared statements or statements with placeholders for the content. This technique has been around for a very long time (as long as I ve using Java & SQL).

Grails (GORM) automatically handles encoding any content that is saved via the objects, including setting a single property, creating a new object and saving it, or setting properties via obj.properties = params or something similar.

As long as you are using GORM, there is no risk of SQL injection.

Content Storage

Also, it s generally considered incorrect to store the already-encoded information in the database, as that encoding would only be correct for a given display type (such as HTML). If you instead wanted to render it using JSON, the HTML encoding is incorrect. XML is also slightly different, and there are times when you might prefer plain text, too.

http://grails.org/plugin/cache http://grails.org/plugin/cache

http://en.wikipedia.org/wiki/Cross-site_scripting http://en.wikipedia.org/wiki/Cross-site_scripting

http://grails.org/doc/latest/guide/conf.html#builtInOptions http://grails.org/doc/latest/guide/conf.html#builtInOptions

grails.views.default.codec =  html 

This will only affect GSPs, and only content echoed using dollar-sign syntax (${foo}). This gives you the flexibility of overriding this behavior using tags (the recommended way) or the <%= %> syntax for one-off situations. It should, however, provide a decent catch to prevent XSS attacks in general.

Performance Considerations

One final note: the concern about encoding the content as HTML being a performance issue would be considered premature optimization . Chances are extremely high that any performance bottlenecks would be somewhere else, and not in the encoding of the content. Build your application first — using a good design — and optimize later after you can benchmark and analyze the running application.

Source

License : cc by-sa 3.0

http://stackoverflow.com/questions/11486894/grails-security-encoding-by-default

Related

Outils personnels
Espaces de noms

Variantes
Actions
Navigation
Outils