Is there a name for this flawed way of thinking about security? [closed]

Question

I've recently encountered a developer who thinks that she can implement security on the client end of a web application. Breaking the security is as trivial as reading a few lines of Javascript and changing a URL.

In other words, the "security" of the application is entirely a facade. I know the vulnerability in question is a form of unchecked input parameters, but there's something deeper going on here, since the developer in question was told to make a security layer that couldn't be tampered with, and instead made something that's just a UI that LOOKS like it's secure.

It occurs to me that it would be useful to have a term for this. We already have "security through obscurity", and "security theater" to describe other behaviors people engage in they think is security. Is there any term yet for this? Security Facade is the best I can come up with.

Answer 1

What about : Security Theater?

Security theater is the practice of investing in countermeasures intended to provide the feeling of improved security while doing little or nothing to actually achieve it. Some experts such as Edward Felten have described the airport security repercussions due to the September 11 attacks as security theater.

While it may seem that security theater must always cause loss, it may actually be beneficial, at least in a localized situation. This is because perception of security is sometimes more important than security itself. If the potential victims of an attack feel more protected and safer as a result of the measures, then they may carry on activities they would have otherwise avoided. In addition, if the security measures in place appear effective, potential attackers may be dissuaded from proceeding or may direct their attention to a target perceived as less secure. Unsophisticated adversaries in particular may be frightened by superficial impressions of security (such as seeing multiple people in uniform or observing cameras) and not even attempt to find weaknesses or determine effect.

Putting a lot of validation on the client side is similar to that. Most people will think that the site is secure when in reality it is not. If you don't really care about security and just want to dissuade lazy attackers then it might not be a bad idea.

Answer 2

Unauthorized Data Access at Server

I suggest you're thinking about this problem backwards. The vulnerability is at the server, and therefore, you should just call as you see it.

Obfuscation is a type of Security Through Obscurity; there's nothing inherently wrong with it unless you believe it more secure than it really is (like your colleague). Client side validation checks are also recommended as they improve responsiveness and reduce server impact, although relying solely upon them is insecure. The flaw is not with the client, but with the server. Don't name the client side "failure", as there isn't one. Instead, name the server side failure which is a missing data verification check (be it a boundary check or an access check).

In this case, the flaw is the missing check, which you know you can expose by crafting your own mini JS hack from a web browser. The moment you demonstrate it theoretically or actually, your team will understand what you mean when you point them at the security hole in the server.

Answer 3

All these terms have a lot of play in the joints, of course. But I think I tend to agree with the question author here: I would hesitate a little to use the labels "security theater" or "security by obscurity" re. the situation the OP offers up. "Security theater" is most often applied where the person who puts or keeps the supposedly effective security measures in place actually knows that they are weak & flawed in reality. Instead, here it seems like the source is simply just ignorant of the real security implications of what she wants to do. As for "security by obscurity", to channel Orwell I think one can argue that that term has been so over-used in the security community at this point that it has lost most of its original, useful meaning. At any rate, it's a term I personally try to avoid using except where it unquestionably applies. ("Why do I think WhirlyBirdBSD is the most secure OS? Well, since there are 700 people in the world that run it nobody ever targets it.")

As for how one might categorize this situation as instead, from technical & practical standpoints I'm with @Schroeder & others who suggested simply ""client-side security" as the category of failure/label. An excellent, concise way of putting it.

More generally, colloquially, & facetiously ... perhaps call it an UROASM failure: Unfortunate Reliance On A Security Myth. :) Category includes tons of other bad practices based on common-but-completely-wrong assumptions. (For eg., not caring about whether the OS on your PC gets patched because you use anti-malware software, which will surely protect you from anything that could be harmful. Or thinking you're safe from SQL injection because you escape user input.)

Answer 4

Security facade sounds like the most elegant choice. In this case the security is nothing more than skin deep and really provides only limited protection against the most lackadaisical script kiddies.

Answer 5

I would like to offer up another approach: Security Gaffe.

This is not necessarily an industry term, but all uses of the phrase that I see in the media imply a similar definition:

1. The creator/provider generally thought their system was secure enough.
2. An unintended security mistake was made.
3. The mistake that was made goes against industry best practices, and thus could probably have been easily avoided.

The main difference with this approach is that the "Gaffe" is not a flawed way of thinking about the problem, but instead it represents the flawed implementation resulting from the flawed thinking.

As a side note, when doing a quick search for "Security Gaffe", all the uses of the phrase are related to a security breach resulting from a security gaffe, but I believe the gaffe is there regardless of whether it is exploited or not.