Cross-site scripting"
Line 12: | Line 12: | ||
</source> | </source> | ||
− | However, there are still some notes worth | + | However, there are still some notes worth paying attention to. |
− | = Some Attributes are Not-Encoded | + | = Some Attributes are Not-Encoded = |
== The <code>content</code> Attribute of Html and Comboitem == | == The <code>content</code> Attribute of Html and Comboitem == | ||
Line 35: | Line 35: | ||
When displaying user input using methods such as <javadoc method="showBusy(java.lang.String)">org.zkoss.zk.ui.util.Clients</javadoc> or <javadoc method="showNotification(java.lang.String)">org.zkoss.zk.ui.util.Clients</javadoc> ... | When displaying user input using methods such as <javadoc method="showBusy(java.lang.String)">org.zkoss.zk.ui.util.Clients</javadoc> or <javadoc method="showNotification(java.lang.String)">org.zkoss.zk.ui.util.Clients</javadoc> ... | ||
and especially when dynamically concatenated JS code is executed using <javadoc method="evalJavaScript(java.lang.String)">org.zkoss.zk.ui.util.Clients</javadoc> user input should be escaped carefully. | and especially when dynamically concatenated JS code is executed using <javadoc method="evalJavaScript(java.lang.String)">org.zkoss.zk.ui.util.Clients</javadoc> user input should be escaped carefully. | ||
+ | |||
+ | == Client-side Actions == | ||
+ | The [[ZK Developer's Reference/UI Patterns/Actions and Effects|client-side action]] is not encoded and the options are interpreted as a JSON object. Thus, you could encode it by yourself, if you allow the end-user to specify it (which is generally not suggested at all). | ||
= Sanitize User Input = | = Sanitize User Input = | ||
[https://commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/apache/commons/lang/StringEscapeUtils.html Apache Commons Lang's StringEscapeUtils] can sanitize user input. | [https://commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/apache/commons/lang/StringEscapeUtils.html Apache Commons Lang's StringEscapeUtils] can sanitize user input. | ||
− | |||
− | |||
− | |||
− | |||
=Version History= | =Version History= |
Revision as of 06:18, 17 May 2022
Overview
Cross-site scripting (XSS) is a type of computer security vulnerability typically found in web applications that enables malicious attackers to inject client-side script into web pages viewed by other users. Because HTML documents have a flat, serial structure that mixes control statements, formatting, and the actual content, any non-validated user-supplied data included in the resulting page without proper HTML encoding may lead to markup injection.
All Input Components Block XSS
To prevent a XSS attack, ZK components encode any value that might be input by a user, such as the value of label and textbox, by escaping &
and other unsafe characters. For example, the following statement is totally safe no matter what the value of any_value
might be:
<textbox value="${any_value}"/>
However, there are still some notes worth paying attention to.
Some Attributes are Not-Encoded
The content
Attribute of Html and Comboitem
The content property of the html and combitem components (Html.setContent(String) and Comboitem.setContent(String)) are designed to allow applications to generate HTML content directly. In other words, it is not encoded. Thus, it is better not to carry the value input by an user, unless it is encoded property. For example, if the value of any_content
is, in the following example, generated directly and vulnerable to XSS attack if it is the value provided by an user and without proper encoding.
<html>${any_content}</html>
- Java API: Html.setContent(String) and Comboitem.setContent(String)
Some methods of Clients
As the name says this utility allows more direct client-side access. Thus the methods don't encode the strings passed into them to allow formatting of the messages at client-side, e.g.:
Clients.showNotification("Successfully processed: <br/>" + myTextbox.getValue());
When displaying user input using methods such as Clients.showBusy(String) or Clients.showNotification(String) ... and especially when dynamically concatenated JS code is executed using Clients.evalJavaScript(String) user input should be escaped carefully.
Client-side Actions
The client-side action is not encoded and the options are interpreted as a JSON object. Thus, you could encode it by yourself, if you allow the end-user to specify it (which is generally not suggested at all).
Sanitize User Input
Apache Commons Lang's StringEscapeUtils can sanitize user input.
Version History
Version | Date | Content |
---|---|---|