APPLICATION SECURITY STRATEGIES
Application security: Past myths, present excuses
Anurag Agarwal
03.14.2006
Rating: -3.33- (out of 5)
|
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:
All of those points are related to authentication and should be properly addressed and documented.
We don't generate session ID.
Issue: 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) co
To continue reading for free, register below or login
To read more you must become a member of SearchSoftwareQuality.com
okies, 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:
We don't use cookies.
Issue: 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.
Issue: 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:
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.
|
|
|
|
|
|
