How Yii framework saves you from Cross Site Scripting (XSS) attack
Let me brief you on CHtml and ChtmlPurifier :
Chtml: CHtml is a static class that provides a collection of helper methods for creating HTML views.
ChtmlPurifier: CHtmlPurifier is wrapper ofHTML Purifier.
CHtmlPurifier removes all malicious code (better known as XSS) with a thoroughly audited, secure yet permissive whitelist. It will also make sure the resulting code is standard-compliant.
Let us check how XSS attacks happening. I assume that you are ready with your new Yii web application. To start with, go to protected/controllers/ and create your controller file say XssController.php and put in the below code:
In normal case, the URL will be /xss/test?username=testuser. However, malicious users will be able to use it as below:
Keep in mind that instead of just alerting XSS, it is possible to steal page contents or even perform some website-specific things such as deleting all users’ data.
How to prevent XSS
Now let me explain you how Yii prevent XSS. Let us consider our above example, we need to escape the data before sending it onto the browser, see how we will write the code:
So the important thing is to always escape all dynamic data. For example, we should do the same for a link name:
echo CHtml::link(CHtml::encode($_GET[‘username’]), array());
Now your page is free from XSS. Let us think what if we want to allow some HTML to pass? In such cases it is not possible with CHtml::encode because it will render HTML as just a code and we need the actual representation. Here comes the richness of Yii, there is a built-in tool with Yii that allows filtering out the malicious HTML. It is nothing but, HTML Purifier and it can be used as following:
OR in a different way:
Now access the html action using the URL : /xss/html?html=Hello, <strong>username</strong>!<script>alert(‘XSS’)</script>and the output on the page will be:
How it works internally…
The CHtml::encode is as follows:
Basically we use the PHP’s internal htmlspecialchars function which is very much secure if one does not forget to pass the correct charset as the third argument.
As we discussed CHtmlPurifier uses the HTML Purifier library which is the most advanced solution out there to prevent XSS inside of HTML. We have used its default configuration which is OK for most of the user-entered content.
More about XSS and HTML purifier
There are two main types of XSS injections:
Non-persistent: Non-persistent type is the one that we have used in our example and is the most common XSS type that can be found in most insecure web applications. Data passed by the user or through a URL is not stored anywhere, so the injected script will be executed only once and only for the user who entered it. Still, it is not as secure as it looks.
Persistent: Persistent type is very serious as the data entered by a malicious user is stored in the database and is shown to many, if not all, website users. Using this type of XSS, one can literally destroy your website by “commanding” all users to delete all data to which they have access.
Configuring the HTML purifier
The HTML purifier can be configured as follows:
For a list of all possible keys which you can use in the options array, refer to the following URL: http://htmlpurifier.org/live/configdoc/plain.html
HTML purifier performance
Its performance is not so good! For the reason that HTML purifier performs a lot of processing and analysis. Therefore as a best practice not to process text every time you are outputting it. Instead, it can be saved in a separate database field or cached.
To learn more about XSS and how to deal with it, please go through the following resources: