The Client Is Not Always Right!

J’accuse!

I often get the question, “How well does your product handle iOS?” I’d like to explain why I think this question is a warning sign for an application security program.

An unfortunate part of my job is that sometimes I have to explain that people are focusing on the wrong objectives. Here’s my unfortunate dose of reality for today: We all need a perspective adjustment when it comes to “the client.” With Drumpf-esque powers of oversimplification, let’s start by envisioning that half of your apps are server code, and half client code, looking something like this:

Client apps could be native mobile APIs, traditional browser code, or classic thick clients that run on your desktop. I am not talking about mail clients, browsers, or stuff like that. From this perspective, it sure looks like Client Apps are half of your portfolio. It seems like you should spend an equal amount of resources securing them!

Well, I disagree.

Exhibit A: Clients Don’t Breach Widely

Most of the time, if a client is compromised, that particular client’s been compromised -- not all the clients. So let’s look at our portfolio again, but this time let’s overlay where all the breaches take place:

            Source: Every data breach study ever

In fact, here’s what the Verizon Data Breach Incident Report said about mobile specifically:

As with the 2015 report, compromises of mobile and Internet of Things devices are not a significant factor in the 2016 DBIR.

So, if the threats that justify our jobs are all focused on the server, shouldn’t we be, too? Shouldn’t you choose a vendor that does an A+ job on the stuff that matters instead of the vendor that does a C- job on everything? Choosing a product vendor because they “support” mobile is the really saying you care more about “checking the security box” for clients rather than actually, you know, securing stuff.

Exhibit B: “Mobile Threats” Are Still Mostly Server Threats

Take a look at the OWASP Mobile Top 10. Almost half of them are actually server problems. Take a look:

• M1: Weak Server Side Controls. Obviously a server thing.
• M3: Insufficient Transport Layer Protection. Yes Virginia, the server should enforce transport security.
• M5: Poor Authentication and Authorization. The server’s model of these is all that matters. Even if the client gets it wrong -- what can the client do that really harms anyone if the server still enforces it correctly?
• M9: Improper Session Handling. Same -- who cares if you get this wrong? The data on the server is still the data to protect.

The others are still worth thinking about, for sure. It’s good to encrypt data at rest on your phone, for example. But, as part of a program, these risks must take a backseat to the server.

Exhibit C: The Tooling Ain’t Great

This is a tricky subject, because it depends on the language of the client app -- with widely varying quality available on the market.  The best bet for analyzing any client side code is using BlueClosure (formerly DOMinator from Minded Security) -- an IAST (Interactive Application Security Testing) tool for analyzing client-side JavaScript. For JavaScript, the rest of the market is really super-grep.

For native mobile apps, there are some vendors who use cool instrumentation technology to find intentionally malicious apps -- but they don’t find much in the way of custom code vulnerabilities that can really hurt your organization.

Closing Arguments

Certainly there are issues in client-side applications. Even though a client issue only compromises one single client, in extreme situations that’s all it takes to make the impact of a vulnerability truly critical.

I would also never say you can outright ignore the client. It’s hard to build a culture of security if it’s only security sometimes or security some places. However, we should stay focused on the types of flaws that can be really harmful -- which, thankfully, there aren’t many of in the client.