Web applications are a target for hackers if not properly secured. There are a number of technical subtleties in correctly securing a web application. Coding errors can lead to vulnerabilities like SQL injection and cross-site scripting. Different risks affect sites with different functions:
Different threats affect sites with different user bases and business functions:
How Bad are Things?
From working in the web security world, my experience is:
In general, operators of high-value and high-profile sites work hard to ensure there are no vulnerabilities in their sites, as any vulnerabilities are likely to be exploited. There have been high-profile cases of social networking worms and web mail viruses, caused by such weaknesses. Operators of high-value sites also generally work hard to protect their users, as it's usually the company that bears the cost of fraud, not the individual.
Operators of general sites have less of an incentive to secure their sites. If they do nothing - a cheap option - they are still unlikely to suffer a serious incident. Some general sites make efforts to be secure anyway. Many only do so when regulations enforce it, e.g. PCI DSS.
How to Secure a Web Application
From a manager's point of view:
This almost makes it sound easy! Sadly, being a web application security specialist, I can't just have the manager's overview. There is a huge amount of detail behind these statements.
Technologies that Promote Security
Older technologies like PHP and ASP are very difficult to use securely. Unless great care is taken, applications are likely to be vulnerable to attacks like cross-site scripting and SQL injection. Newer technologies, such as ASP.Net or Ruby on Rails, take on much more security responsibility, leaving less chance of developer errors.
Developer Security Awareness
Ideally, all programmer education would include a significant amount of security awareness. In practice, not all trained programmers have good security awareness, although this is certainly improving. To have reasonable confidence in a team, all the web developers need basic security knowledge, and there needs to be a security "champion" in the team. Companies that employ developers need to be prepared to allocate time for training, and fund some courses.
Reference information for developers:
Web Application Security Testing
There are two main approaches to testing - black box and code review. For black box testing, the site is accessed in the same was a user would access it, and the test uses similar techniques to those used by hackers. A code review is an offline analysis of the source code. Both techniques require either specialist people or tools, which are generally expensive. Code reviews in particular tend to be time consuming and expensive. While a code review can find more vulnerabilities, black box testing is cheaper, and can find most of the vulnerabilities that are likely to be exploited.
For both kinds of testing there is a choice of manual testing or using automated tools. Manual tests can find more vulnerabilities, as a human can understand the intricacies of each application. I've discovered serious flaws, such as server compromise by a malicious file upload, that an automated tool would not be able to discover. However, you need a specialist to do manual testing. A great advantage of automated tools is the ability for developers to use them, so problems are found early in the development cycle. Both approaches tend to be expensive, although manual testing costs for every test, while once you have a tool, each test is usually free.
I recommend that all commercial sites (apart from purely static sites) have manual black-box testing performed before release, and before major updates. High-profile and high-value sites should also embed automated security tools into the development cycle.
Reference information for testers:
Web Application Firewalls
A Web Application Firewall (WAF) aims to protect a web application even if it has technical vulnerabilities. Requests are analysed for patterns that appear in attacks, and blocked or modified as appropriate. I don't have a great deal of experience with WAFs, but knowing roughly how they work, I believe the moderate vendor claims of blocking most attacks and not interfering with the user experience. One concern I have is that in some cases a skilled attacker could still exploit a vulnerability through the WAF, by carefully crafting the attack to confuse the WAF.
My opinion is that most sites do not need a WAF. Even for high-value sites, if there is confidence in development processes, and security testing is done, a WAF is not necessary.
The idea is to design the site so that even if the user access it from a trojaned system, or is tricked by a phishing email, their account remains secure. A technique used by many high-value sites is multi-factor authentication (MFA). To perform sensitive operations (such as transferring money), the user needs to have a physical device present, as well as their user name and password. Some sites issue a token, while others use a device the user already has, most commonly a mobile phone.
In the medium-term I expect MFA to be very successful at preventing attacks. However, it does not provide complete protection against either phishing or Trojans. Attackers can increase the complexity of their attacks, and still be successful in some circumstances. My opinion is that most high-value sites should implement MFA, and monitor the situation to see if more complex attacks become common.