Developer

Ask these key questions to test application security

Companies should conduct application testing from both an authorized user's and an unauthorized user's perspective. This testing should include all systems that make up the application. Not sure where to begin? Mike Mullins suggests some key questions to ask when testing.

Worried about security issues? Who isn't? Automatically sign up for our free Security Solutions newsletter, delivered each Friday, and get hands-on advice for locking down your systems.

For many small and midsize networks, application security can often be a gray area. Almost all companies test for vulnerable versions (i.e., missing security patches) and default configuration files. But while these steps do address network security, they fail to identify flaws within the applications themselves.

If your organization has a Web server, then it has a deployed network application. If your company has a database server behind its Web presence, then it has twice the risk for application security.

Before investing any time or money in securing or verifying the security of an application, first perform a risk assessment. In particular, if you're dealing with the storage and/or use of sensitive personal or financial information, consider conducting a full code-level review and thoroughly documenting your actions. Not everyone needs this level of security, so measure your risk and take appropriate action.

Companies should conduct application testing from both an authorized user's and an unauthorized user's perspective. This testing should include all systems that make up the application. The complexity of your testing should depend on whether the organization created the application or contracted a reputable vendor to do the work.

Let's look at some main areas to focus on and some key questions to ask when testing.

  • Scripting: Can you perform administrative functions remotely from the Internet? Could someone script an attack that overwhelms the application?
  • Enumeration: Is it possible to enumerate account information of other users?
  • Passwords: Have you changed the default passwords to meet the complexity standard for your network?
  • Sessions: Have you based tokens on some easily re-created variable, such as sequential or time and date?
  • Error handling: Does your application reveal any useful information about the products used to create the application?
  • Field variables: Have you fixed SQL injection and buffer overflows that take advantage of system calls to unauthorized programs?
  • Code commenting: Have you cleansed HTML source code of all comments and metadata that doesn't serve an end-user function?
  • Session time-out: Do sessions expire after a reasonable period of time?
  • Session cache: Does information expire to prevent someone from replaying a session?
  • Network parameters: Have you thoroughly documented ports and protocols and filtered them for content and source origination?

These are just a few of the areas you should pay special attention to when deploying a network application. Keep in mind that application development is a complex process, and it must incorporate security checks as development occurs. Going back after the fact to fix a security flaw can sometimes cost more than the original development of the application.

Final thoughts

All of this might sound like a lot of high-tech speak that seemingly has little bearing on your network. However, it's actually a relatively simple process, and it's one you should perform for every box on your network.

Take steps to secure the platform the application resides on, and test and secure the application from an authorized user's perspective—and a hacker's perspective. Make sure you find problems before they find you.

Mike Mullins has served as a database administrator and assistant network administrator for the U.S. Secret Service. He is a network security administrator for the Defense Information Systems Agency.

Editor's Picks

Free Newsletters, In your Inbox