Ecosystem of Breaches -- User Interfaces

In the world of applications and the ecosystem of breaches, the thing we interact with most often as people is the User Interface. The UI has its own set of challenges because this is what really usually holds onto our identity. It's the thing that says, 'Hi, I'm Michael' whether that UI really is representing me or not.

One of the things that as an industry we've been getting better at over time, is not having super long-lived tokens, but we do still have super long sessions where we remain logged in. We're not forcing people to reestablish their identity and that means that these tokens may actually be getting exposed and be being used while we're not really using the User Interface.

The application, the UI itself, also needs some level of access whether there is a user represented or not. One of the challenges I've seen over time is that we tend to give the application a little more access than it needs and while we may not be exposing personal information, we may be exposing organizational information that can lead to other kinds of exploits and hacking.

Those application credentials have to be stored somehow that they don't get exposed but in the world of browser based applications there are definitely challenges with how to do that securely, conveniently and performantly and this blance is definitely something that has led to exploits.

That brings us to all that code and data that we store out in individual user's browsers. Keep in mind your entire body of code is something that a bot running from a server somewhere can download and then interrogate to find back doors or other ways to exploit your code.

Of course the browser itself has its own local database -- we use local caching and we use other ways to store data locally, and if that browser gets compromised (which we will talk about more when we get to devices), the data can be interrogated and harvested.

Finally, when we're developing code, there are conventions for how we call to the backend, and sometimes we violate those conventions for various practical reasons. I've seen UI teams create mirrors and copies of data outside of the original source, sometimes in the UI and sometimes in part of the application stack on other servers that are not associated with the backend.

And let’s not forget those workarounds where something wasn't quite right in the API structure or the backend access. We hire creative, smart people to deliver a uer experience and schedules sometimes require creative workarounds. Those workarounds become fragile places and frequently when we're looking at how companies got breached, those workarounds are exploited.

Remember:

• We should verify Identity frequently
• Tokens should be short lived and contextual
• Application keys need to be secure
• Code can have clues to how to hack the backend
• Local Databases are not secure
• Workaround and creative code can lead to breaches