OWASP Periodic Table of Vulnerabilities

= Main =

After 20 years of software engineering since the first Internet worm was written to exploit a buffer overflow vulnerability, web 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.

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.

= Periodic Table of Vulnerabilities =

= Solution Detail =

Browser / Standards Solution
None

Perimeter Solution
Perimeter technologies including geocaching/proxy services must support automatic and/or manual "panic button" anti-automation, enforcing progressive CAPTCHA for unvalidated requests, triggering on excessive 5XX responses, or direct signal from application.

Complexity: High Impact: Medium

Generic Framework Solution
Provide configurable per-user/session request rate limits. For authenticated transactions, limits should be configurable on a per-user or per-session basis. Configuration should allow combining multiple limits of the form "# of requests per time period". For example, an administrator should be combine "10 requests per minute" with "500 requests per day" in order to simultaneously apply policies which prevent users from automatic crawling/screen scraping as well as longer-term slow leeching activities.

Complexity: Low Impact: High

Custom Framework Solution
Provide a common configuration functionality available to any feature/function. Configuration settings should allow multiple per-user rate limits as well as global rate limits to prevent denial of service.

Complexity: Low Impact: High

Custom Code Solution
Any feature sensitive to high transaction rates should expose configurable rate limits per user or globally per feature.

Complexity: Low Impact: High

Discussion / Controversy
Generic framework solution requires too much overhead to track request limits. Request rate limiting should be done in perimeter, not framework. Should combine with Denial of Service (Application-Based)? Custom Code solution is the same as Custom Framework Solution; Custom Code solution should be pushed into framework.