You wouldn't walk into a bank and find money or valuables laid out in plain view and easy to reach. However strong a bank's walls are, the assumption is that people who get in legally during normal working hours might still have malicious intent, let alone those who might succeed in breaking in at night. This is the reason why money, gold bars or safe deposit contents tend to be further secured by vaults, security guards, locks and thick steel doors.

Although this may be commonsense, a lack of security is pretty much standard when it comes to organizations with web sites allowing customer to purchase goods or make enquiries online. While perimeter security is well addressed through products such as firewalls, application level security is too often disturbingly neglected.

The weakest link

According to a recent survey published by San Francisco's Computer Security Institute and the FBI, nine out of ten web-based applications tested were susceptible to serious security breaches. Some were open to fraud, while the majority of the rest unknowingly allowed partial or full access to sensitive information - access that can allow hackers to modify and manipulate both raw data and application code. Just because your application hasn't been hacked (assuming you can be certain of that to begin with) - doesn't mean it can't be.

The costs of a security breach are quite obvious. When any sum of money can be transferred from your bank account to that of your hacker's, the liability of a breach is practically unlimited. Aside from the direct monetary value of security breaches, they can also result in less quantifiable costs such as damage to reputation, poor brand image or customer dissatisfaction.

Any vulnerability can be exploited by both amateur and professional hackers, either for fun or for the financial or business benefit that results from their penetration. In fact, security breaches can be the result of a combination of bugged code and an innocent user's actions or mistakes.

Get development right

Software is only ever as good as the code that lies behind it. No program can be completely bug free. However, basic development and testing methodologies must be adhered to if companies are to make sure the code is free of the high-risk/high-impact bugs that could make the application crash, give the wrong output or allow users to execute commands they are not supposed to.

While these principles are often no more than elaborate descriptions of what commonsense would dictate, commonsense is, alas, not so common. This is why getting external, specialized assistance in the development stage can be a very worthwhile investment.

Furthermore, the sooner errors are recognized, the less costly they are to correct. This logic should be applied as early as the requirements development stage, where initial bugs can be detected if properly tested.

The functional aspect of programs is the most important issue for everyone involved in development, yet critical 'functional' bugs often make their way into the end product. It is no wonder then that information security is, more often than not, given less attention, when organizations can't even make sure the application does what it is supposed to.

Don't get trapped in the web

An easy way to minimize security risk is to run an application on a standalone machine, not connected to the internet or intranet. While philosophically speaking this is a logical solution, it is as practical as closing down a business to make sure that costs are kept to a minimum.

Despite the burst of the dot-com bubble, the internet is here to stay. An old tactic to encourage businesses to advertise in the yellow pages claimed: "If you're not there - you're nowhere." This is quite true for the internet today. What's more, unlike the yellow pages, the internet is not just a fancy business directory that includes some flashy brochures and background information. Web sites allow customers to perform actions, execute commands and even place transactions. These features, by their very nature, dramatically increase the challenges developers and administrators face trying to secure those sites from malicious abuse.

Another way the web can increase security risks is the accessibility of hacking tools. Hackers' web sites, where these 'professionals' can exchange ideas, participate in newsgroups, download tools and get updated on the latest trends and technologies abound. Furthermore, legitimate software systems vendors often publish their software's known vulnerabilities on the web and suggest a way to protect against the vulnerability or offer a patch that fixes the problem. Unfortunately hackers often make better use of this information than the people it is published for.

Common application-level security vulnerabilities include

• Confusing infrastructure security with application level security - firewalls and intrusion detection systems (IDS) are limited in their ability to provide application level security. For example, a firewall cannot be allowed to block port 80, as it would be practically synonymous to prohibiting internet access. Hence having the best available firewall still does not ensure application-level security.
• Inadequate development - errors in the common gateway interface (CGI) scripts of web-server applications. Since new code lines and patches are frequently added, errors might be created even when development was bug-free.
• Source code availability - when we look at a piece of paper we cannot view the molecules that make it without the use a very powerful and expensive microscope. However, when we look at a web page this microscope, a.k.a. 'view source' is readily available to all. This allows for viewing hidden fields or file naming conventions.
• False sense of SSL security - organizations that use the secure sockets layer protocol usually realize the importance of data security, however they may wrongly assume that it provides application-level security. It does not. Most of the following forms of attack are possible even in the presence of SSL.

Some common application-level security attacks include

• Hidden field manipulation. As a web page's source code is easily available, this allows anyone to view hidden fields, which are frequently used to provide status information to the server. Unfortunately it also allows hidden field tampering. Going to the local camera shop one can't really go behind the counter, change the camera's price tag without the shopkeeper noticing and then buy it for the reduced price. However, going home and visiting the shop's web site where the same camera's price information is stored in a hidden field might be different.
• Cookie poisoning. Since cookies are sent from the server to the browser and since they are easily viewable and editable, they can be used to attack the server. If the application does not expect cookie modification it may process a poisoned cookie, which could modify fixed data fields, allow viewing of unauthorized information or enable users to masquerade as someone else.
• Buffer overflow. Overloading the server with more information than it expects to handle (e.g. a text string with 10,000 characters instead of a maximum expected number of 25 characters). Thus can result in server failure, malicious code execution, overwriting of crucial system data etc.
• Known vulnerabilities. As mentioned above, hackers often make better use of information published by software vendors about their products' vulnerabilities than the people it is trying to assist.
• Cross-site scripting/forceful browsing. Use of the address line to perform actions. Normally this is achieved by adding a script tag to a URL (uniform resource locator). As with cookie poisoning, if the web site does not expect such URL modifications, it may execute the malicious command or allow breaking out of the server's root directory when the hacker refreshes the page.
• Database manipulation. Free entry fields/forms might be used to enter valid SQL commands.

The missing piece of the puzzle

In the day and age, when not enabling online access to services and information is simply unthinkable, application-level security is crucial. It is as important an element as any other to complete the security puzzle, which is required to maintain the performance, integrity and reliability of any system. While the reasons for lax application-level security vary, they are in fact no more than mere excuses.

The solution is a combination of proper development and testing (starting from the design stage) with as strong an emphasis on security as on any other element. And, where necessary, organizations should apply adequate and properly maintained infrastructure security applications, and adequate and properly maintained application-level security applications.

Itay Haber is marketing manager for TesCom (www.tescom-intl.com)