This has left applications vulnerable, especially as, according to analyst firm Gartner, 70% of successful attacks occur through the application, rather than through the network or operating system.
Cyber intruders, especially, are succeeding in breaking into enterprise applications, which can contain sensitive information such as customer credit card details or financial data. This means that large parts of the corporate IT infrastructure are exposed to massive potential damage, in terms of reputation and cost.
Many organisations do not seem to realise that their web applications, in particular, are easy targets. Malicious users do not need a lot of time or knowledge to vandalise websites or use applications as a gateway into the corporate infrastructure.
Legislation aimed at motivating enterprises to secure their web applications has added fuel to the fire. Under the Data Protection Act, for example, companies could be liable to legal action as a result of problems with application security if, unknown to them, they are exposing confidential data.
Organisations must not make the mistake of thinking that this is about phishing or identity fraud: it is about the way web applications are developed. Far too often they are developed without security being considered or given due prominence at the outset.
Building security into the design of applications is not as hard as it sounds. There are documented application architectures that promote security best practices. The real challenge is when the code comes to be written. Application security is not a high priority in application development - functionality and delivery come first.
This cannot continue. Security must be built into the code from the beginning and, by definition, this means that testing for security loopholes becomes a priority also. The emphasis must change from building functionality to building secure functionality.
There are coding techniques that produce functional results, yet offer intruders a way to use the application or the underlying operating system to gain unauthorised access.
One example is that most operating systems offer multiple ways to designate the same logical location in the file system. A developer may write some code that closes a path to that specific location, but this will only block hackers' access if they try to get in using exactly that path. There will be many other paths that they could use. The only way to protect against this type of weakness is to identify all possible routes or paths and protect each of them individually.
Insecure coding practices often creep in when developers are trying to get around persistent errors in applications. For example, often the ValidateRequest attribute of pages at the front end of a web application is set to "false" by a developer, to get around the problem of the page crashing when the validation request is set to "true".
Although by doing this developers do not change the functionality of the application, they introduce a security vulnerability, as intruders can then use data entry fields to try and send commands to the application, database, or operating system, that could allow them access to private corporate data.
These are just a few examples of how coding practices are resulting in insecure web-based applications. There are hundreds of different practices for dozens of different application scenarios that are constantly changing and evolving as hackers become more sophisticated and new vulnerabilities are found. It is impractical to think that developers can keep abreast of all of these, and even if they could, most organisations could not afford to retrain all their developers to write secure code.
However, developers can be armed with tools and processes that enable them to produce better quality code. They should be given tools that check their code against known security errors and that analyse internal calls and data transfers within the application, as well as the operating system and software environment in which it operates.
Improving the quality of code from a security perspective will undoubtedly make your applications more secure. However, you cannot stop there: you also need to test against security loopholes.
It is not unheard of for organisations to bring in professional hackers to test an application by trying to break into it. But this is not always possible from a cost and resource point of view. In addition, this type of activity will prove expensive and is not done over the lifetime of an application. Security vulnerabilities can arise at any point in an application's lifecycle, so organisations need to find ways to continually test for security loopholes.
One way to do this is with automatic attack simulation, where software pretends to attack the application through known paths of intrusion. This software can be updated and re-run on the application across its lifecycle to ensure you are constantly testing your application against known attacks.
Although it is virtually impossible to create a 100% secure application, by changing development and testing practices organisations can significantly reduce the number of security vulnerabilities that exist in many of the applications developed today.
Organisations must sit up and take note, otherwise they will soon find that security holes in their applications affect their ability to do business and could land them in legal hot water.
Sarah Saltzman is technology support manager at software and services company Compuware