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:
- Static Sites
To the server, static sites are just a collection of files. There are general risks to the server, such as denial of service, but there is no significant risk of application coding errors. - Simple Dynamic Sites
Some sites have simple server-side logic, e.g. a store locater, or a guest book. All the information is public, but the server itself needs to be protected. There is a risk, for example, that a coding error could allow a hacker to take control of the server. - Sites with Authentication
Sites where you can login and access a private area have more risks to deal with. As well as protecting the server, the application also needs to protect users' data. There is a risk, for example, that a coding error could allow one user to access another user's data.
Different threats affect sites with different user bases and business functions:
- General Sites
Sites without large user bases, or financial access, are relatively unlikely to be attacked. - High-Profile Sites
Popular sites, such as web mail providers and social networks, are very likely to be attacked if they have even minor vulnerabilities. - High-Value Sites
Sites that have a financial incentive for hackers, e.g. online banking, face even more threats. As well as attacks against the server, users of the application are targeted too. Phishing emails attempt to trick people into revealing login details, while Trojans sit quietly on compromised workstations, waiting for login details to be entered.
How Bad are Things?
From working in the web security world, my experience is:
- Vulnerabilities that allow a server compromise are rare on any kind of site.
- Less serious vulnerabilities are common on general sites, but rarely attacked.
- Vulnerabilities of any kind are rare on high-profile and high-value sites, but they happen.
- Users of high-value sites are often vulnerable, and often attacked.
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:
- Use technologies that promote security.
- Make sure developers are security aware.
- Consider application security testing.
- Consider deploying a web application firewall.
- For high-value sites, provide additional protection for your users.
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:
The OWASP Guide- Authentication and Session Management on the Web - I wrote this paper as part of my GSEC certification.
- Pretty Bad Proxy - this paper gives an excellent insight into how to think about security.
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.
Protecting Users
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.
