Allowing users to enter the HTML of your site imposes security risks that you need to address.
This article demonstrates how a hypothetical attack proceeds and what to do to prevent it.
The following steps demonstrate the way a typical XSS attack proceeds.
A malicious user visits a page that uses the Editor widget. Let us assume that there is a
<textarea id="editor">element on the page.
The attacker sets the Editor value of the
<textarea>to a malicious script without using the editing interface and then submits the form.
$("#editor").val("<script>alert('Script that gathers user info and posts it to another site');</script>"); $("form").submit();
The unprocessed content is stored on the server.
- A victim visits the compromised page that outputs the above HTML.
The Editor itself can do little to protect you from XSS attacks because malicious users can manually edit form fields and post forged requests to the server, as shown in Step 2. To protect your users from these attacks, clean the posted content on the server through an HTML parsing and a whitelist of allowed tags.
By design, the Editor does not allow the execution of scripts inside its content area. This is achieved by transforming all
script tags in the content to
When the Editor content is submitted, the
k:script tags are either completely removed, or transformed back to
script tags. This depends on the
To allow the execution of scripts inside the Editor content:
- Enable the script serialization.
- Obtain the value of the Editor through its
- Extract the
- Place the
scripttags elsewhere on the page where they can be evaluated by the browser.
The following list provides information on the libraries that allow processing HTML with a whitelist depending on your server-side platform:
Other articles on the Kendo UI Editor:
- Overview of the Editor Widget
- Image Browser
- Post-Process Content
- Set Selections
For how-to examples on the Kendo UI Editor widget, browse its How To documentation folder.