By now you have probably heard of Missouri governor Mike Parson tweet threatening to prosecute a journalist for responsibly disclosing a data breach. If you missed it though, according to the tweet and the governor’s ensuing press conference, a journalist from the St. Louis Post-Dispatch found teachers’ SSNs embedded in a public web page by accessing the HTML of the webpage and decoding it and reported the data breach to the state’s Department of Elementary and Secondary Education. The website administrators updated the site to better protect the teachers SSNs indicating they found a fault in the site itself. Instead of thanking the journalist for responsibly disclosing the breach, Governor Parson instead threatened legal action for this “hacking” effort. While I find the governors comments amusing this does provide a valuable lesson for us on how to protect private information on a website.
- Labeling a field as hidden or password only changes what the browser displays
The view on a browser will differ from the HTML code but anyone can view the HTML. You can’t depend on the application like a browser to hide the code for you. A user can change password fields and hidden fields to display this information. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/input/password
- Don’t encode private information in HTML.
Websites can safely encode HTML into base64 to make transferring of the code over the internet to a browser easier. We don’t advise to send private information in base64 because anyone can easily decode it. If you send private information, encrypt it by using HTTPS. Obviously, anyone with access to the page can decrypt it at their browser so only send what the client has authorization to see. Base64 does have its uses. For example, a query to a database uses special symbols that will break a URL. We can encode the query with base64 to send the query, but we don’t like to see private information in the query. https://developer.mozilla.org/en-US/docs/Glossary/Base64
- Send only what’s needed.
Encrypted information won’t protect data if it ever becomes decrypted on the client. We see this most often with scripting inside HTML. The script will make a query to a server with the client information and the server will respond with a link to the data requested. We can view this link by debugging the code in the browser or viewing the traffic with programs like Burp Suite or Fiddler. From here we can access the data directly without any need to authenticate. To protect against this, you must check the client has authorization at the time of the request for the protected data. You can do with a session cookie but make sure the session has a short expiration period in case the client becomes compromised at some time in the future. Also use the session cookie to only allow access to the data required so other protected data stays safe. https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/cookies
Web servers should never send any protected data, encoded or otherwise, to the client until the client has authenticated with the server and has the authorization to view that data. This would have prevented at least some of the blunder that the Missouri government faces right now.