In this post I’ll be reviewing the security practices of Infosnap. Infosnap is a signatory of the Student Privacy Pledge.
UPDATED: June 7, 2015: Infosnap has made numerous improvements to the service’s security, as described below. Over the past few weeks I have had a very open and collaborative interaction with Infosnap to discuss the many improvements, and verify them from my side. Many thanks to everyone at Infosnap for making these changes and for enabling the open communications about them.
The changes are listed here and also updated inline. I have independently verified all of these.
• Changes were made to the user login process to provide identical responses to invalid username and password combinations. This was done to make it more difficult to test potential usernames for validity.
• Changes were made to the user login process to obfuscate the email address of the account holder. This was done to reduce the sensitive information displayed to the user.
• Changes were made to the session authentication token to set the “httpOnly” flag. This was done to prevent an XSS (Cross-Site Scripting) exploit from gaining access to a session cookie.
• Changes were made to the session authentication token to set the “secure” flag. This protects against accidental transmission of the session cookie across an unencrypted link.
• Changes were made to invalidate the session authentication token at logout. This was done to prevent the unauthorized reuse of a session cookie.
• Changes were made to examine headers for the X-Frame-Option. This was done to prevent frame sniffing attacks.
• Changes were made to reduce server details included in response headers. This was done to reduce the amount of internal system information provided.
• A change was made to the recommended procedure for utilizing Snapcodes. The standard procedure is to require both Snapcode and Date of Birth verification for authorization.
• Changes were made to the Snapcode authentication process to limit the number of times a user can provide an incorrect Date of Birth before the Snapcode is invalidated. This was done to make brute force attacks more difficult.
Notification and response
Update: In May 2015 Infosnap notified me of many security enhancements as described in the updates to this post.
I first reported these observations in this post to Infosnap in August, 2013. Infosnap responded that the issues could not be addressed at that time without causing significant impact and potential usability issues to its user base. I reported them again in August 2014 and received a similar response. The Student Privacy Pledge site does not show the dates that companies signed but the Wayback Machine’s Jan 20th snapshot shows that Infosnap had signed by then. In March 2015 I reconfirmed most of the observations outlined below. Since March Infosnap has made numerous security improvements as described in the updates to the post, and as captured in the updated Web App Security Test Plan results included at the end of the post.
Overview of the service
Infosnap is a school registration service. Schools pre-load some information and Infosnap emails an access code, called a “snapcode” to parents by email. Parents use this snapcode to access the student’s account by associating it with an Infosnap account, and complete the registration. An excerpt of an email sent to a parent is shown below.
The school preloads information including a student’s name, address, and date of birth, the student’s parents and their info from its records. When parents access the record they can update this information, add student medical information, and select directory sharing preferences . The screenshot below shows some of the personal information that is preloaded to the service.
The next screenshot shows the information about medical conditions that is collected by the service.
The first person to present a snapcode gets access to the records, with no double checks against email addresses known to the school
Update 6/7/15: This is mitigated by the changes to make birthdate verification the default, and to lock out a snapcode after 4 incorrect birthdates are presented by the user
When a snapcode is presented, the user logs in (if a returning user) or creates a new account, and the student record is associated with that account. The account usernames are email addresses, and there is no verification that the student record is being accessed by the owner of an email account known to the school for that student. This means that anyone who obtains a snapcode can access the student record if it is presented before a parent uses it to register the student. There is a feature that the school can configure to require the student’s birthday before gaining access, but I observed that it is not rate limited and can be quickly bypassed with a script or “fuzz tool” that automatically cycles through possible birthdates.
Snapcodes are sent in email and included in URLs
As shown above, snapcodes are sent to parents in emails. Handling of these codes is very similar to handling of passwords, as both can be used to gain access to information protected by the code or password. Sending passwords in emails is documented to be counter to best practices, and snapcodes should be treated with similar care. This is discussed in the OWASP Application Security FAQs, which states: “Emailing the actual password in clear text can be risky as an attacker can obtain it by sniffing. Also the mail containing the password might have a long life time and could be viewed by an attacker while it is lying in the mailbox of the user. Apart form the above threats, a malicious user can do shoulder-surfing to view the password or login credentials.”
The embedded link in the email contains the student’s snapcode in the URL. This is also against best practices because the URL may be logged in browser history, or server logs. This requirement is part of the OWASP Application Security Verification Standard and the text of the requirement is shown below.
Valid snapcodes can be used to extract student and parent information without logging in to an account
Update: 6/7/15: changes have been made to obfuscate the parent’s full email address on all interfaces
If a parent has already registered and “claimed” the snapcode, an attacker in possession of the snapcode could still extract considerable information by attempting to attach the snapcode to another existing account controlled by the attacker. This information includes the name of the school district (served in a banner at the top of the page), the child’s first name and birthdate, the parents email address, first name and last initial.
After entering the snapcode to the account, the service asks for the student’s DOB as an additional check (optional and controlled by the school). The dialog that asks for this includes the student’s first name.
If the birthday presented is incorrect, the user is prompted to try again. I observed there were no rate limits or attempt limits on this check. As described above, an attacker could use an automated tool to quickly bypass this check, and in the process discover the student’s birthdate.
Once past the birthdate check, the potential attacker would be presented with a page that reveals the parent’s first name and last initial. The email address is obscured but can be obtained in another way that I’ll show later.
If a valid snapcode is presented that has already been “claimed” and a potential attacker selects the option to create a new account, the parent’s full email address is revealed.
Consider that among other things, an attacker could construct a phishing attack using all of this information (school/district name and logo, student and parent first name, parent last initial, student birthdate, parent email address) to make the malicious email or web link look legitimate.
Authentication token and session handling
Update 6/7/15: The session cookie’s httpOnly and Secure flags are now set, and session cookies are invalidated when a user logs out.
Note: this is more technical than the above sections, but important. An attacker in possession of a user’s session cookies can potentially control the user’s account and view all the information it holds. Broken session management and authentication controls are #2 in the latest OWASP Top 10 list of web app vulnerabilities. Refer to my earlier post on Session Cookies for more information.
Several best practices are not followed with respect to protecting session authentication tokens, which are codes that give a user access to an account after presenting username and password. Problems include:
- Not invalidating a session authentication token when a user logs out
- This means that if an attacker obtains the token, the user does not revoke the access by logging out
- Not setting the ‘secure’ flag in session authentication token cookies or using strict transport security. These protect against accidental transmission of session authentication tokens over unencrypted links
- secure flag prevents the cookie from being sent over an unencrypted link.
- it’s not uncommon to see this flag not set due to requirements of load balancers in the infrastructure, but then strict-transport-security must be used, and it is not.
- strict-transport-security tells a browser to always connect to a site over an encrypted link even if the url is presented as http
- Not setting the httpOnly flag in the session authentication token cookies, which could allow them to be read by a malicious script and sent to an attacker.
The image below shows that the httpOnly and secure flag are not set on the FamilyPortalAuthentication cookie. This is the one that grants access to a user’s authenticated session.
Updated: Full end-user test plan results
Full results of end-user security testing, repeated in June 2015 to capture numerous recent security improvements, are in the embedded report. (The original results from March follow below this latest version.)
June 2015 results:
March 2015 results: