App security audits: Don't ignore thick clients

When it comes to running application security audits many organizations make the mistake of assuming that only Internet-facing, browser-based Web applications deserve scrutiny. After all, thick client applications tend to face inside and tend to be compiled binaries so they are less risk of malicious tampering.

That assumption is dangerous.

Thick client applications face far fewer attack attempts than applications facing the Internet, but they also tend to handle the most critical transactions, and employees often know how these programs work from both a business and a technical perspective, making them prime targets for insider attacks.

In fact, compiled executable clients are often inherently less secure than browser-based Web applications, and the tools for tampering with them are available and easier to use than you might expect.

One axiom of application security is "Never rely on client-side validation for security" because it is easy to manipulate the client and bypass security controls. Yet the very definition of a thick client is one that performs most, if not all, of the application's logic. In many cases the application's architecture is two-tier, meaning the client talks directly to a back-end database with no intermediary server to enforce security. As a result, virtually all of the application's logic, including security, is in the client and thus in the hands of the potential attacker.

Thick client applications are prone to many of the same types of vulnerabilities that thin client and Web applications are. Yet the fact that much of the security enforcement responsibility is placed with the client translates into more critical vulnerabilities, including:

Password harvesting: When a user logs in to the application, it is not uncommon for the thick client to query the database for the password of the supplied user name, and then do a client-side check for a match against the password supplied by the user. As a result, the user can supply the username of other account holders and then obtain the password for that user from the database's response.

Privilege escalation: After a user authenticates, the thick client needs to know what functional features that user is privileged to access. This is often accomplished by querying the database and enabling or disabling various menu items depending on the permission bits returned by the database. If the user can manipulate these response bits before they get to the client, he can usually enable extra permissions -- perhaps even full administrative permissions to the application.

Hard-coded application credentials: In an attempt to prevent the users from directly accessing the database, developers sometimes "hide" the application's database credentials inside the compiled thick client. If the user can extract these credentials, he can often directly access the database with the application's full privileges. The security controls built into the client can be entirely bypassed in this way.

• Bookmark this page
• Share this article
  •  
  • facebook
  • slashdot
  • digg
  • Reddit
  • stumbleupon
  • linkedin
  • twitter
• Got more on this story? Email Computerworld
• Follow Computerworld on twitter

• Share
  Share this article

  •  google+
  • facebookfacebook
  • slashdotslashdot
  • diggdigg
  • RedditReddit
  • stumbleuponstumbleupon
  • linkedinlinkedin
  • twittertwitter
• print
• email
• Bookmark