More than once, in the past months, I have found myself in the undesirable position of having to replace a credit card for fraud or having my bank send me a new card because their data was compromised. Their data included my personally identifiable information (PII). Considering this, and my online practices, I found it necessary to evaluate my behavior when going to a website. While I was sure I had nothing to do with a banks’ system being compromised, I had to ask if my behavior might have led to identity theft or fraud that was used against me and my account. In my review of this data I found that while I was not at fault I had not considered if sites were secure enough before using them. I found that I relied on simple information, the browser padlock, which was about as meaningful as a screen door lock, to determine if a site I was using was safe and secure. Considering this I have decided to make changes. But before I get into the changes let me describe the problem a bit more.
As an online culture it becomes important for us to protect our privacy related information from many sources of data leaks. The areas of concern are personally identifiable information, from here on out I will refer to this as PII. PII is information that can be used to identify you and perhaps your location in some way. A simple non exhaustive list would be; full name, ID or driver license number, passport number, vehicle registration, face, handwriting, credit card numbers, social security number, mother’s maiden name, mother’s middle name, age, gender, race, job position, employer, criminal record. In fact PII is any information that can be used to identify you.
You may want to review: the “Guide to Protecting the Confidentiality of Personally Identifiable Information (PII)”. By NIST.
Now, let’s return to the title of this article regarding the browser padlock and whether or not it is meaningless in the situations that I discussed above. I would have to answer that no it is not meaningless, but in fact is dangerous as it creates a false sense of security. The browser padlock makes us lax on where and how we enter information. This is especially true when you consider the willingness that we have to enter PII into web based applications in situations where we know nothing about the company, their security practices or the quality of the application. What are some of the things that companies should be doing to protect their consumers? Here is a list that web developers need to consider:
1. The company privacy policy/statement should be in the websites user interface and it should be in the design area of the global footer. While from an application perspective this may not be very important, from the perspective of ‘Do I have a warm and fuzzy regarding the website’ it is huge. If a website does not have this I recommend going away and fast. But please note that having a statement does not mean that your information is safe!
2. Forms are of course a main concern with PII and not just forms but form elements and any other sort of user input. To the user these items are also not always present and to the application developer not trained in security they are often overlooked. Here is a shortlist of some of the elements that matter:
- Input
- TextArea
- Select
- Buttons
- Datalist
- Keygen
By themselves, these items are not inherently bad, but it is how they are used that can be bad. Again they are not always visible to the site visitor and they may be stylized to appear like anything but a form. So there are some form rules that developers and site visitors need to be aware of. First, a form should not use the get method, as a developer you should not use this method as related to PII, Authentication, etc…it is not necessary. Remember HTTPS does not provide an acceptable level of PII protection to the visitor in this case (Logs, History, and so on). In addition to the obvious issues with having PII in the URL it is important to never trust the user input. We do this every day, when we set patterns for completing a phone number but for some reason many developers do not find it necessary to prevent malicious user input. When we use textareas, inputs or any way to enter or display data as developers we must validate the input and take the extra step if available of encoding your html and using other forms of validation. A take away here is that we need to evaluate all forms to see if they are developed and implemented in a secure manner.
3. Cookies, there are many types of cookies; session cookies, authentication cookies, third party cookies and so on. With regards to security and privacy a web site/application, to be safe, should use secure cookies for any cookie that exposes security or privacy information and they should also prevent mixed content. Even with this precaution there can still be dangers to PII and other user account information. A take away here is that we need to evaluate all cookies to see if they are developed and implemented in a secure manner.
4. Mixed Content is an issue for many reasons with the first being, what it means to the site visitor. Most site visitors have no idea what it means and to keep it simple here it means content that is received via https and http and in many cases a user has the choice of whether or not they want to display the same. One of the problems with this can again be the developer of the web application and/or a lack of a content security policy in the development team. From Cross Site Scripting (XSS) to “spear fishing” and a lot in-between, the impact of mixed content can be huge because again the lock provides a false sense of security. A take away here is a company needs to develop a content security policy.
You may notice at this point I have not provided any information on scanning or reviewing PII on pages yet and that may seem a bit odd, but I think by the end you will agree that it is not. The reason this is not odd is that there are a couple truths that need to be mentioned about your PII. First, if the site you are visiting does not use basic application security your PII is not safe on the site. Second, if it is obvious that the site you are visiting does not have a policy on content security then all the scanning in the world for data leaks is meaningless. When a company considers a Privacy Scanner, like the ConPraxis Privacy Server (http://34alabs.com/conpraxis.htm), to proactively check to see if their visitors data is safe they also need to look to security factors before random and near meaningless scans for a SSN number and more.
So what can a site visitor do along the same terms as the company who purchased a privacy scanner? The sad answer is “not much today”. This is because the items listed above require that the site visitor be able to identify the security issues listed above, understand the context and then make a decision to go forward or leave the site. Personally, I find that I never do this and I know how to. So what do we do when we either do not have the time or the knowledge to review a website application?
When trying to solve a technical problem I always lean toward education and in this case education seems to be a perfect solution. In the next week or so 34a Laboratories will make available a free and online version of the ConPraxis Privacy Server that will be suitable for both developers and every day web trotters. It will allow you to enter a URL and see how it validates against a list of well-known web site security threats and security context threats and privacy/data leak issues. It will be a one page at a time tester used for educational purposes. Its intention is to educate not to inoculate, so please do read the reports, learn and take an active part in protecting your PII and Online Identity.
An API will also be available to help you tie these validation checks into Visual Studio, Rad Studio and more. This will allow developers to perform a quick scan of their application from their IDE. Developers also need to consider their content security policy and tools like the ConPraxis Privacy Server and its plug-ins to different development and content environments are a good first step toward both developing and enacting policy.
We have all seen, and not read, a forty page privacy policy notice from our banks or cloud application providers. That may make sense if we trust the provider and we understand they are selling our PII to partners. However, when it comes to being willing to allow someone to steal our information we need to think twice, by educating ourselves on what the browser padlock really means and the security context of the items that appear in the browser chrome we will be safer.
So to state the obvious, I will repeat my previous answer, “No the browser padlock is not meaningless, but in fact is dangerous as it creates a false sense of security “, by educating ourselves, both developers and web trotters we can better protect everyone’s PII. Remember, in the end the browser padlock merely defines how information is being transmitted, it does not relay information on proper application development nor does it provide information on what the web sites content security policy includes.
Cheers,
Rob Yonaitis