Cross-site scripting"

From Documentation
(→‎Comboitem's content: ZK-5182: Prevent XSS issue in component attributes)
 
(18 intermediate revisions by 3 users not shown)
Line 3: Line 3:
 
= Overview =
 
= Overview =
  
[http://en.wikipedia.org/wiki/Cross-site_scripting 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.
+
[http://en.wikipedia.org/wiki/Cross-site_scripting Cross-site scripting] (XSS) is a type of computer security vulnerability typically found in web applications that enables malicious attackers to inject client-side scripts 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 =
+
= What ZK Encodes =
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 <code>&amp;</code> and other unsafe characters. For example, the following statement is totally safe no matter what the value of <code>any_value</code> might be:
+
== All Input Components Block XSS ==
 +
To prevent a XSS attack, ZK components encode any value that might be input by a user by escaping <code>&amp;</code> and other unsafe characters. For example, the following statement is totally safe even if <code>any_value</code> contains a script like <code><script>alert('xss')</script></code>:
  
 
<source lang="xml">
 
<source lang="xml">
Line 12: Line 13:
 
</source>
 
</source>
  
However, there are still some notes worth to pay attention to.
+
== Attributes to Generate Texts ==
 +
[[ZK%20Component%20Reference/Essential%20Components/Label | Label]] component's <code>value</code> and those attributes that generate texts into a page including <code>label, title, tooltiptext, placeholder, name, type</code>, and message like <code>createMessage, emptyMessage</code>. (ZK encodes them with <code>zUtl.encodeXML()</code> at client-side.)
  
= Some Attributes are Not-Encoded on Purpose =
+
Since ZK implicitly turns an EL expression like <code>${myMessage}</code> on a zul into a [[ZK%20Component%20Reference/Essential%20Components/Label | Label]], so it's encoded, too.
== The <code>content</code> Attribute of Html and Comboitem ==
 
  
The content property of the html and combitem components (<javadoc method="setContent(java.lang.String)">org.zkoss.zul.Html</javadoc> and <javadoc method="setContent(java.lang.String)">org.zkoss.zul.Comboitem</javadoc>) 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 <code>any_content</code> 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.
+
= What ZK Doesn't Encode =
 +
 
 +
== Components used to Generate HTML Directly==
 +
ZK provides several ways to write HTML tags in a zul, including  [[ZK_Developer%27s_Reference/UI_Patterns/HTML_Tags/The_html_Component | ZK <html> component]], [[ZK_Developer%27s_Reference/UI_Patterns/HTML_Tags/The_native_Namespace | native namespace]], and [[ZK_Developer%27s_Reference/UI_Patterns/HTML_Tags/The_XHTML_Component_Set | xhtml components]]. Since their purpose is to allow you to write HTML tags directly, ZK doesn't encode them.
 +
 
 +
==Comboitem's <code>content</code>==
 +
 
 +
The <javadoc>org.zkoss.zul.Comboitem</javadoc>'s <code>content</code> attribute is designed to allow applications to generate HTML content directly. In other words, it is not encoded. In most cases we expect these values to come from the server-side. However, if your application takes user input as the content property, you will need to encode it properly. For example, if the value of <code>any_content</code>, in the following example, is generated directly without proper encoding, it may be vulnerable to XSS attacks.
  
 
<source lang="xml">
 
<source lang="xml">
Line 23: Line 31:
 
</source>
 
</source>
  
* Java API: <javadoc method="setContent(java.lang.String)">org.zkoss.zul.Html</javadoc> and <javadoc method="setContent(java.lang.String)">org.zkoss.zul.Comboitem</javadoc>
+
{{versionSince | 10.0.0}}
 +
The content is sanitized by default to avoid XSS attack. Please don't use JavaScript in the content.
  
 
== Some methods of <code>Clients</code> ==
 
== Some methods of <code>Clients</code> ==
  
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.:
+
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 the client-side, e.g.:
  
 
<source lang="java">
 
<source lang="java">
Line 33: Line 42:
 
</source>
 
</source>
  
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><javadoc method="showNotification(java.lang.String)">org.zkoss.zk.ui.util.Clients</javadoc>, or anything similar; or when using <javadoc method="evalJavaScript(java.lang.String)">org.zkoss.zk.ui.util.Clients</javadoc> to dynamically concatenate JS code, 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. In most cases we expect the values to come from the server-side. However, if you allow end-users to specify them (not recommended), you should encode them by yourself.
  
 +
== Page Directive ==
 +
All attributes of [[ZUML_Reference/ZUML/Processing_Instructions/page| <?page?>]] are not encoded.
  
 
= 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.
+
As a framework, ZK tries to maintain a good balance between flexibility and default settings. Regarding attributes that are not escaped by default, application developers should use ZK <javadoc method="escapeXML(java.lang.String)">org.zkoss.xml.XMLs</javadoc> or [https://commons.apache.org/proper/commons-lang/javadocs/api-2.6/org/apache/commons/lang/StringEscapeUtils.html Apache Commons Lang's StringEscapeUtils] to sanitize user input if you are taking user input as these attributes.
 
 
= Client-side Actions =
 
 
 
The [[ZK Developer's Reference/UI Patterns/Actions and Effects|client-side action]] is not encoded and the options is 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).
 
  
=Version History=
 
{{LastUpdated}}
 
{| class='wikitable' | width="100%"
 
! Version !! Date !! Content
 
|-
 
| &nbsp;
 
| &nbsp;
 
| &nbsp;
 
|}
 
  
 
{{ZKDevelopersReferencePageFooter}}
 
{{ZKDevelopersReferencePageFooter}}

Latest revision as of 07:11, 16 February 2024


Cross-site scripting


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 scripts 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.

What ZK Encodes

All Input Components Block XSS

To prevent a XSS attack, ZK components encode any value that might be input by a user by escaping & and other unsafe characters. For example, the following statement is totally safe even if any_value contains a script like <script>alert('xss')</script>:

<textbox value="${any_value}"/>

Attributes to Generate Texts

Label component's value and those attributes that generate texts into a page including label, title, tooltiptext, placeholder, name, type, and message like createMessage, emptyMessage. (ZK encodes them with zUtl.encodeXML() at client-side.)

Since ZK implicitly turns an EL expression like ${myMessage} on a zul into a Label, so it's encoded, too.

What ZK Doesn't Encode

Components used to Generate HTML Directly

ZK provides several ways to write HTML tags in a zul, including ZK <html> component, native namespace, and xhtml components. Since their purpose is to allow you to write HTML tags directly, ZK doesn't encode them.

Comboitem's content

The Comboitem's content attribute is designed to allow applications to generate HTML content directly. In other words, it is not encoded. In most cases we expect these values to come from the server-side. However, if your application takes user input as the content property, you will need to encode it properly. For example, if the value of any_content, in the following example, is generated directly without proper encoding, it may be vulnerable to XSS attacks.

<html>${any_content}</html>

Since 10.0.0 The content is sanitized by default to avoid XSS attack. Please don't use JavaScript in the content.

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 the client-side, e.g.:

Clients.showNotification("Successfully processed: <br/>" + myTextbox.getValue());

When displaying user input using methods such as Clients.showBusy(String), Clients.showNotification(String), or anything similar; or when using Clients.evalJavaScript(String) to dynamically concatenate JS code, 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. In most cases we expect the values to come from the server-side. However, if you allow end-users to specify them (not recommended), you should encode them by yourself.

Page Directive

All attributes of <?page?> are not encoded.

Sanitize User Input

As a framework, ZK tries to maintain a good balance between flexibility and default settings. Regarding attributes that are not escaped by default, application developers should use ZK XMLs.escapeXML(String) or Apache Commons Lang's StringEscapeUtils to sanitize user input if you are taking user input as these attributes.



Last Update : 2024/02/16

Copyright © Potix Corporation. This article is licensed under GNU Free Documentation License.