XSS Exploits

March 3, 2005

I've gotten the question "Has Tabulas been exploited?" twice over the past week. So an entry on Tabulas security weaknesses and holes.

The short answer is that Tabulas has not been the target of any software exploits. There were a few issues during the first iteration of Tabulas where users coming from the same IP address would magically find themselves logged in as somebody else, but that problem seemed related to people coming from behind the same NAT [which at the time made no sense because Tabulas wasn't checking based on IPs - browser weirdness?] but was quickly resolved. I'm pretty vigilant against SQL injections and allowing any type of user input, so the standard methods of hijacking php scripts shouldn't occur in Tabulas.

Sal e-mailed me a few weeks ago bringing to my attention that Tabulas users were all vulnerable to a XSS exploit.

The Tabulas templating engine, being completely open-ended, allows users to input Javascript. In theory, someone could write Javascript that pretends that it's the input form of your control panel and send you to your control panel. The e-mail quoted from Sal: (My comments are bolded.)

Hi Roy,

Got bored tonight, thought I might have a bit of fun with my Tabulas account. Was thinking of ways I could play around with any logged in Tabulas user tame enough to view my site. Thought of a few good ones too, :/

Heres a couple of examples.

In simple forms, things like this put in templates could force a new friend

<iframe src="http://my.tabulas.com/friends.php?action=add& friendname=USERNAME" style="display: none"></iframe>

This is why your 'add a friends' feature now requires another step. This was also the tipping point in removing any control panel triggers through the GET method; everything is POST now.

...or you could helpfully post an entry for your Tabulas visitor

<div style="display: none"> <body onload="document.forms.forceEntry.submit()"> <form method="post" action="http://my.tabulas.com/post.php?action" name="entryForm" id="forceEntry"> <input type="hidden" name="title" value="I use Viagra" /> <textarea name="entryText"><a href="http://viagra.com/">Viagra</a></textarea> </form> </div>

BAD ROY! BAD!!!!!!

So the problem basically boils down to the problem of, "How do I verify that users are coming in through the control panel as opposed to maliciously-scripted JS?"

The solution was surprisingly simple; Tabulas now stores a table of data which I've simply called "Post Keys." Everytime you visit a page in the control panel, Tabulas stores [in the system, you'll never see these post keys] a randomly generated md5-hashed value [md5 wasn't entirely necessary, but I like having alphanumeric characters of consistent length]. Everytime there's a form input field, Tabulas creates a field: <input type="hidden" value="ce6351e1e14483ed2301d9edaf5d04b6 />. Tabulas then ensures that this post key value is the same one that was assigned. If not, it kicks you out to the login page (Which is why some of you get errors).

If you use multiple Tabulas browser windows when posting entries [which is a UI issue, but I just don't have the time to build an elegant solution for posting pictures to your entries, I usually open at least two windows when posting pictures and posting an entry at the same time], the problem comes up where the post key that was generated for your entry page is no longer value. Unfortunately I've basically had to assume that you wouldn't visit more than 10 pages between actions.. Tabulas stores the past 10 post key values and compares between all of them.

All pages of any import in your control panel now have the post key value, so Tabulas is [for now] safe from any XSS exploits coming from what Sal mentioned.

Much thanks to Sal for pointing this out.

Posted by roy on March 3, 2005 at 06:19 AM in Web Development, Tabulas | 5 Comments