How Silverstripe CMS can prevent cross site scripting attacks

Posted 3 years ago by Yuchen Liu

5 Minute(s) to read

Posted in

blog listing yl xattack

What is Cross Site Scripting (XSS)?

Cross Site Scripting (XSS) is one of the most common web application attacks. XSS attacks target scripts that run on client-side (user’s web browsers). It utilises the XSS vulnerabilities of Javascript and HTML script languages in a website to inject malicious content which can force a browser to run the code provided by attackers, change how a page is displayed and manipulate sending and receiving requests.

This vulnerability is often overlooked by developers because it requires a web user to visit a specific website page or copy and paste malicious content into their browser’s web CMS console. However, it poses a real danger if not taken seriously and left unpatched.

Two Types of XSS

XSS attacks can be divided into two types:

  • Non-Persistent (Reflected) XSS and

  • Persistent (Stored) XSS.

Non-Persistent XSS Attacks

Let’s first have a look at an example for Non-Persistent XSS, where a website has the following style URLs,

The parameter tag is used to filter blog posts under a blog page with tags of each article and the blog page then prints out the tag being searched in the front end above the search results. A malicious hacker can exploit the parameter ‘tag’ by appending malicious script.

<script type='text/javascript'>alert('xssattack');</script>

If the tag parameter is printed out without being converted to XSS safe html code, it will pop up as a dialogue saying “xssattack”, displays <script type='text/javascript'>alert('xssattack');</script> in tag area and the page URL reads:<script type='text/javascript'>alert('xssattack');</script>.

This suggests to the attackers that this website is XSS vulnerable, then what they can do is to create a link which reads:<script%20src="></script>

This link loads a malicious script when landing on the blog page and then the attackers can do what they want on the page and access sensitive data stored in a user’s browser like cookies. Attackers can put this link on related forums or in emails to be sent to their target audience.

Even though this link is suspicious and people are unlikely to click on it, it doesn’t mean there won’t be people clicking. Even if only 1 in each 1,000 viewers clicks the link, that can still compromise a dozen website users. This malicious code can steal account information and run or download malware on a computer.

How Silverstripe can prevent Non-Persistent XSS Attacks

So, how can users be protected from this type of XSS attack? Take Silverstripe CMS as an example: it converts all URL and parameters appended to html safe format. It converts all ‘<’, ‘>’ and special characters into ‘&#60;’, ‘&#62;’ as well as into other html character codes that won’t let a browser treat what a user has typed in as a script that could be run on client side. The conversion happens before the query is printed on the search result. At this point, the response has not even been returned to the client so there is no way to put malicious script on the filtered blog results page.

Persistent XSS Example

Persistent XSS (Stored XSS) vulnerabilities normally occur via social engineering because websites often allow users to share content, including blogs, comments, social networks, videos and message boards. Let’s click into a blog article page and scroll to the comments area.

An attacker can add a comment saying: Great deal for reduced PS4 in store. <script src=""> </script>. If the website prints out the comment at the bottom as it is, from this point, the malicious comment HTML tag will constantly exist on the page and load a JavaScript file on page landing which infects every user accessing this page. This script file is hosted on another server and has the ability to steal visitors' session cookies.

How Silverstripe can prevent Persistent XSS attack

To prevent this type of attack, the standard Silverstripe CMS comments module has two mechanisms. The first one is comment moderation, all comments posted by visitors have to be approved by the administrator to be displayed on blog articles at the frontend for the public. The administrator can screen out harmful texts with malicious or nasty intent. In addition, all comments are escaped before presenting in the frontend, so that scripts in comments are only treated as plain text and won’t be executed by the browser.

What if I can't even trust my editors?

Most frameworks provide websites the ability to create accounts with different permissions, like administrator for the owner of website and author for content editors. It’s quite normal to hire or just invite people from another organisation or department to edit the content of your websites. Sometimes these people may not work in your company or you are not familiar with them and worry they may insert some malicious script into the content purposely or accidentally.

This is not a worry with Silverstripe. The default SilverStripe configuration assumes some level of trust is given to your editors with access to the CMS. However, if you can't trust your editors, SilverStripe can be configured to filter the content so that any javascript is stripped out.

In some cases you may be particularly concerned about which HTML elements are addable to content by authors via CMS. Silverstripe can set restrictions to rule out dangerous tags (such as script tags, iframes, etc), so that your website can have high level security even if external content editors have access to the CMS.


XSS attacks are a real threat and Silverstripe offers your website good security and protection from them enabled by default. Silverstripe does not require you to do any configuration or make extra effort to learn how it works. If you do want to learn more about how Silverstripe works, please contact us: we love to share our insights.