Interface Encoder
-
- All Known Implementing Classes:
DefaultEncoder
public interface Encoder
TheEncoder
interface contains a number of methods for decoding input and encoding output so that it will be safe for a variety of interpreters. Its primary use is to provide output encoding to prevent XSS.To prevent double-encoding, callers should make sure input does not already contain encoded characters by calling one of the
canonicalize()
methods. Validator implementations should callcanonicalize()
on user input before validating to prevent encoded attacks.All of the methods must use an "allow list" or "positive" security model rather than a "deny list" or "negative" security model. For the encoding methods, this means that all characters should be encoded, except for a specific list of "immune" characters that are known to be safe.
The
Encoder
performs two key functions, encoding (also referred to as "escaping" in this Javadoc) and decoding. These functions rely on a set of codecs that can be found in theorg.owasp.esapi.codecs
package. These include:- CSS Escaping
- HTMLEntity Encoding
- JavaScript Escaping
- MySQL Database Escaping
- Oracle Database Escaping
- Percent Encoding (aka URL Encoding)
- Unix Shell Escaping
- VBScript Escaping
- Windows Cmd Escaping
- LDAP Escaping
- XML and XML Attribute Encoding
- XPath Escaping
- Base64 Encoding
The primary use of ESAPI
Encoder
is to prevent XSS vulnerabilities by providing output encoding using the various "encodeForXYZ()" methods, where XYZ is one of CSS, HTML, HTMLAttribute, JavaScript, or URL. When using the ESAPI output encoders, it is important that you use the one for the appropriate context where the output will be rendered. For example, it the output appears in an JavaScript context, you should useencodeForJavaScript
(note this includes all of the DOM JavaScript event handler attributes such as 'onfocus', 'onclick', 'onload', etc.). If the output would be rendered in an HTML attribute context (with the exception of the aforementioned 'onevent' type event handler attributes), you would useencodeForHTMLAttribute
. If you are encoding anywhere a URL is expected (e.g., a 'href' attribute for for <a> or a 'src' attribute on a <img> tag, etc.), then you should use useencodeForURL
. If encoding CSS, then useencodeForCSS
. Etc. This is because there are different escaping requirements for these different contexts. Developers who are new to ESAPI or to defending against XSS vulnerabilities are highly encouraged to first read the OWASP Cross-Site Scripting Prevention Cheat Sheet.Note that in addition to these encoder methods, ESAPI also provides a JSP Tag Library (
META-INF/esapi.tld
) in the ESAPI jar. This allows one to use the more convenient JSP tags in JSPs. These JSP tags are simply wrappers for the various these "encodeForXXYZ()" method docmented in thisEncoder
interface.Some important final words:
- Where to output encode for HTML rendering:
Knowing where to place the output encoding in your code
is just as important as knowing which context (HTML, HTML attribute, CSS,
JavaScript, or URL) to use for the output encoding and surprisingly the two
are often related. In general, output encoding should be done just prior to the
output being rendered (that is, as close to the 'sink' as possible) because that
is what determines what the appropriate context is for the output encoding.
In fact, doing output encoding on untrusted data that is stored and to
be used later--whether stored in an HTTP session or in a database--is almost
always considered an anti-pattern. An example of this is one gathers and
stores some untrusted data item such as an email address from a user. A
developer thinks "let's output encode this and store the encoded data in
the database, thus making the untrusted data safe to use all the time, thus
saving all of us developers all the encoding troubles later on". On the surface,
that sounds like a reasonable approach. The problem is how to know what
output encoding to use, not only for now, but for all possible future
uses? It might be that the current application code base is only using it in
an HTML context that is displayed in an HTML report or shown in an HTML
context in the user's profile. But what if it is later used in a
mailto:
URL? Then instead of HTML encoding, it would need to have URL encoding. Similarly, what if there is a later switch made to use AJAX and the untrusted email address gets used in a JavaScript context? The complication is that even if you know with certainty today all the ways that an untrusted data item is used in your application, it is generally impossible to predict all the contexts that it may be used in the future, not only in your application, but in other applications that could access that data in the database. - Avoiding multiple nested contexts: A really tricky situation to get correct is when there are multiple nested encoding contexts. But far, the most common place this seems to come up is untrusted URLs used in JavaScript. How should you handle that? Well, the best way is to rewrite your code to avoid it! An example of this that is well worth reading may be found at ESAPI-DEV mailing list archives: URL encoding within JavaScript. Be sure to read the entire thread. The question itself is too nuanced to be answered in Javadoc, but now, hopefully you are at least aware of the potential pitfalls. There is little available research or examples on how to do output encoding when multiple mixed encodings are required, although one that you may find useful is Automated Detecting and Repair of Cross-SiteScripting Vulnerabilities through Unit Testing It at least discusses a few of the common errors involved in multiple mixed encoding contexts.
- A word about unit testing:
Unit testing this is hard. You may be satisfied with stopped after you have
tested against the ubiquitous XSS test case of
</script>alert(1)</script>
or similar simplistic XSS attack payloads and if that is properly encoded (or, you don't see an alert box popped in your browser), you consider it "problem fixed", and consider the unit testing sufficient. Unfortunately, that minimalist testing may not always detect places where you used the wrong output encoder. You need to do better. Fortunately, the aforementioned link, Automated Detecting and Repair of Cross-SiteScripting Vulnerabilities through Unit Testing provides some insight on this. You may also wish to look at the ESAPI Encoder JUnittest cases for ideas. If you are really ambitious, an excellent resource for XSS attack patterns is BeEF - The Browser Exploitation Framework Project.
- Since:
- June 1, 2007
- Author:
- Jeff Williams (jeff.williams .at. owasp.org)
- See Also:
- OWASP Cross-Site Scripting Prevention Cheat Sheet, OWASP Proactive Controls: C4: Encode and Escape Data, Properly encoding and escaping for the web
-
-
Method Summary
All Methods Instance Methods Abstract Methods Modifier and Type Method Description java.lang.String
canonicalize(java.lang.String input)
This method is equivalent to callingEncoder.canonicalize(input, restrictMultiple, restrictMixed);
.java.lang.String
canonicalize(java.lang.String input, boolean strict)
This method is the equivalent to callingEncoder.canonicalize(input, strict, strict);
.java.lang.String
canonicalize(java.lang.String input, boolean restrictMultiple, boolean restrictMixed)
Canonicalization is simply the operation of reducing a possibly encoded string down to its simplest form.java.lang.String
decodeForHTML(java.lang.String input)
Decodes HTML entities.byte[]
decodeFromBase64(java.lang.String input)
Decode data encoded with BASE-64 encoding.java.lang.String
decodeFromURL(java.lang.String input)
Decode from URL.java.lang.String
encodeForBase64(byte[] input, boolean wrap)
Encode for Base64.java.lang.String
encodeForCSS(java.lang.String untrustedData)
Encode data for use in Cascading Style Sheets (CSS) content.java.lang.String
encodeForDN(java.lang.String input)
Encode data for use in an LDAP distinguished name.java.lang.String
encodeForHTML(java.lang.String untrustedData)
Encode data for use in HTML using HTML entity encodingjava.lang.String
encodeForHTMLAttribute(java.lang.String untrustedData)
Encode data for use in HTML attributes.java.lang.String
encodeForJavaScript(java.lang.String untrustedData)
Encode data for insertion inside a data value or function argument in JavaScript.java.lang.String
encodeForLDAP(java.lang.String input)
Encode data for use in LDAP queries.java.lang.String
encodeForLDAP(java.lang.String input, boolean encodeWildcards)
Encode data for use in LDAP queries.java.lang.String
encodeForOS(Codec codec, java.lang.String input)
Encode for an operating system command shell according to the selected codec (appropriate codecs include the WindowsCodec and UnixCodec).java.lang.String
encodeForSQL(Codec codec, java.lang.String input)
Encode input for use in a SQL query, according to the selected codec (appropriate codecs include the MySQLCodec and OracleCodec).java.lang.String
encodeForURL(java.lang.String input)
Encode for use in a URL.java.lang.String
encodeForVBScript(java.lang.String untrustedData)
Encode data for insertion inside a data value in a Visual Basic script.java.lang.String
encodeForXML(java.lang.String input)
Encode data for use in an XML element.java.lang.String
encodeForXMLAttribute(java.lang.String input)
Encode data for use in an XML attribute.java.lang.String
encodeForXPath(java.lang.String input)
Encode data for use in an XPath query.java.lang.String
getCanonicalizedURI(java.net.URI dirtyUri)
Get a version of the input URI that will be safe to run regex and other validations against.
-
-
-
Method Detail
-
canonicalize
java.lang.String canonicalize(java.lang.String input)
This method is equivalent to callingEncoder.canonicalize(input, restrictMultiple, restrictMixed);
. The default values for restrictMultiple and restrictMixed come fromESAPI.properties
Encoder.AllowMultipleEncoding=false Encoder.AllowMixedEncoding=false
- Parameters:
input
- the text to canonicalize- Returns:
- a String containing the canonicalized text
- See Also:
canonicalize(String, boolean, boolean)
, W3C specifications
-
canonicalize
java.lang.String canonicalize(java.lang.String input, boolean strict)
This method is the equivalent to callingEncoder.canonicalize(input, strict, strict);
.- Parameters:
input
- the text to canonicalizestrict
- true if checking for multiple and mixed encoding is desired, false otherwise- Returns:
- a String containing the canonicalized text
- See Also:
canonicalize(String, boolean, boolean)
, W3C specifications
-
canonicalize
java.lang.String canonicalize(java.lang.String input, boolean restrictMultiple, boolean restrictMixed)
Canonicalization is simply the operation of reducing a possibly encoded string down to its simplest form. This is important, because attackers frequently use encoding to change their input in a way that will bypass validation filters, but still be interpreted properly by the target of the attack. Note that data encoded more than once is not something that a normal user would generate and should be regarded as an attack.Everyone says you shouldn't do validation without canonicalizing the data first. This is easier said than done. The canonicalize method can be used to simplify just about any input down to its most basic form. Note that canonicalize doesn't handle Unicode issues, it focuses on higher level encoding and escaping schemes. In addition to simple decoding, canonicalize also handles:
- Perverse but legal variants of escaping schemes
- Multiple escaping (%2526 or <)
- Mixed escaping (%26lt;)
- Nested escaping (%%316 or &%6ct;)
- All combinations of multiple, mixed, and nested encoding/escaping (%253c or ┦gt;)
Using canonicalize is simple. The default is just...
String clean = ESAPI.encoder().canonicalize( request.getParameter("input"));
You need to decode untrusted data so that it's safe for ANY downstream interpreter or decoder. For example, if your data goes into a Windows command shell, then into a database, and then to a browser, you're going to need to decode for all of those systems. You can build a custom encoder to canonicalize for your application like this...ArrayList list = new ArrayList(); list.add( new WindowsCodec() ); list.add( new MySQLCodec() ); list.add( new PercentCodec() ); Encoder encoder = new DefaultEncoder( list ); String clean = encoder.canonicalize( request.getParameter( "input" ));
In ESAPI, the Validator uses the canonicalize method before it does validation. So all you need to do is to validate as normal and you'll be protected against a host of encoded attacks.String input = request.getParameter( "name" ); String name = ESAPI.validator().isValidInput( "test", input, "FirstName", 20, false);
However, the default canonicalize() method only decodes HTMLEntity, percent (URL) encoding, and JavaScript encoding. If you'd like to use a custom canonicalizer with your validator, that's pretty easy too.... setup custom encoder as above Validator validator = new DefaultValidator( encoder ); String input = request.getParameter( "name" ); String name = validator.isValidInput( "test", input, "name", 20, false);
Although ESAPI is able to canonicalize multiple, mixed, or nested encoding, it's safer to not accept this stuff in the first place. In ESAPI, the default is "strict" mode that throws an IntrusionException if it receives anything not single-encoded with a single scheme. This is configurable inESAPI.properties
using the properties:Encoder.AllowMultipleEncoding=false Encoder.AllowMixedEncoding=false
This method allows you to override the default behavior by directly specifying whether to restrict multiple or mixed encoding. Even if you disable restrictions, you'll still get warning messages in the log about each multiple encoding and mixed encoding received.// disabling strict mode to allow mixed encoding String url = ESAPI.encoder().canonicalize( request.getParameter("url"), false, false);
WARNING!!! Please note that this method is incompatible with URLs and if there exist any HTML Entities that correspond with parameter values in a URL such as "¶" in a URL like "https://foo.com/?bar=foo¶meter=wrong" you will get a mixed encoding validation exception.If you wish to canonicalize a URL/URI use the method
Encoder.getCanonicalizedURI(URI dirtyUri);
- Parameters:
input
- the text to canonicalizerestrictMultiple
- true if checking for multiple encoding is desired, false otherwiserestrictMixed
- true if checking for mixed encoding is desired, false otherwise- Returns:
- a String containing the canonicalized text
- See Also:
- W3C specifications,
getCanonicalizedURI(URI dirtyUri)
-
encodeForCSS
java.lang.String encodeForCSS(java.lang.String untrustedData)
Encode data for use in Cascading Style Sheets (CSS) content.- Parameters:
untrustedData
- the untrusted data to output encode for CSS- Returns:
- the untrusted data safely output encoded for use in a CSS
- See Also:
- CSS Syntax [w3.org]
-
encodeForHTML
java.lang.String encodeForHTML(java.lang.String untrustedData)
Encode data for use in HTML using HTML entity encodingNote that the following characters: 00-08, 0B-0C, 0E-1F, and 7F-9F
cannot be used in HTML.
- Parameters:
untrustedData
- the untrusted data to output encode for HTML- Returns:
- the untrusted data safely output encoded for use in a HTML
- See Also:
- HTML Encodings [wikipedia.org], SGML Specification [w3.org], XML Specification [w3.org]
-
decodeForHTML
java.lang.String decodeForHTML(java.lang.String input)
Decodes HTML entities.- Parameters:
input
- theString
to decode- Returns:
- the newly decoded
String
-
encodeForHTMLAttribute
java.lang.String encodeForHTMLAttribute(java.lang.String untrustedData)
Encode data for use in HTML attributes.- Parameters:
untrustedData
- the untrusted data to output encode for an HTML attribute- Returns:
- the untrusted data safely output encoded for use in a use as an HTML attribute
-
encodeForJavaScript
java.lang.String encodeForJavaScript(java.lang.String untrustedData)
Encode data for insertion inside a data value or function argument in JavaScript. Including user data directly inside a script is quite dangerous. Great care must be taken to prevent including user data directly into script code itself, as no amount of encoding will prevent attacks there. Please note there are some JavaScript functions that can never safely receive untrusted data as input – even if the user input is encoded. For example:<script> window.setInterval('<%= EVEN IF YOU ENCODE UNTRUSTED DATA YOU ARE XSSED HERE %>'); </script>
- Parameters:
untrustedData
- the untrusted data to output encode for JavaScript- Returns:
- the untrusted data safely output encoded for use in a use in JavaScript
-
encodeForVBScript
java.lang.String encodeForVBScript(java.lang.String untrustedData)
Encode data for insertion inside a data value in a Visual Basic script. Putting user data directly inside a script is quite dangerous. Great care must be taken to prevent putting user data directly into script code itself, as no amount of encoding will prevent attacks there. This method is not recommended as VBScript is only supported by Internet Explorer- Parameters:
untrustedData
- the untrusted data to output encode for VBScript- Returns:
- the untrusted data safely output encoded for use in a use in VBScript
-
encodeForSQL
java.lang.String encodeForSQL(Codec codec, java.lang.String input)
Encode input for use in a SQL query, according to the selected codec (appropriate codecs include the MySQLCodec and OracleCodec). This method is not recommended. The use of thePreparedStatement
interface is the preferred approach. However, if for some reason this is impossible, then this method is provided as a weaker alternative. The best approach is to make sure any single-quotes are double-quoted. Another possible approach is to use the {escape} syntax described in the JDBC specification in section 1.5.6. However, this syntax does not work with all drivers, and requires modification of all queries.- Parameters:
codec
- a Codec that declares which database 'input' is being encoded for (ie. MySQL, Oracle, etc.)input
- the text to encode for SQL- Returns:
- input encoded for use in SQL
- See Also:
- JDBC Specification, java.sql.PreparedStatement
-
encodeForOS
java.lang.String encodeForOS(Codec codec, java.lang.String input)
Encode for an operating system command shell according to the selected codec (appropriate codecs include the WindowsCodec and UnixCodec). Please note the following recommendations before choosing to use this method: 1) It is strongly recommended that applications avoid making direct OS system calls if possible as such calls are not portable, and they are potentially unsafe. Please use language provided features if at all possible, rather than native OS calls to implement the desired feature. 2) If an OS call cannot be avoided, then it is recommended that the program to be invoked be invoked directly (e.g., System.exec("nameofcommand" + "parameterstocommand");) as this avoids the use of the command shell. The "parameterstocommand" should of course be validated before passing them to the OS command. 3) If you must use this method, then we recommend validating all user supplied input passed to the command shell as well, in addition to using this method in order to make the command shell invocation safe. An example use of this method would be: System.exec("dir " + ESAPI.encodeForOS(WindowsCodec, "parameter(s)tocommandwithuserinput");- Parameters:
codec
- a Codec that declares which operating system 'input' is being encoded for (ie. Windows, Unix, etc.)input
- the text to encode for the command shell- Returns:
- input encoded for use in command shell
-
encodeForLDAP
java.lang.String encodeForLDAP(java.lang.String input)
Encode data for use in LDAP queries. Wildcard (*) characters will be encoded.- Parameters:
input
- the text to encode for LDAP- Returns:
- input encoded for use in LDAP
-
encodeForLDAP
java.lang.String encodeForLDAP(java.lang.String input, boolean encodeWildcards)
Encode data for use in LDAP queries. You have the option whether or not to encode wildcard (*) characters.- Parameters:
input
- the text to encode for LDAPencodeWildcards
- whether or not wildcard (*) characters will be encoded.- Returns:
- input encoded for use in LDAP
-
encodeForDN
java.lang.String encodeForDN(java.lang.String input)
Encode data for use in an LDAP distinguished name.- Parameters:
input
- the text to encode for an LDAP distinguished name- Returns:
- input encoded for use in an LDAP distinguished name
-
encodeForXPath
java.lang.String encodeForXPath(java.lang.String input)
Encode data for use in an XPath query. NB: The reference implementation encodes almost everything and may over-encode. The difficulty with XPath encoding is that XPath has no built in mechanism for escaping characters. It is possible to use XQuery in a parameterized way to prevent injection. For more information, refer to this article which specifies the following list of characters as the most dangerous: ^&"*';<>(). This paper suggests disallowing ' and " in queries.- Parameters:
input
- the text to encode for XPath- Returns:
- input encoded for use in XPath
- See Also:
- XPath Injection [ibm.com], Blind XPath Injection [packetstormsecurity.org]
-
encodeForXML
java.lang.String encodeForXML(java.lang.String input)
Encode data for use in an XML element. The implementation should follow the Character Encoding in Entities from W3C.The use of a real XML parser is strongly encouraged. However, in the hopefully rare case that you need to make sure that data is safe for inclusion in an XML document and cannot use a parser, this method provides a safe mechanism to do so.
- Parameters:
input
- the text to encode for XML- Returns:
- input encoded for use in XML
- See Also:
- Character Encoding in Entities
-
encodeForXMLAttribute
java.lang.String encodeForXMLAttribute(java.lang.String input)
Encode data for use in an XML attribute. The implementation should follow the Character Encoding in Entities from W3C.The use of a real XML parser is highly encouraged. However, in the hopefully rare case that you need to make sure that data is safe for inclusion in an XML document and cannot use a parse, this method provides a safe mechanism to do so.
- Parameters:
input
- the text to encode for use as an XML attribute- Returns:
- input encoded for use in an XML attribute
- See Also:
- Character Encoding in Entities
-
encodeForURL
java.lang.String encodeForURL(java.lang.String input) throws EncodingException
Encode for use in a URL. This method performs URL encoding on the entire string.- Parameters:
input
- the text to encode for use in a URL- Returns:
- input encoded for use in a URL
- Throws:
EncodingException
- if encoding fails- See Also:
- URL encoding
-
decodeFromURL
java.lang.String decodeFromURL(java.lang.String input) throws EncodingException
Decode from URL. Implementations should first canonicalize and detect any double-encoding. If this check passes, then the data is decoded using URL decoding.- Parameters:
input
- the text to decode from an encoded URL- Returns:
- the decoded URL value
- Throws:
EncodingException
- if decoding fails
-
encodeForBase64
java.lang.String encodeForBase64(byte[] input, boolean wrap)
Encode for Base64.- Parameters:
input
- the text to encode for Base64wrap
- the encoder will wrap lines every 64 characters of output- Returns:
- input encoded for Base64
-
decodeFromBase64
byte[] decodeFromBase64(java.lang.String input) throws java.io.IOException
Decode data encoded with BASE-64 encoding.- Parameters:
input
- the Base64 text to decode- Returns:
- input decoded from Base64
- Throws:
java.io.IOException
-
getCanonicalizedURI
java.lang.String getCanonicalizedURI(java.net.URI dirtyUri)
Get a version of the input URI that will be safe to run regex and other validations against. It is not recommended to persist this value as it will transform user input. This method will not test to see if the URI is RFC-3986 compliant.- Parameters:
dirtyUri
- the tainted URI- Returns:
- The canonicalized URI
-
-