A Starting Point: A Web App Security Test Plan for End Users

In an earlier post I discussed why we need security standards for education-related web apps.  Today we really don’t have any. Student privacy legislation typically requires “reasonable” security.  (This is due in part to the fact that legislation moves at a slower pace than technology and today’s requirements might not outlast the legislative cycle.) Industry-driven student privacy standards also tend to speak of “reasonable” security with few specifics. TRUST-e’s definition of kids privacy does not require protection of students’ personal information and academic activity, just their credit cards and SSNs.  Nobody has really specified what reasonable security means.   In this post I’ll share a starting point, based on the OWASP Application Security Verification Standard (ASVS) and my own observations of web app security problems.

Securing web applications takes effort, and attack methods grow more sophisticated all the time.  But the blueprint for providing a baseline of strong security is well defined.  The OWASP ASVS spells out a comprehensive list of requirements for designing and verifying a secure web application and defines different levels of verification.  A security standard appropriate for apps collecting students’ personal information and academic activities should incorporate most of the requirements from the ASVS ‘Standard’ level of verification.   Many requirements for the Standard level of verification require access to the inner workings of a web service’s operations.    The test plan I’m presenting here focuses on the ‘Opportunistic’ level of verification that can be observed by end-users of the web application.   My outlook is that the rigor of the practices we *can* observe is an indicator of the practices we *can’t* observe as end users.  So by assessing the health of a service against the observable security practices we can create a yardstick to compare sites and make decisions about whether to use them.

To perform the tests in this plan, no special access is needed beyond an account with the service, and no special equipment is needed beyond a computer and some free software programs.   Every item on the test presents some level of security risk. Many of them are minor but as a whole they paint a picture that’s often more important than the individual weaknesses cataloged in the test.  Having said that, if every education-related web app met this test standard, it would be a big leap forward from where we are today.

It’s my hope that this test plan might be adopted by parents, administrators and teachers as a yardstick or minimum set of requirements for apps that collect our children’s and students’ information.   It’s embedded below for viewing and downloading.

Web-App-Security-Test-Form-Feb15 (downloadable PDF)

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.”