To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
The risks you mention have been around a long time, but they're still providing hackers with plenty of opportunities to successfully access data or take control of a compromised machine.
Standard advice for Web application developers is to test application code prior to deployment and promptly patch it as soon as new flaws are reported. But this is no longer enough, as today's attackers are more thorough in how they seek out vulnerable websites. Hackers use a variety of toolkits to speed up the exploitation process, and recent attacks show that vulnerabilities are now more likely to be uncovered and exploited maliciously.
To reduce the chances of your application falling victim to an attack, it's essential that any Web application development is undertaken using a "security development lifecycle" approach. The aim of the security development lifecycle is to reduce the number of security-related design and coding defects, and to reduce the severity of any defects that do remain undetected.
As part of this process, you should incorporate threat modeling. Performed during the application design stage, threat modeling identifies and evaluates the risks to an application. In order to identify potential threats to the application, assets must be categorized, along with sensitive information that the application accesses. Threat modeling not only raises security awareness among developers, but also makes security an integral part of the application design and development process. By having security professionals and developers work together, it's easier to analyze an application from an attacker's point of view. For more help, download Microsoft's free Threat Modeling Tool.
On larger projects, consider automatic source code-scanning tools and Web vulnerability scanners. A good Web vulnerability scanner will spot common technical vulnerabilities, such as SQL injection flaws, cross-site scripting vulnerabilities, parameter tampering, hidden field manipulation, backdoors, debug options and buffer overflows. Custom application code, however, will still need manual reviewing, particularly if it uses Ajax. Ajax increases the possible permutations of user and service interaction, which makes automated testing difficult, since scanners can only process syntactic information. Until scanners can harness true artificial intelligence and put the anomalies into context or make normative judgments about them, they will struggle to find certain types of vulnerabilities.
For applications that use open source components, be aware of the emerging threat of cross-build injection, in which attackers insert malicious code into applications even as they are being built. The attack is a good example of how malicious hackers look at every aspect of the application development and deployment lifecycle to find where they can take advantage of weaknesses to plant their code.
The end result of Web applications built using security development lifecycle methodology will be a reduction in the number of vulnerabilities that make it through to the release version. Since the cost of fixing vulnerabilities in a live production environment is so much higher than addressing them during development, a security development lifecycle helps to create better products, increase customer confidence in your applications, and benefit the bottom line.
Having spent time ensuring your Web application is robust, you still need to conduct penetration tests to ensure that your Web server and database server have been hardened and are well-protected, too. By simulating an attack, you can evaluate whether your Web application has any potential vulnerabilities resulting from poor or improper system configuration, hardware or software flaws or weaknesses in the perimeter defenses protecting the site. Finally I recommend reading the Open Source Security Testing Methodology Manual. The free guide provides a recognized methodology for performing security tests and measuring the results.
More information:
In 2008, one SQL injection attack infected hundreds of thousands of websites.
See which new tactics can prevent cross-site scripting attacks.
|
