How to reduce WEB 2.0 attack surface by going back to WEB 1.0, the dynamic way!

Overview

The arrival of WEB 2.0 brought dynamic content through the use of technologies such as Java, Flash, and PHP. Consequently, it also widened the attack surface. Websites became prettier, more interactive, easier to update, and also easier to attack! The need for further functionality was, as it is often the case, at the cost of security.

Architecture Comparison

The four diagrams below illustrate the differences between a WEB 1.0 and a WEB 2.0 architecture as well as highlighting the increased attack surface.

WEB 1.0 Typical Architecture

In a typical WEB 1.0 architecture, besides the physical, human, and network security considerations, protecting the data depends on the Operating System and the application security layers. Typically, the application security layer is restricted to the Web Server (i.e.: Apache) if no other services/applications are exposed to the Internet.

WEB 2.0 Typical Architecture

A WEB 2.0 Architecture introduces a number of extra applications which may be directly exposed to the Internet or through a Web Server. Those extra applications will provide the interface to dynamically display and manipulate the data.

WEB 2.0 Extended Architecture

For larger and more complex WEB 2.0 websites, those applications may not all be located on one server and instead rely on remote/centralised storage locations as well as using more advanced data frameworks such as databases.

WEB 2.0 Increased Attack Vectors

Those extra applications and servers/locations also introduce extra attack vectors as they increase the chances of misconfiguration, bugs, back doors, entry points, complexity, etc.

Considerations

The problem is that not all websites need to generate dynamic content on demand; in fact, most websites could happily be static/WEB 1.0. The reason why almost all current websites use technologies such as PHP or FLASH is that nearly all website creation frameworks now only offer WEB 2.0 backend.

WordPress, for example, provides an easy and user-friendly experience to create great looking websites with little IT knowledge, yet it is using PHP and is consistently peppered with security alerts and issues. The appeal for using WordPress was originally for creating blogs, where as new posts get added, the website is dynamically updated to display the newest articles first, while archiving older ones and grouping the posts by categories.

Issues with Dynamic Solutions

There are two issues with this type of solution:

  1. As the website and its content grow, dynamically creating content on demand requires an increasing amount of server resources. Although there are techniques to optimize such requests, a dynamic website will always consume more resources than one only serving static webpages. This will eventually result in slow page loading or time-out errors.
  2. Websites that have no main purpose related to blogs still use such software to dynamically generate what is in fact static content, because those applications have become the default web creation packages provided by many web hosting providers.

From a security and performance point of view, it makes more sense to host a static website and reduce the number of applications being used to produce the webpages. This way, one only has to secure the Operating System and the web server application (singular, not plural).

Static Website Example

A live example of what can be done with a WEB 1.0 website in a WEB 2.0 world is this website. It is entirely static as far as visitors are concerned. Yet, every time a post is published, the categories, pages index, RSS, etc. are all dynamically generated… once! Only once when the new post is published, as opposed to every time a visitor accesses the page, which is the case in a typical WEB 2.0 website.

To achieve this, a script was created that runs on a laptop when a new post is published and dynamically updates the website with all the changes. If happy with the content, the changes are then uploaded to the web server.

Conclusion

The key message is that before creating or publishing a website, you should really consider if you need all the bloating of a dynamic WEB 2.0 framework and all the security issues that come with it. Move any power-crunching, resource-consuming, dynamic activities offline, far away from the claws of the Internet. This approach might solve your backup, security, and performance issues in the process.