Security and risks with data and its storage

So we all know we're getting datamined (The action of mining for data) to hell by companies like Facebook, Twitter, and every somewhat large social media platform. Along with companies like Google with your search history and anything you do on their platforms, which include a lot.

So that data has to go somewhere, and has to be stored securely so no third party can either walk up to the physical location and take it. Or connect to the servers directly and download the data remotely.
When it comes to gamedev, and the stuff we do. All we really need to be worried about is not only the data we keep ourselves such as WIP (Work in Progress) games/programs. But any data we choose to collect about anyone who plays our games. For the Studio 3 project this trimester, we didn't have to worry about this to a large degree because the data that we're gathering from the player has to do with the game entirely and is stored on the players device rather than a server in New York for example.

But, as for other projects I've been apart of outside University. Well, we encountered a similar situation of exposing user accounts to the wrong people. The chrome extension I help develop with, although I've taken kind of a backseat with it recently and just help support the server side of it, introduced a new feature which involved storing the user's login token to a site. This token is then used to make requests to the site's API to get a session ID that links to that account with the login token.

The problem was it seemed like Cloudflare on my site probably cached a few requests, even though the URLs were different. So the two different (or more) requests returned the same content which when the extension applied the session id. One account got logged in successfully, while the other logged into the same account that wasn't theirs...
This was a big notice to us when we heard about it and rolled back the extension from the public to the previous version, so no more people encounter this bug.
The lesson learned here was to not have Cloudflare cache requests when the query strings were different, or better yet, not at all...

But nonetheless, there was talk of having a server store all this data which I quickly downplayed the idea of it as it would pose a security risk to the already current 13k+ users.

But hey, at least it wasn't on the level of Heartbleed or Cloudbleed, which was a severe bug in OpenSSL for the former and Cloudflare's reverse proxy system for the latter.

Heartbleed was pretty bad since it affected OpenSSL's implementation of TLS (Transport Layer Security). Major sites like Github, Akamai and SoundCloud were somewhat affected and they all took measures to approach the situation and deploy their fix.

Cloudbleed was somewhat similar and is somewhat more documented in terms of what information was leaked. It occurred February this year, although Cloudflare says it could have gone as far back as September 2016. It was caused by some HTTP requests (1 in 3 300 000 requests) leaking data from the server's memory onto the page directly. This data included HTTP cookies, authentication tokens, HTTP POST bodies. Tavis Ormandy, the person who was the first to find the bug/flaw, said he was able to get "private messages from major dating sites, full messages from a well-known chat service, online password manager data, frames from adult video sites, hotel bookings. We're talking full https requests, client IP addresses, full responses, cookies, passwords, keys, data, everything." (You can find out more here)

Tom Lynn

Read more posts by this author.