From the Blogosphere
Social Loginwall Failure
It is not uncommon today to click an interesting link you see on Facebook only to be confronted by a "social loginwall"
By: Lori MacVittie
Apr. 9, 2013 09:00 AM
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
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
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.
**Starting to sound like Application Layer SDN? It should...
Latest AJAXWorld RIA Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week