DirectoryBurst – XSS and caching.

First a word about disclosure and vendor response.  I sent a couple of emails to DirectoryBurst about the problems in this post.  Though I never heard back from them, I observed that they fixed the XSS problem described below.  I describe the other less serious ones here too, in part so that users who see this can be aware and take steps to protect their information.

DirectoryBurst is an online school directory service.  It stores lots of personal information including full name, address, phone numbers, and parent email addresses.  I took a look at the site and saw a few problems.

The first one, now fixed, is that they were storing unvalidated user input for later display on their website.  Entering a directory name (to a demo admin account) that included the string “<script>alert(document.cookie);</script>” caused the following window to pop up each time this directory was viewed.  I’ve redacted the cookie values but kept the cookie names in the screen shot.

Screen Shot 2014-11-25 at 8.59.48 PM

This means that the script included in the directory name was executed in the browser when the page was viewed.  Popping the cookies up in an alert window is innocuous but a different script could forward these cookies to an attacker’s server, which could pose a real risk.  The defense against this attack is to inspect all user input and convert any code or scripts to printable, not executable formats.  For instance, the script text above was converted as follows for display on this blog post. (I’ve highlighted the converted characters).

&lt;script&gt;alert(document.cookie);&lt;/script&gt

Notice that there are two JSESSIONID cookies on the list of cookies?  Those are session IDs that could be used in a “session hijack” attack to take control of the user’s account.   The reason the script could read them is that the httpOnly flags were not set to protect them from this sort of attack.  I describe this problem in more detail in my post on session cookies.

Screen Shot 2014-11-25 at 9.08.03 PM

Another thing an attacker could do with this vulnerability is include malicious HTML in the page sent to users who load the directory.  As an illustrative example, entering a directory name including the HTML for a link to sfgate.com results in this HTML being served to the user.

Screen Shot 2014-11-25 at 9.16.09 PM

Which looks like this on the page – the text ‘click’ is a live link.  An attacker could set such a link to point to a malicious site or otherwise change the content of the page.

Screen Shot 2014-11-25 at 9.31.24 PM

Finally, DirectoryBurst is not preventing directory information from being stored in the browser’s disk cache. This means that someone can view them in a browser even if the browser has been closed and restarted. It also means that someone can hit the ‘back’ or ‘history’ buttons and view the directory details loaded by a user even after a user has logged out of the site.   (The fix is to include the “Cache-control: no-cache, no-store, must-revalidate” directives in response headers to prevent disk caching of sensitive data).  If your school uses DirectoryBurst, you should be careful about accessing it from a shared computer, and should clear the browser’s history and cache if you do use it on a shared computer.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s