Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Application security: Past myths, present excuses

Increasingly, hackers are targeting Web applications. The problem is exacerbated by the fact that development managers wrongly think the security technologies they have relied on in the past will protect those apps. Anurag Agarwal sets the record straight on what those technologies actually do.

Over the past five years we've seen an unprecedented growth in the sophistication of application security measures. Unfortunately, that has been paralleled by an increase in the ability to penetrate applications.

With recent attacks more targeted at Web applications, it has become increasingly important to address application vulnerabilities overlooked in the past. Though some of the companies are maturing and addressing application security issues, a vast majority either underemphasize the importance of those measures or labor under misconceptions.

This issue is further exacerbated by the lack of proper process or guidelines. As a result, a vast majority of development managers rely heavily on pre-programmed tools such as AppScan from Watchfire or WebInspect from SPI Dynamics to identify the vulnerabilities in their applications. Based on my experience in this field, I have found that the problem is two-fold: people rely on out-of-date information for their decision-making and they lack initiative for staying current in this rapidly developing field.

Below are some of the common reasons I have received from development managers for believing their applications are safe and what they should do to ensure application security:

  1. We are behind a firewall.
    This is my personal favorite. It is perhaps the most dated belief of them all. With recent attacks targeting applications, firewalls and intrusion detection systems (IDS) are not sufficient.

    Solution: Security needs to be tightly integrated into the application, and there should be a proper secure design methodology. Managers, architects and developers need to increase their awareness and receive differential training. For example, developers should concentrate more on secure coding of their applications, whereas architects ought to focus on designing secure applications.

  • We use SSL for authentication.
    Using SSL doesn't necessarily means you are safe.

    Solution: The architect should look beyond using just SSL. Some points to consider while designing the module:
    1. Is SSL being used only for login/authentication or for the entire site?

    2. If the SSL is being used only for authentication, is it also used for the change password or forgot password page?

    3. Does a session get created? If yes, does it use a secure cookie to store the session ID?

    4. The document should also contain encryption detail such as key length, encryption algorithm, hashing algorithm, etc. Not to mention the fact that it should comply with the company's standards.

    5. Where are the user ID and password stored? Are they stored in the database? Are they stored in clear text or encrypted? If encrypted, then is it one-way encryption?

    6. If a user forgets the password, does a system send his original password in an e-mail or does the system generate a new unique one-time password and send it via e-mail? Is the user forced to change the password when he logs in for the first time? Is the e-mail that contains the password secure?

All of those points are related to authentication and should be properly addressed and documented.

  • We don't generate session ID.
    Almost every developer knows how to create a session object and how to store, retrieve or delete values from it. What developers also need to understand is the story behind the scenes. When a session is created the session ID is generated, which usually is stored at the client browser in one of the three ways: (1) appended in the URL, (2) hidden form fields or (3) cookies, where cookie usually is the default setting.

    Solution: Two security measures are necessary to ensure security. Namely, in the server configuration panel, the cookie generated should be secure and the life of the cookie should be for that session only. Other points to consider:
    1. The session ID should be encrypted, and the cookie should not contain any other information than the session ID.

    2. When a user logs out, the session should be invalidated. For sensitive applications, the user should be forced to close the browser. That will clear out any cookies generated for that session.

    3. The session timeout value should be more conservative for sensitive applications, such as e-commerce sites (15-20 minutes).

    4. The other thing that is overlooked is whether the application allows multiple concurrent logins or should allow multiple concurrent logins. Another step that can be taken is to map a user session with its IP address. Those two approaches coupled together can greatly reduce the chance of session hijacking.

Application security realities

Myth-busting Web application buffer overflows

Are you leaving your apps open to attack?

  • We don't use cookies.
    Regardless of whether or not the developer is creating cookies for the application, the server generates cookies in the background.

    Solution: It is imperative that the architect remains aware of cookies being generated by the server and knows why they are generated. If the architect determines that cookies are not required, then cookie generation should be disabled. For those that are required (e.g., session), architects should ensure that the cookies are secure. That will prevent malicious people from snooping into applications.

  • We use secure FTP to transfer data to a third party.
    Even if you use proper encryption algorithms and appropriate key length, you may be safe from only one communication point to another.

    Solution: Proper measures should be taken to safeguard the data before and after the communication as well. Here are some points to consider:
    1. While using secure FTP, are you using digital signatures? Is it two-way authentication?

    2. Where are the files being transmitted? Who has access to them? How long are the files kept before they are deleted? Are the files backed up after they are processed? What is the backup retention policy? Is it necessary to keep a backup? Remember, the more places the data resides, the harder it is to protect it.

    3. After the file is processed, is the data stored in the database? Who has access to that information in the database? What kind of security mechanisms are in place to protect that data? This may seem more like an infrastructure issue, but in reality the business and development managers own the data and are responsible for safeguarding them. They should capture the information from the third party in a signed document.

    4. If there is any error during the transmission, how is it handled? Are errors logged? Does the log store enough information to see if there is a pattern in the errors?

As you can see, a little due diligence not only saves a lot of effort in patching these applications but also goes a long way toward integrating security in the design phase. Remember, every step, however small, is a step forward in securing your application.

About the author: Anurag Agarwal, CISSP, is an application security specialist at Wipro Ltd. where he addresses different aspects of application security in the software development life cycle.

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.