With regard to the heise report in my above post, here are some of the findings which drew critiscism:
- In several cases, when they found problems with websites, they sent the findings to the Data Protection Officer for the company, also asking whether they though the problems found were serious enough to require reporting the incident to the state data protection authorities. In nearly all cases, they DPO agreed it was a notifiable transgression - in only one case did the DPO not respond.
Also, in many cases, the DPO was unaware that their employer even had such a system in their portfolio. This, in and of itself, makes it a reportable transgression - the DPO must be included in the initial discussions on the product, before its definition is finalised and certainly before any coding starts! - Tracking and fingerprinting technologies built into the websites - this is a medical appointment system, there is absolutely no need for any tracking information or website statics, like Google Analytics. You know who the users are you know you have a finite number of appointments, you don’t need any other information.
- The sites often used CDNs or other sources to load external libraries. Again, this is medical information, all of the code should be self-hosted and no external tracking.
- Many sites used an incrementing number to deliver results (E.g. example.com/test?123456), which meant, if you had your number, you could call up anybody else’s results by simply changing the number in the URL!
- One site was delivering a JSON file with all of the test results carried out by the company and the web browser was doing the filtering to just extract the user’s test results. But the user had access to every test the company had made!
- One site was using a fax service to provide a fax to the doctor’s practice with the registration information of the user. It didn’t pay for the service, it just used a free fax-test service, which had a free-text field. It put in the telephone number of the practice and the user was told to enter their medical history and name and contact data into the free text field - which had the warning that, “this is for test purposes only, the information is not encrypted in transit.”
There were many others, but those were the most serious.
When my wife organised a test for us, she phoned the local chemists to obtain an appointment. They created an account for us. They set the password for both of our accounts with the testing service to “123456”!
On top of that, the service was using a serialised identifier for the results and wasn’t forcing strong passwords. There was also no option, at the time, to change the password on the account. I found a workaround, you could say you “forgot” the password and could then enter a new password (email link, at least).
I contacted the site and informed them that the passwords were being set as 123456, I thought it was a system standard to start with, but they cleared that up, that the chemist was setting the passwords. I also informed them, that there was no change password option, only “forgot password”, their answer was, yes, that is correct, that is how you change your password! I did manage to get them to add an extra change password option in the account settings, at least.
That is the problem with these rushed systems. Developers used to developing commercial websites, or providers who have no real experience with developing web applications at all, are just bashing together some sort of system that “works”.
They aren’t taking into account best practices for web platform development, they aren’t taking into account GDPR requirements or medical system requirements (no tracking, data confidential, deletion of data once it is no longer relevant for the original purpose etc.) and, where they are doing some of it right, they are applying normal platform practices, such as using CDNs or other resources for code libraries, as opposed to making them self-sufficient and secure.