The dramatic uptake in Web 2.0 usage has seen a massive increase in sites mixing user generated content, live feeds, and interactive content alongside traditional images and text. Only 10 years ago, Facebook and Twitter simply didn't exist.
However, the security implications can be daunting. Many Web 2.0 sites use mash-ups (many different elements and functionality drawn from multiple sources) so there is no means of validating their code. Additionally, as Web 2.0 sites mature and become more dynamic, it's more difficult to identify any "normal" traffic patterns which can be used as a yardstick for setting usage policies or firewall rules, and as a result, sites are vulnerable to attack.
Requires Free Membership to View
Web
application firewalls (WAFs) were developed to counter to these threats. Unlike the traditional
firewall, which protects the entire network, a WAF only secures the Web servers. Sitting between
the Web client and Web server, web application firewalls monitor every request and response within
the application layers. They look for specific "attack signatures" to identify a specific incoming
attack, whilst monitoring for abnormal behaviours that don't fit with past traffic patterns.
Whilst WAFs are fundamental to the security of any Web application, they are only truly effective if configured properly. Most problems result from their poor initial configuration rather than their operation, but a few simple steps can avoid the most common problems:
Coordinating Web application firewall configuration with Web update cycle
This may seem almost too obvious to highlight, but configuring the web application firewall in
parallel with a Web application's update cycle prevents significant problems. The optimum time to
configure a web application firewall is when the website is being updated or patches are
implemented. If the two operations don't happen at the same time, there's a strong
likelihood that part -- or all -- of the application will not be protected. In this case, the WAF
will identify part of the application as a rogue element and block it. The consequence can be
severe for the site's users, who experience problems such as news feeds dropping out, message posts
not uploading and content being inaccessible.
Check third-party code for bugs/vulnerabilities
Mash-ups, feeds and/or aggregators are the essence of Web 2.0, but if they harbour vulnerabilities,
they put the whole Web infrastructure at risk from attack. Placing a WAF in front of a site will
protect it, but for 100% peace of mind, a secure application vulnerability check (before you
implement it) is the way forward. This kind of assessment gives detailed information about what is
going to affect the site -- before it happens.
There are several assessment tools available, some proprietary and some not. Whilst they all scan for vulnerabilities, the most suitable one will probably be determined by its compatibility with the web application firewall that's installed. Assessment tools are available in manual and automated versions: The manual ones are conducted by external organisations or consultants and meet PCI DSS requirements, whilst automated assessments are handled by external scanning software. For real peace of mind, it's sensible to run both manual and automated testing tools. It's also worth feeding back the results of the vulnerability check to vendors; they like to know if/where they need to make changes. It costs nothing and helps everyone avoid the same pitfalls.
Use a web application firewall with built-in acceleration
IT departments often worry that WAFs mean latency and impact on users' experience and productivity.
If this is an issue, opt for a WAF with a built-in acceleration feature, which mitigates Web
latency and speeds overall traffic.
Lock the back door -- as well as the front!
By using WAFs to protect the front door, or the applications, IT departments often neglect the back
door, which includes the protection of databases and back-end applications. If the WAF misses
something, then the whole site is vulnerable. Securing both ends can be achieved with a database
activity monitoring product, a proper Web application firewall configuration and vulnerability
assessment at the outset.
It may sound costly and a bit excessive, but an all encompassing option will highlight all the issues which need to be addressed before they can cause real damage. The costs involved are negligible compared with the financial, operational and reputation costs of a major Web incident.
In the U.S., this "belt and braces" approach to Web security is widespread, which may be due to more exposure to website fraud or simply a more stringent compliance regime. Over the next couple of years, it is likely that the U.K. will follow a similar path, in no small part spurred on by news such as the recent Web Hacking Incidents Data Report, which showed a sharp rise in Web hacking incidents for social networking sites such as Twitter posts. These accounted for 19% of all Web hacking incidents from January to July 2009, and the trend looks set to continue for the foreseeable future.
The statistic is a stark indication that WAFs and wide-ranging Web security assessments need to move from the IT department's 'wish list' to being seen as necessities in a Web 2.0-dominated world.
About the author:
Nick Garlick is managing director of Nebulas Security Solutions Group. Send Nick your comments and security questions.
Email Alerts
This was first published in December 2009
