One of the greatest challenges in building a web application is making sure it is secure. It's an important matter, as malicious attacks can come from various sources and in various forms.

I cannot stress enough the importance of building secure applications. In that respect, we take security very seriously, knowing that the Telerik UI for ASP.NET AJAX suite is integral for many web applications. We strive to provide controls that offer great performance and appropriate security.

One of the most common kind of malicious attack related to client content is a cross-site scripting (XSS) attack. Therefore, this sort of attack will be emphasized below.

Although much of the following content is valid in the most general cases, we will center our discussion around the RadEditor control, as it allows rich-text input from users and is easily regarded as a common target for XSS attacks.

What is XSS?

First, what is an XSS attack? It refers to a class of attacks where malicious client-side script is injected in the web application. Later, this piece of code is rendered and executed on the page that an unsuspecting user has opened. As a result, privacy information may be sent to a location known to the attacker, including personal information or even the authentication cookie resulting in Session theft.

XSS attacks are very common and, at the same time, very dangerous. Furthermore, SSL encryption does not protect from those attacks, which makes preventing them even more important.

XSS Counter-measures

The RadEditor control has some valuable built-in practices for preventing XSS attacks. Nevertheless, it is always the duty of the developer to implement the necessary content validation, specific to the domain of their application, to protect the integrity of the stored data.

RadEditor Built-in Counter-Measures

The XSS attack prevention mechanisms of the RadEditor control are based on content filtering. There are two filters specifically dedicated to the task of handling script tags and their content. Those are RemoveScripts and EncodeScripts.

The first filter, RemoveScripts, strips all script tag definitions from the content. It runs both on the client-side and the server-side, because client-side validation can be easily “tricked” and the server-side is the only area that can be fully trusted. Removing the scripts altogether makes sure that no script is executed from the Editor's content, thus no malicious activity can take place.

Nevertheless, there are many cases that need the RadEditor to persist the scripts, but prevent their execution while the content is being edited. For those cases, you should use the EncodeScripts filter that does not remove the scripts, but simply prevents their execution on the client-side.

CSS Expressions

CSS Expressions were introduced in Internet Explorer 5.5 with the idea to incorporate JavaScript code with CSS properties in an attempt to provide more flexibility. Here is an example:

          #container { width: expression((document.body.offsetWidth / 4 + 30) + "px"); }

Unfortunately, this flexibility comes at a price. By using this CSS property, an attacker could inject a piece of malicious script, which may result in a successful XSS attack. We’d like to thank G.S. McNamara from CGI Federal for his research into this attack vector.

RadEditor does not sanitize CSS expressions from the content out of the box at the moment. Secure input handling and sanitization has always been an industry best practice, and we want to make sure it is easier for developers to incorporate this extra security measure when it comes to using RadEditor in their apps. As a result, bearing in mind that CSS expressions are considered a bad practice, are not available in IE8+ versions of the Internet Explorer browser (unless in compatibility mode) and IE11 does not support them for the Internet zone, we see it fit to add an extra layer of built-in sanitizing that strips CSS expressions unconditionally from the Editor content as of Q3 2014. This way, you will get this feature out of the box and you will have one thing less to worry about when it comes to securing from XSS attacks.

As we said, developers should take care of sanitizing the content in their applications from possible threats. That’s why we have come up with a sample implementation for this particular case that can be found in our feedback portal.

Attribute DOM Events

There is another area where the boundaries of presentation and scripting are intertwined—DOM event attributes like onclick, onmouseover, onmousedown, etc. This approach to defining event handlers is very handy and requires minimum code. However it may pose a risk of XSS attacks as malicious script is injected in the attribute definition and later an unsuspecting user is "tricked" into the necessary interaction to trigger the event and the respective malicious code.

For the RadEditor control, we believe in providing enough flexibility when it comes to content management. In that respect, the Editor does not remove event attributes from the content, with the idea that they may be an important part of the intended result. Therefore, it is important for the developer to acknowledge this and if there is a need to strip these attributes, a custom filter approach could be used to change the content in the required way.

Securing your web application takes time and effort, but it is worth it. With well implemented security practices and input validation, you can guarantee fewer troubles for your applications. You can be sure that we are there to help you leverage that through our Telerik UI for ASP.NET AJAX suite.

Be safe and happy coding!

Related Posts


Comments are disabled in preview mode.