Vulnerabilities and weaknesses from industry-recognized indexes including OWASP Top 10, WASC TCv2, and CWE-25 are analyzed to determine which of the protection options are ideal for solving the software security problem. Where changes to internet standards and protocols are required, alternatives in perimeter, framework, or custom code solutions are also provided until the internet-scale solutions are in place. If a solution can be completely implemented in perimeter or infrastructure technologies, only that solution is provided. Similarly, if any part of the solution can be provided in standard or custom frameworks, that solution is not recommended to be implemented in custom code. The guiding principle is essentially: "implement security controls as far from custom code as possible." Only if there is no other way to solve a particular security problem is a custom code solution recommended.

After 20 years of software engineering since the first Internet worm was written to exploit a buffer overflow vulnerability, developers are still building insecure software. It is time for a new approach. The vast majority of software bug classes can be eliminated by building protections into perimeter technologies, platform infrastructures, and application frameworks before a developer even writes a single line of custom code. By allowing developers to focus on just a small subset of bug classes, training and standards programs can be more targeted and effective so developers can write secure code much more efficiently.

The most scalable and effective approach to addressing vulnerability classes is to fix the browsers, standards, and protocols that enable web applications. This approach can sometimes increase security for every application on the internet without changing a single custom application. Less scalable, but almost as effective is to address vulnerabilities in perimeter technologies such as application firewalls, load balancers, geocaching services and proxies.

These technologies can shield vulnerable applications without requiring changes to the applications themselves. The next most scalable approach requires upgrading popular application frameworks so they are robust against common attack classes. Finally, organizations can customize application frameworks to support their own application-specific APIs and security controls that developers can leverage during development instead of having to build the controls in during their daily coding efforts. If none of these options are possible for a given vulnerabillity class, developers will be required to protect against that class in every line of code that they write, which does not scale effectively at all.

Vulnerability/Weakness

Browser/Standards/Internet Technology

Perimeter/Infrastructure

Generic Framework

Custom Framework

Custom Code

Abuse of Functionality

All features should have defined abuse cases and implemented protections against these abuses.

Provide a secure random token generator AND use it to generate session IDs.

Cross-Site Scripting (XSS)

Browser vendors and standards bodies should agree on markup for elements to contain dynamic content (e.g. Flash, JavaScript, HTML, etc.) inline without allowing the dynamic content to perform malicious actions such as navigating the parent window, reading or writing data across trust boundaries, or other undesirable behaviors as determined by the owner of the containing page.

Automatically sanitize any dynamic content before writing it into HTML, XML, or other documents that might be rendered by user agents that execute active content. If dynamic context must include dangerous elements, provide APIs which filter and sanitize potentially dangerous attributes of these elements. Exceptions and attribute configurations should be described by a policy file instead of hard-coded into the framework itself or into function calls.

Cross Site Scripting (XSS) - DOM-Based

"Web 2.0" frameworks must expose an API for page creation/modification that does not use document.write/ln or allow dynamic data to be injected into innerHTML or similar DOM element attributes.

Recognize and dynamically adapt to deliberately slowed connection attempts by dropping slower connections during a detected event. The perimeter should protect itself and the Web server from saturation by slow connections.

Directory Indexing

Disable directory listings in the web- or application-server configuration by default.

Fingerprinting

Infrastructure should not leak any information which can be used to identify the platform or infrastructure technology. Perimeter technologies should strip all such information from outgoing responses.

URL structure should not reveal the underlying technology.

Format String

Alert and/or block on known format string signatures.

Prohibit access to vulnerable APIs and provide safe wrappers of those APIs instead.

Purpose: There are many anthologies of vulnerabilities and weaknesses (including CWE-25, TCv2, and OWASP top 10), but there is no attempt to classify these issues based on how they should best be solved. In the past, we have tried to teach developers how to avoid introducing these problems, but it appears via the lesson of Buffer Overflow that the only way we'll ever eliminate them is to make it impossible for developers to write vulnerable code at all. The periodic table classifies issues based on the most scalable solution, whether that be in frameworks, perimeter technologies, custom code, or fixing the browsers and standards responsible.