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.

Session cookies

We all know that we need to protect our usernames and passwords.  Session cookies are nearly as valuable to a hacker.  I’ll explain why, and how an end user can check to see if session cookies are being protected properly by a web site.

When we log in to websites we give our usernames and passwords once, then the site “remembers” that we are logged in for the requests that come later, until we log out.   Session cookies are what makes this work.  On the initial login the server returns a “session ID” in a cookie, and this ID is associated with the current login session on the server side.  The browser stores this cookie and sends it with the transactions that follow.  The server recognizes it and uses it to allow access and to return the information associated with that account.

If an intruder gets the session ID he can install it in his browser and “impersonate” the user it belongs to.  Some sites defend against this but in many cases, when the server gets the hacker’s requests it will behave the same way as it would if the account owner had logged in to the site.  Our intruder now has full control of the account and can browse its pages at will.  This type of attack is called “session hijacking”.  To make matters worse, many sites don’t invalidate session cookies when a user logs out.  In that case logging out will not stop someone from accessing your account with a stolen cookie.

In May, 2013 I worked with Dana Liebelson on a story in Mother Jones about lack of SSL on popular team sharing sites.  As part of that we made a video demonstrating how a hacker could use a free software program called CookieCadger to automate the process of stealing session cookies and using them to access other users’ accounts. You can watch that here.  This problem was also covered for education-related web sites by Natasha Singer in NY Times in June of 2013.  Before CookieCadger, a browser extension called Firesheep first called widespread attention to the problem.

Now that we see why session cookies are important, how can an end user check to see how well they are protected by a web site?  The first thing is to know how to look at them. There are a number of browser extensions that allow users to examine cookies, such as EditThisCookie for Chrome.  Session IDs have different names on different sites but usually the name indicates it’s a session cookie – ‘sessid’, ‘phpsessid’, ‘sid’ are some examples.  Here are some other things you can look for.

  1. Check whether the site is using SSL/https the whole time you’re logged in.  The first step to protecting the session cookies is encrypting them as they travel between your browser and the website. A URL starting with ‘https’ is your sign that the site is using encryption.  Some sites will use https for the page that collects the username and password and then switch back to http. THIS IS NOT ENOUGH! If the site switches back to http it’s sending your session cookies back and forth without encryption, ready to be stolen by anyone who can monitor the network traffic.  (Such as an open wifi network).  If the site is not using https at all, this is even worse – your username and password are also being sent in a way that others can see it.
  2. Check to see if the session cookie’s flags are set correctly.  Cookies have security-related flags that can be set by the website.  The ‘secure’ flag prevents the cookie from being sent over an unencrypted connection. For a site that uses https, this protects against unintended transmission over http.  A common example of this is when a user enters the site’s name in a new tab while already logged in — browsers typically default to http, and if the secure flag is not set, cookies will be sent and exposed over http during the redirect from http to https.  The ‘httpOnly’ flag prevents the cookie from being read by a script embedded in the page. This protects against an attack called XSS or Cross-Site Scripting, that can read a session cookie and send it to an attacker.  There are occasions when a website’s implementation prevents setting these flags but you’re always safer if they are set (and most of the time it’s an oversight if they are not).  Here’s an example of a google session ID that has both flags set.                                                                                         Screen Shot 2014-11-25 at 3.50.17 PM
  3. Look for the session ID in the url.  A URL can be logged in a server log or browser history even if sent with encryption.  If the website puts your session ID in the URL, it gets stored with the URL.  From there it could be read and used by an attacker to gain access to your account.

More on TRUSTe – Serving Seals without SSL

SSL/HTTPS provides encryption, but the protocol also provides assurance that the website on the other end of the connection is who they say they are, and that the information they send has not been tampered with by someone in the middle.  In other words it means you can have much more TRUST in the information’s authenticity.

The screen shot below shows an example of what Chrome displays when you click the lock icon next to an HTTPS URL.  Identity Verified

Screen Shot 2014-11-20 at 12.10.49 AM

TRUSTe’s site that verifies the privacy seals allows HTTP connections without SSL.  If a page with the seal is an HTTP page, clicking the TRUSTe seal will take you to an HTTP lookup page. You can try it here.  TRUSTe’s page for looking up which sites have its seals is an http page.  You can see that here.

Here is a screen shot of what Chrome says about the identity of the TRUSTe page for looking up certified companies. Identity not verified

Screen Shot 2014-11-20 at 12.31.09 AM

So, TRUSTe is providing a privacy certification, but allows the certificate to be sent over a connection that does not verify their identity or protect against tampering with the information between their server and your browser.  How can a user trust that it’s authentic?

TRUSTe and data security

I wasn’t too surprised to see the recent news that TRUSTe had settled with FTC for failure to reevaluate sites yearly for compliance.

Over the past couple of years I’ve filed several complaints with TRUSTe against sites that were subject to COPPA but not using SSL to protect the transfer of children’s personal information and the usernames, passwords and session identifiers for the accounts.  I got some surprising responses.

TRUSTe’s children’s privacy program requirements state that web services in the program must:

Use reasonable encryption methods such as Secure Socket Layer for transmission and storage of information if the inappropriate use or disclosure of that information could cause financial, physical, or reputational harm to an Individual.

Let’s start with reputational harm.  If an intruder gets usernames and passwords, or session IDs, the intruder can impersonate students or teachers in the service’s forums.  It’s not hard to see how that could lead to reputational harm.  Many educational and kids sites hold information about a child’s address or school, and pictures of the child.  Physical access can lead to physical harm.  Enough said there

As you’ll see in the responses below, TRUSTe has a children’s privacy program that does not consider children’s personal information to be sensitive data worthy of encryption.  What?  They also say that they don’t require SSL for things like passwords that are commonly sent unencrypted in emails.  One bad practice does not excuse another.  It’s like saying there’s no point in putting a fence around a pool because people often forget to close the gate.

These are actual quotes from TRUSTe’s responses:

Here they state that children’s PII is not considered sensitive information under their Children’s Privacy Program.

“We require encryption in transit for information we consider sensitive
under our program. Examples would include social security number,
credit card information, and medical laboratory results.

We do not require encryption for information we do not consider
sensitive under our program, or for passwords in transit if they
control access to only information that is not sensitive.

Based on the categories of information the  site is
collecting, which do not qualify as sensitive under our program, we do
not have authority to require the change you reference regarding HTTPS
in transit.”

Here, they reason that SSL is not needed to protect info that might be sent unsecurely by other means, and  state again that encrypting children’s personal info or the things that control access to it are not a requirement of their program

 “we do not consider that we have authority under our program requirements to require the service to use encryption to encrypt web traffic in transit for categories of information that are commonly sent unencrypted via e-mail to the account holder, or for passwords/cookies etc. used to access only this category of information, even though we understand that a technology-capable eavesdropper sitting in a coffee shop who chooses to violate federal and potentially other laws could possibly intercept unencrypted information sent unencrypted such as over HTTP or e-mail.

Additionally, just because information contains personally identifiable
information pertaining to a child under 13 years old does not
necessasrily require HTTPS encryption in transit under TRUSTe‘s
program (or under COPPA).

Therefore, based on the categories of information the service is
collecting, we do not have authority to require the service to encrypt
in transit:

1) the login form; or
2) after login, session cookies and data which include
or control access to children’s personal infromation.”

Here, another response where they state that encryption is not required for personal information of kids under 13.

“COPPA does not require that the service have site-wide HTTPS encryption.TRUSTe‘s program requires encryption where disclosure “could cause financial, physical, or reputational harm to an individual.” TRUSTe‘s current program requirements do not require site-wide encryption simply because the information being exchanged includes information about children under 13. However,TRUSTe strongly encourages the use of site-wide encryption even in situations where the nature of the information does not rise to this level.”

Transparency and disclosure

I see lots of security problems with educational web sites and apps.

Sometimes problems like these get reported in the press.  For example in the past couple of years, Shutterfly, Schoology and Edmdodo have been in the press for not using SSL to protect user accounts and the information that they contain about kids.  Often, even if they are fixed, the companies don’t report that their users were exposed to security vulnerabilities.   This sort of thing is not as serious as an actual data breach, but parents and educators can’t make informed decisions without transparency and information about the security practices of the sites they are considering.  Many companies and sectors do make a practice of disclosing their security problems responsibly.  But this is not something I’ve seen in the ed-tech space.

Talking about things that are already fixed adds transparency and openness.  There are differing opinions about the best way to disclose security problems that have not yet been fixed.     This post by Troy Hunt lays out a good set of guidelines for when it makes sense to publicly disclose security problems.  He weighs the consequences to the site’s operators and users. It’s worth a read, and Troy’s blog, www.troyhunt.com is a great resource for those who’d like to learn more about security.

Why we need standards: Part one of many

The other day, I heard that some classes at our school were considering using an online service to share updates and photos about what happens at school during the day.   I took a look at the site and the first thing I noticed was that the site was not using SSL at all.  In fact, the site’s developers seemed to have spent more effort on protecting against disclosing parents’ email addresses to each other than to protecting against unauthorized access by outsiders.

Uh oh.  This means that the site transmits usernames and passwords, links to photos, comments, and personal information unencrypted – visible to anyone who is able to see the network traffic.   This also means the site is vulnerable to session hijacking, where an attacker can take full control of a victim’s account.  More on that in an upcoming post.

I sent a note to the company and got a quick (and a bit indignant) response from the CEO, saying that SSL was coming within days but had not been implemented yet because the site was not collecting any “highly sensitive” information such as credit cards or home addresses, and thus did not need SSL.

Really?  The site collects students’ first and last names, parent emails, and allows photos to be uploaded and shared.  Though COPPA does not apply here, I view the list of COPPA-protected personal information as one good yardstick for what sorts of student information requires secure handling, and all of these are on that list.

However, there is no real standard for data security in educational technology.  Laws such as COPPA and California’s SOPIPA require “reasonable” security, but do not define what “reasonable security” is.   The edtech industry has not come forward with a meaningful standard.   Without a standard, edtech implementors don’t have a clear target to aim for and educators and parents don’t have visibility in to the security practices of the companies that collect their children’s information.

In upcoming posts I’ll share thoughts on what the standards might look like and examples of why it’s important to have them.

More reading:

OWASP  (Open Web Application Security Project) has lots of information about securing web applications.  Here’s a link to their Transport Layer Security cheat-sheet, which includes the following about using SSL/TLS for login and authenticated pages.

Rule – Use TLS for All Login Pages and All Authenticated Pages
The login page and all subsequent authenticated pages must be exclusively accessed over TLS. The initial login page, referred to as the “login landing page”, must be served over TLS. Failure to utilize TLS for the login landing page allows an attacker to modify the login form action, causing the user’s credentials to be posted to an arbitrary location. Failure to utilize TLS for authenticated pages after the login enables an attacker to view the unencrypted session ID and compromise the user’s authenticated session.