A variety of attacks can be used to gain access to SaaS apps. Here's how to protect user accounts from exploit.

Kurt Marko, Contributing Editor

September 7, 2011

3 Min Read

InformationWeek SMB - Sept. 12, 2011

InformationWeek SMB - Sept. 12, 2011

InformationWeek Green

InformationWeek Green

Download the entire InformationWeek SMB, distributed in an all-digital format as part of our Green Initiative
(Registration required.)
We will plant a tree for each of the first 5,000 downloads.


Kurt Marko: Saas ID Security

Kurt Marko: Saas ID Security

Data security is a perennial concern for cloud customers. But one issue many SMBs overlook is identity protection. The risks are real when it comes to Office-like productivity suites because one login grants access to email, contacts, calendar, documents, and more. And in this era of browser-based applications, it's easier than you think to hijack credentials.

The easiest way to compromise Web application identities is via session hijacking, a.k.a. sidejacking. This exploit, made popular by the Firesheep Firefox extension, takes advantage of the common practice of websites using an unencrypted cookie to store state information in a session key. While the initial site login is SSL-encrypted, subsequent transactions between the client and various Web pages within a site's ecosystem are authenticated via an unencrypted token. Anyone who intercepts the cookie--and that's easy to do on public Wi-Fi networks--can impersonate the user. While Gmail on a PC isn't vulnerable to this particular exploit, Facebook and Twitter are, as were Google services on Android until Google rushed out a patch a few months ago. Microsoft says Office 365 uses SSL for all application connections.

Another technique is a variant of a cross-site scripting attack that exploits privileges granted to extensions in Google's Chrome browser to access credentials and inject code into other browser sessions. In a recent demo at the Black Hat conference, researchers developed a "malicious extension" that could do everything from scan ports on the local network to access a user's Google credentials and email contacts and chat with friends. It could even inject a JavaScript keylogger onto another Web page, say a bank or credit card account, open in another tab. This exploit is particularly pernicious because Google doesn't vet browser extensions.

Another way to compromise Web logins is through the combination of weak password-recovery processes and clever social engineering that makes it easy for attackers to impersonate legitimate users and steal their identities. This technique was made famous when a hacker reset the password to a Twitter executive's public Gmail account, combed through emails to discover the executive's Google Apps account name (which used the same password), and then stole documents from Twitter's internal email system.

Now, while none of these attacks is unique to SaaS applications, when you run your business on the Web, you open up your users to these threats. Nevertheless, these exploits shouldn't be a SaaS showstopper if you employee prudent security practices. For instance, use SSL wherever possible (Google Apps has a domain-wide setting to enforce this). Monitor accounts for unusual activity. Use VPN tunnels (making sure all traffic traverses the VPN with split tunneling turned off) on public Wi-Fi networks. Mobile users of Google Apps who access their accounts from untrusted networks should strongly consider enabling Google's two-step verification, which augments the basic user name and password login with a security token sent to a smartphone. Domain admins may have to set this up for their users, and probably should.

About the Author(s)

Kurt Marko

Contributing Editor

Kurt Marko is an InformationWeek and Network Computing contributor and IT industry veteran, pursuing his passion for communications after a varied career that has spanned virtually the entire high-tech food chain from chips to systems. Upon graduating from Stanford University with a BS and MS in Electrical Engineering, Kurt spent several years as a semiconductor device physicist, doing process design, modeling and testing. He then joined AT&T Bell Laboratories as a memory chip designer and CAD and simulation developer.Moving to Hewlett-Packard, Kurt started in the laser printer R&D lab doing electrophotography development, for which he earned a patent, but his love of computers eventually led him to join HP’s nascent technical IT group. He spent 15 years as an IT engineer and was a lead architect for several enterprisewide infrastructure projects at HP, including the Windows domain infrastructure, remote access service, Exchange e-mail infrastructure and managed Web services.

Never Miss a Beat: Get a snapshot of the issues affecting the IT industry straight to your inbox.

You May Also Like


More Insights