Social Loginwall Failure

#devops #infosec #HTML5

It is not uncommon today to click an interesting link you see on Facebook only to be confronted by a "social loginwall". If you aren't familiar with that term it's probably because I just made it up to describe the use of CSS overlays to "hide" the content you want with a second overlay, usually containing a plaintive "login or register to see this content" dialog.

It's annoying, particularly if it's a random site you're not sure you want to visit again and aren't comfortable openly sharing the gory details of your Facebook life with some third-party site.

So what do you do? Close the tab? Swear? Sigh and move on?

Not me because, well, I can read a DOM and I'm a developer by trade and Chrome has generously made sure I have access to a debugger that can modify in real-time just about any piece of a page.

That "delete node" option neatly eliminates the "social loginwall" with only minimal irritation on my part. Couple clicks and voila! I'm reading what you thought you were gating.

The lesson here is if your business model (and logic) require that a visitor be logged in to see certain content, you'd better make sure that it's enforced somewhere other than on the client.

C'mon. I've got marketing in my title for crying out loud. If I can circumvent your attempts to enforce application logic flows then, well, lots of other people can and honestly, there's probably a plug-in that will do it automatically for folks who aren't trained as developers.

DOMAIN (APPLICATION) LOGIC

It seems increasingly there's a disconnect as application architecture transitions from its traditional client-server model to a modern, API-based model. That disconnect is caused by the reality that the API is focused on data and business logic - not domain (or what we might call application logic). So that logic that controls state, that controls access to data, ends up where it doesn't belong: on the client, in the presentation layer.

And because the technologies used on the client, in the presentation layer, are almost exclusively* markup language that must be parsed and rendered, well... it's fairly easy to circumvent client-side application logic as well as the oft-times rudimentary security mechanisms. Evidence of that is seen in the OWASP Top Ten, where XSS and CSRF remain two of the top vulnerabilities developers (and devops) should be addressing.

And yet the exigencies of the mobile explosion complexify (yes, I made that one up, too) addressing such issues. On the one hand, we could go back to a more traditional three-tier architecture, but that reduces the benefits of the emerging, API-centric model in which the server-side components are focused on data, while the client worries about presentation (GUI). On the other hand is a new, emerging model that more concretely implements the application best-practices model.

There's That Strategic Point of Control Again

That's the CLIENT INTEREMDIARY SERVER pattern, and it's important; it provides a light-weight, intermediate tier on which to provide security and application (domain) logic enforcement without disrupting the basic model. The proxy, like the application delivery controller model, provides a strategic point of control at which a variety of client and server-side operational risks can be addressed. This point of control is also the appropriate place to provide metering governance. The technical point of metering is, after all, to reduce the load on services to ensure availability. If the service has to make the determination whether a request puts a user/application/partner over quota, it defeats the purpose because the resources are being consumed anyway.

Metering through an intermediary, however, insulates the service and provides a better assurance of availability. It also enables a programmatic point in the data path** where new authentication and authorization can be provided, without modifying the service itself. Most important, however, is the elimination of as much application (domain) logic from the client as possible to avoid the consequences of exploitation of both application and security-related logic.

*Plug-ins, while theoretically safer, are not without their own risks. See "Adobe Sandbox: When the Broker is Broken" for a good example of this.