Security and the Web App

Mike Donoghue

January 2, 2007

Admittedly, many products rely upon a backbone of conventional server technology, and are thereby limited by this necessity in their functionality when it comes to system design. This is especially true when considering that older, behind-the-scenes mechanisms are often called upon to interact with newer products and frontends that may have gaps in their design. These applications have the potential to make it--and its information support structure--vulnerable to security attacks, since their very limits expose weaknesses.

Exposure Check

When constructing Web-based applications, concern over customer bandwidth bottlenecks and simultaneous high transaction volume is king. This often means that their functionality is distributed over many servers by means of a tiered architecture model and that that functionality is dependent upon client code and data feeds. Additionally, there are situations where script-oriented development languages are used and frequent changes to procedures for authentication and certification are made. The combination of these factors regularly lead to application security flaws which then become cannon fodder for hackers who then use their abilities to break into sites and get a hold of critical systems.

One direct problem with these products is the very nature of their strength--accessibility. Localized products and those that use proprietary design concepts are understandably less likely to be attacked. The ease of use of Web tools and its language components unfortunately makes the Web-based applications a more popular target. The Web also provides the means to deliver these offenses while providing some degree of anonymity.

Security protocols and products provide a small amount of protection, but for those that know how to manipulate code and data feeds (for example, forcing lower prices into a website shopping basket) or send corrupt information (for example, disrupting process workflows), then fraud and abuse transactions as well as identity theft are more possible.

It used to be that security updates for various products and services were intermittent interruptions. Nowadays though, the process has become more frequent and, by physical and psychological necessity, more “invisible” to the user. One doesn’t have to look far back on any given day into the archives of a news service to read about how a company or government agency was infiltrated and sensitive data potentially retrieved.

Discovery Check

Just as with development, there never is any cookie-cutter solution when it comes to making a Web-based application secure. The diversity in which Web technologies are deployed can make the goal seem unattainable; however, it can be reached through a comprehensive assessment approach that employs the use of a variety of tools and techniques. Testing products abound in their ability to locate the common gaps for simple programs, but they serve only as a partial solution and should be considered only for first round of security evaluation.

An analysis to help determine security issues should include the following assessment parameters:

Review of incoming code for information that could be used to determine the workflow of an application or how it functions.
Examination of application exchanges that create interactions between different system components. This creates a risk for mimicked system functions.
Determination of limits of appropriate server responses when presented with data format incongruities. This requires a review of validation checking procedures.
Review of methodologies that could be used by intruders to access components that give a “back door” entrance into components that otherwise require high permission rights or bypass authentication processes altogether.
Determination of effect of incoming code and locally stored information (for example, cookies and session data) that may be designed without the need for established authentication protocols.
Examination of methodologies used to exchange data that may be vulnerable to attack, manipulation or retrieval.
Evaluation and periodic reevaluation of deployment and security configurations to take into account current and ongoing threat concerns.

Reality Check

It has been commented that sloppy work has allowed for too many forays past the security of Web-based applications.

Given that we are creatures of habit, it is often simple for hackers to guess at a number of security protocols we set up that are both simple to remember and easy to tell others of in situations or roles where we have to share tasks or responsibilities. Master account holders are the worst offenders and the ones naturally with the most access.

Unless we want people to start finding the hidden key that we place behind the geranium pot next to our virtual front door, we need to start getting serious about truly locking it up. Making sure that we have thorough cache and cookie cleaning procedures, verifying that we have removed dead code that might otherwise grant access and disallowing developer shortcut starter pages that circumvent the login process are only a few small things that we need to do if we truly don’t like unwanted visitors.

The URL for this article is:
https://www.projectmanagement.com/articles/234121/security-and-the-web-app