Examples of hirondelle.web4j.security.SafeText

• hirondelle.web4j.security.SafeText
  wasp.org/index.php/Cross_Site_Scripting'>Cross Site Scripting (XSS).

  Free-form text refers to text entered by the end user. It differs from other data in that its content is not tightly constrained. Examples of free-form text might include a user name, a description of something, a comment, and so on. If you model free-form text as a simple String, then when presenting that text in a web page, you must take special precautions against Cross Site Scripting attacks, by escaping special characters. When modeling such data as SafeText, however, such special steps are not needed, since the escaping is built directly into its {@link #toString} method.

  It is worth noting that there are two defects with JSTL' s handling of this problem :

  • the {@code } tag escapes only 5 of the 12 special characters identifiedby the Open Web App Security Project as being a concern.
  • used in a JSP, the Expression Language allows pleasingly concise presentation, but does not escape special characters in any way. Even when one is aware of this, it is easy to forget to take precautions against Cross Site Scripting attacks.

  Using SafeText will protect you from both of these defects. Since the correct escaping is built into {@link #toString}, you may freely use JSP Expression Language, without needing to do any escaping in the view. Note that if you use {@code } with SafeText (not recommeded), then you must use escapeXml='false' to avoid double-escaping of special characters.

  There are various ways of presenting text :

  • as HTML (most common) - use {@link #toString()} to escape a large number of special characters.
  • as XML - use {@link #getXmlSafe()} to escape 5 special characters.
  • as JavaScript Object Notation (JSON) - use {@link #getJsonSafe()} to escape a number of special characters
  • as plain text - use {@link #getRawString()} to do no escaping at all.

  Checking For Vulnerabilities Upon Startup

  WEB4J will perform checks for Cross-Site Scripting vulnerabilities upon startup, by scanning your application's classes for public Model Objects having public getXXX methods that return a String. It will log such occurrences to encourage you to investigate them further.

  Design Notes :
  This class is final, immutable, {@link Serializable}, and {@link Comparable}, in imitation of the other building block classes such as {@link String}, {@link Integer}, and so on.

  The reason why protection against Cross-Site Scripting is not implemented as a Servlet Filter is because a filter would have no means of distinguishing between safe and unsafe markup.

  One might object to escaping special characters in the Model, instead of in the View. However, from a practical point of view, it seems more likely that the programmer will remember to use SafeText once in the Model, than remember to do the escaping repeatedly in the View.

Related Classes of hirondelle.web4j.security.SafeText