This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

Difference between revisions of "OWASP Periodic Table of Vulnerabilities"

From OWASP

Jump to: navigation, search

Latest revision as of 05:42, 13 February 2016

Main
Periodic Table of Vulnerabilities
Release Formats
Project About

Introduction

After 25 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 making changes to protocols and standards and 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, enabling developers to write secure code much more efficiently.

Vulnerabilities and weaknesses from industry-recognized indexes including OWASP Top 10, WASC TCv2, and CWE-25 are analyzed to determine which of the remediation strategies 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.

Browsers, Standards, and Protocols

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 line of application code. The amount of industry collaboration required to implement a protocol/standard change can be enormous, but some classes of vulnerabilities simply cannot be addressed without this kind of change (e.g. Clickjacking). A solution at this level is incredibly powerful: a Content Security Policy (CSP) solution to Cross-Site Scripting (XSS) might allow most application owners to write a simple policy file instead of implementing a costly framework or custom code solution to protect their existing application assets.

Perimeter / Platform Technologies

Less scalable, but almost as effective, is to address vulnerabilities in perimeter technologies such as application firewalls, load balancers, geocaching services (e.g. Akamai), and proxies. These technologies can shield vulnerable applications without requiring changes to the applications themselves. While most classes of vulnerability depend heavily on the application code and aren't easily solved by a generic perimeter solution, some are generalizable to the point where a perimeter solution could protect any application behind it before an attack even has a chance to do damage. Anti-automation and protocol validation are especially good solutions for perimeter technologies to address.

Similarly, some vulnerability classes should be addressed in platform technologies such as web servers, application servers, and operating systems. Often these technologies are responsible for exposing the vulnerability in the first place, and must be responsible for providing the solution.

Generic Application Frameworks

The next most scalable approach requires upgrading popular application frameworks so they are robust against common attack classes. Platforms such as Java Struts/J2EE, Ruby on Rails, and PHP can theoretically prevent developers from introducing most classes of vulnerability in the first place. However, the current state of the framework industry is a result of being more driven by features than by security; any conflict between the two is usually decided in favor of adding features and ease of use, as opposed to difficult-to-use security enhancements. Some frameworks even have built-in vulnerabilities out of the box!

Improvements to application frameworks won't immediately help protect existing applications (though they would make any new applications built on the platform much safer). Many applications currently rely on insecure features of their frameworks that would be eliminated or refactored when the framework is secured. Existing applications would need to follow an upgrade path provided by a "secure" branch of existing frameworks before these solutions could take effect. Many applications don't even use popular frameworks at all, and so could never be helped by improvements to common development platforms.

Generic Framework solution guidelines would, however, help application owners prioritize refactoring efforts for their existing applications in order to make their application code more robust against future development mistakes. This is true whether their applications use popular frameworks or not. Implementing a robust solution to a vulnerability class is much more cost-effective in the long run than training every developer to understand every vulnerability and continuously patching new instances of the vulnerability each time they appear. Cross-Site Scripting is a classic example of the "whac-a-mole vulnerability" that recurrently wastes developer time and attention and could be solved more holistically with a framework wrapper. Application owners can pattern their security refactoring efforts against the recommended solutions for Generic Frameworks in order to completely eliminate the same classes of vulnerabilities from their existing applications, even if they can't easily port their applications to a framework which has already addressed those vulnerabilities.

Custom Application Frameworks

Some vulnerabilities are unique to a specific application and can't be solved by a generic framework solution. For example, a generic framework might ship with a Social Security Number (SSN) validator, but a custom framework solution would be needed for a CustomWidgetItem validator. The SSN data type is well-defined and not unique to a specific application or business, but the CustomWidgetItem is unique to that application and has its own validation rules.

Organizations should still customize application frameworks to support their own application-specific APIs and security controls. Developers can leverage these controls during development instead of having to build the controls in during their daily coding efforts. If developers use a CustomWidgetItem object that has already been validated by framework code, it is much more likely that they will use it safely than if they have to remember to do their own validation each time they use the object. By addressing the vulnerability once with a single framework customization, the application owner can protect all future development from introducing the vulnerability into new code.

Custom Code

If none of the other solution options are possible for a given vulnerability class (or the solution still requires the developer to do something in order to leverage a framework feature), developers will be required to think about how to protect against that class in every line of code that they write. This is the least scalable of all of the solution models, which explains why current efforts to educate developers about all vulnerability classes hasn't resulted in secure software. Some classes of attacks, such as Abuse of Functionality, depend completely on the custom code and business logic of the application and cannot be abstracted at all into other solution models.

The set of vulnerabilities which must be eliminated in custom code is only a small fraction of the total vulnerability space. By focusing training and testing efforts on just this set of issues, after addressing all other problems in a more scalable manner, developers have a much better chance of building secure applications in the future.

VULNERABILITY		LOCATION OF SECURITY CONTROL
VULNERABILITY		Standards	Infrastructure/Perimeter	Generic Framework	Custom Framework	Custom Code
Abuse of Functionality	AF					All features should have defined abuse cases and implemented protections against these abuses.
Application Misconfiguration	AM		Ensure proper application settings are deployed in configuration file/s. Varies by platform and technology stack.
Brute Force (Generic) / Insufficient Anti-automation	BF		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.	Provide configurable per-user/session request rate limits.	Provide a common configurable anti-automation framework available to any feature.	Any feature sensitive to high transaction rates should expose configurable rate limits per user or globally per feature.
Brute Force Login	BL		Provide capabilities to detect brute force attacks and help enforce lockout or CAPTCHA based on signals from the application.	Provide configurable progressive lockout/delay for failed authentication requests to a single account and detection/alerting for fixed-password variable-username attacks. Provide configurable CAPTCHA enforcement.
Brute Force Session Identifier	BI	Define a new standard for transmitting session information.		Detect and alert on a configurable rate of session ID cache misses. Provide configurable session lockout if source IP for a session changes during an event. Ensure that token generation is secure, random, and from a sufficiently large key space.
Brute Force Predictable Resource Location/Insecure Indexing	BP		Generic anti-automation response should trigger during spikes in 4XX responses.	Provide a configurable GUID-based obfuscator for sensitive parameter values. Do not expose administrative interfaces on the same path as user interfaces.	Require authentication wherever possible. Create independent interfaces for administrative access and enforce stricter authentication rules.
Buffer Overflow	BO		Defend infrastructure from known exploit signatures (e.g. CodeRed) and alert/block parameter anomalies.	Build on a memory-managed code platform or otherwise prohibit direct memory management.
Clickjacking	CJ	Browser vendors should standardize on CSP directives to support safe framing options for framed sites.		Support configurable options for setting X-Frame-Options header and automatically embedding framebusting code in HTML/Script/CSS for older user agents that do not support XFO.
Content Spoofing	CS	Provide a new response status code for "File not found, but show custom 404 content body AND replace the URL displayed in the title bar because the current requested URL will confuse users".			If the framework supports user-supplied content, such content must be clearly marked as such in the display context.
Cookie Theft/Session Hijacking	SH	Define a new standard for transmitting session information to replace cookies.	Terminate/regenerate session if the session token is transmitted insecurely. Help enforce cookie/session management rules.	Prevent leakage of session tokens with strict cookie parameters and other rules. Detect evidence of successful hijack to proactively terminate compromised sessions. Rotate the session token as often as possible.
Cross-Site Request Forgery	XF	Change default browser behavior to look for policy file for cross-domain writes instead of "default allow", transitioning through CSP framework.		Automatically generate and check tokens for all POST requests by default, with configuration-based exclusion list. Disallow state changes via GET requests, enforcing RFC.
Cross-Site Scripting (XSS)	XS	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 content 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	XD			"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.
Denial of Service (Application Based)	DA		See Brute Force (Generic)			Profile resource-dependent transactions and build transaction queues and alerting when queues reach thresholds. Enforce transaction-based rate limits.
Denial of Service (Connection Based)	DS		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	DI		Disable directory listings in the web- or application-server configuration by default.
Fingerprinting	FP		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. Default content should be removed when possible. Tools that assist development or debugging should not be hosted or accessible.
Format String	FS		Alert and/or block on known format string signatures.	Prohibit access to vulnerable APIs and provide safe wrappers of those APIs instead.
HTTP Request/Response Smuggling	RG	Tighten RFC standards to describe precise behavior for malformed request/response data. Increase SSL adoption to prevent proxy tampering.	Enforce strict parity match between requests and responses, discarding extraneous Content-Length headers and canonicalizing requests/responses.
HTTP Response Splitting	RS			Automatically URL-encode CRLF characters in dynamic data before writing to HTTP response headers.
Implicit Logout	IG	Define a new standard for handling sessions. Define CSP or other standard for triggering a logout flow when user browses away from a site. At least destroy session cookies.		Detect when a user browses away from the site and automatically log the user out of the application.
Improper Filesystem Permissions	IF		Ensure that proper file and directory permissions are applied. Enforce stricter default permissions.
Improper Input Handling	IH			Provide canonicalization and positive validation APIs for common data and file types, with configurable rules to reject or sanitize bad data.	Provide canonicalization and positive validation APIs for custom data and file types, strictly enforcing business rules, with configurable rules to reject or sanitize bad data.	Never use primitives in custom code.
Improper Output Handling	OH			Provide context-sensitive encoders for all common data types in all output contexts, ensuring no custom code can write directly to output.	Provide context-sensitive encoders for all custom data types in all output contexts, ensuring no custom code can write directly to output.
Information Leakage	IL		Alert, block, or sanitize classified data in responses. Automatically scrub HTML, JavaScript, CSS, and other data formats of comment data and stack traces. Configure platform to return generic error codes by default and log locally.	Provide common error-handling framework and APIs which take two error messages as parameters: one to be displayed to the user and one to be written to logs. Provide configurable content expiration/caching interface; default to no-cache, no-store.		Don't leak information via error parity mismatches.
Insufficient Authentication/Authorization	IA			Provide configuration-based authentication and authorization platform.		Apply least-privilege principle to all transactions, requiring authentication and authorization where applicable.
Insufficient Data Protection	ID			Provide a configuration-based suite of encryption utilities for all data security needs including HMAC, symmetric, password hash, and asymmetric encryption requirements.
Insufficient Password Recovery	IR			Provide generic credential recovery with configurable "secret question" and multi-factor side-channel authentication functionality (e.g. SMS, email, etc.).
Insufficient Process Validation	IP			Require state validation rules to be specified for multi-step flows.		Enforce state validation for asynchronous transactions.
Insufficient Session Expiration	IS	Define a new standard for instructing the browser about session timeouts and how to handle them.		Provide and enforce configurable absolute and inactivity-based session timeouts.
Insufficient Transport Layer Protection	IT	Fix DNS and browser technologies so that the intent of domain owners can be more strictly followed.	Enforce Strict Transport Security and redirect any HTTP request to HTTPS.
Integer Overflow/Underflow	IO			Provide safe wrappers for primitive numeric types.		Never use primitives without strict checking for underflow/overflow conditions.
LDAP Injection	LI			Provide safe libraries for LDAP communication which properly encode dynamic data.
Mail Command Injection	MI			Provide safe libraries for SMTP and IMAP interaction that properly encode dynamic data.
Null Byte Injection	NB		Alert and/or block on known null byte attacks.	Provide safe libraries that automatically encode dynamic data in any context which uses null bytes as control characters.
OS Commanding	OC				Build safe wrappers for system calls which prevent dynamic data from changing the intended meaning of the call.
Path Traversal	PT		Canonicalize URLs and prevent directory access outside the web root.	Provide safe libraries for accessing the file system which canonicalize path references and enforce proper access control.
Race Conditions	RC			Prevent singletons from instantiating class-scope objects. Provide transaction integrity for task queues.
Remote File Inclusion	RF	Define a standard for safe inclusion of 3rd-party code and content which enforces namespace separation and mediates namespace/DOM access.		Provide proxy library to sanitize/sandbox third-party code and content for safe inclusion (e.g. Caja).
Routing Detour	RD			Provide configuration-based whitelist for WS Routing destinations.
Server Misconfiguration	SM		Ensure proper application settings are deployed in configuration file/s. Provide secure default settings.
Session Fixation	SF			Do not create sessions using session IDs generated by the HTTP client. Expire and rotate session IDs whenever the privilege level associated with a session changes.
SOAP Array Abuse, XML Attribute Blowup, XML Entity Expansion	SA		Perform schema validation of XML structure on incoming requests.
SQL Injection	SI			Provide safe libraries for communicating with SQL servers which enforce parameterized query patterns.		Do not create queries with dynamic data in stored procedures.
SSI Injection	SS			Do not support SSI with dynamic file names.
URL Redirector Abuse	UR			Provide configurable white list for redirection URLs in 3XX responses, Refresh headers, and JavaScript redirects.
Weak HTTP Authentication Methods	WA	Define a new, safe standard for HTTP-based authentication.	Reject HTTP Basic Auth, NTLM, and Digest Authentication requests. Block or proxy inline 3rd-party content.	Block or proxy inline 3rd-party content.
XML External Entities	XE			Disable External Entities within the XML parser. Enforce strict, static, internal DTDs.
XML Injection	XI			Provide safe libraries for constructing XML documents which automatically encode dynamic data.
XPath/XQuery Injection	XP			Provide safe libraries for constructing XPath queries with dynamic data. Provide safe libraries for XQuery construction which parameterize query values.

Compressed view - One-pager that highlights the vulnerability classes that developers will still have to worry about at the top, with "solved" vulnerabilities ordered toward the bottom.
Infographic - Cartoony, visually-appealing storyboard introduction of the project, its goals, and high-level approach.
Working View/Summary - Working view summarizes solutions in respective columns for quick reference but doesn't provide details. Links directly to detailed sections.
Solution Detail (see linked issues on summary view) - Detailed view combines references, detailed solution designs, discussion/controversy detail, and other relevant information for each solution recommendation. The detail view does NOT explain what each vulnerability/weakness is - it only references existing vulnerability descriptions from other projects (e.g. OWASP Top 10, WASC TCv2, CWE, etc.). A short summary of root cause(s) is included, but only to the level of depth required to suggest all of the solution design elements that need to be addressed.
Solution Checklist - Summary of solutions grouped by target (e.g. perimeter or framework) so that maintainers of standards, frameworks, and perimeter technologies can view the solutions required for their areas ONLY. May require templating to generate list automatically, or short summaries in place of detailed descriptions.
Periodic Table Interactive View - Minimal representation of the Periodic Table View combined with a legend mapping each symbol to the vulnerability name, related taxonomies, and solution targets. Rolling over each element gives solution highlights. Clicking an element opens the corresponding Solution Detail view.
Periodic Table Poster-Size View - Vulns/Weaknesses laid out like the table of chemical elements, with solution target along the top and some measure of severity progressing down through the "periods". Top 10 could be highlighted in some way. Issues may show up in multiple periods. Poster-size so we can get all the relevant information in each "element".
Periodic Table Compact View - Minimal representation of the Periodic Table View combined with a legend mapping each symbol to the vulnerability name, related taxonomies, and solution targets. View is designed to fit on a single US Letter size piece of paper, printed in grayscale.

PROJECT INFO
What does this OWASP project offer you?

RELEASE(S) INFO
What releases are available for this project?

what	is this project?
Name: OWASP_Periodic_Table_of_Vulnerabilities (home page)
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.
License: Creative Commons Attribution ShareAlike 3.0 License
who	is working on this project?
Project Leader(s): James Landis @
Project Contributor(s): David Fern Peter Mosmans Jim Manico Venkatesh Jagannathan Rajat Bhargava Bil Corry
how	can you learn more?
Project Pamphlet: Not Yet Created
Project Presentation:
Mailing list: Mailing List Archives
Project Roadmap: View
Key Contacts
Contact James Landis @ to contribute to this project Contact James Landis @ to review or sponsor this project

current release
Not Yet Published
last reviewed release
Not Yet Reviewed

other releases

This project is part of the OWASP Builders community.
Feel free to browse other projects within the Defenders, Builders, and Breakers communities.

Retrieved from "https://wiki.owasp.org/index.php?title=OWASP_Periodic_Table_of_Vulnerabilities&oldid=208776"

Categories:

@@ Line 1: / Line 1: @@
 = Main =
+<!-- DO NOT ALTER OR REMOVE THE TEXT ON NEXT LINE -->
+<div style="width:100%;height:100px;border:0,margin:0;overflow: hidden;">[[Image:OWASP Inactive Banner.jpg|800px| link=https://www.owasp.org/index.php/OWASP_Project_Stages#tab=Inactive_Projects]] </div>
+== Introduction ==
-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 25 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 making changes to protocols and standards and 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, enabling developers to write secure code much more efficiently.
-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.
+Vulnerabilities and weaknesses from industry-recognized indexes including OWASP Top 10, WASC TCv2, and CWE-25 are analyzed to determine which of the remediation strategies 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.
-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.
+== Browsers, Standards, and Protocols ==
-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.
+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 line of application code. The amount of industry collaboration required to implement a protocol/standard change can be enormous, but some classes of vulnerabilities simply cannot be addressed without this kind of change (e.g. Clickjacking). A solution at this level is incredibly powerful: a Content Security Policy (CSP) solution to Cross-Site Scripting (XSS) might allow most application owners to write a simple policy file instead of implementing a costly framework or custom code solution to protect their existing application assets.
-= Project About =
+== Perimeter / Platform Technologies ==
+Less scalable, but almost as effective, is to address vulnerabilities in perimeter technologies such as application firewalls, load balancers, geocaching services (e.g. Akamai), and proxies. These technologies can shield vulnerable applications without requiring changes to the applications themselves. While most classes of vulnerability depend heavily on the application code and aren't easily solved by a generic perimeter solution, some are generalizable to the point where a perimeter solution could protect any application behind it before an attack even has a chance to do damage. Anti-automation and protocol validation are especially good solutions for perimeter technologies to address.
+Similarly, some vulnerability classes should be addressed in platform technologies such as web servers, application servers, and operating systems. Often these technologies are responsible for exposing the vulnerability in the first place, and must be responsible for providing the solution.
+== Generic Application Frameworks ==
+The next most scalable approach requires upgrading popular application frameworks so they are robust against common attack classes. Platforms such as Java Struts/J2EE, Ruby on Rails, and PHP can theoretically prevent developers from introducing most classes of vulnerability in the first place. However, the current state of the framework industry is a result of being more driven by features than by security; any conflict between the two is usually decided in favor of adding features and ease of use, as opposed to difficult-to-use security enhancements. Some frameworks even have built-in vulnerabilities out of the box!
+Improvements to application frameworks won't immediately help protect existing applications (though they would make any new applications built on the platform much safer). Many applications currently rely on insecure features of their frameworks that would be eliminated or refactored when the framework is secured. Existing applications would need to follow an upgrade path provided by a "secure" branch of existing frameworks before these solutions could take effect. Many applications don't even use popular frameworks at all, and so could never be helped by improvements to common development platforms.
+Generic Framework solution guidelines would, however, help application owners prioritize refactoring efforts for their existing applications in order to make their application code more robust against future development mistakes. This is true whether their applications use popular frameworks or not. Implementing a robust solution to a vulnerability class is much more cost-effective in the long run than training every developer to understand every vulnerability and continuously patching new instances of the vulnerability each time they appear. Cross-Site Scripting is a classic example of the "whac-a-mole vulnerability" that recurrently wastes developer time and attention and could be solved more holistically with a framework wrapper. Application owners can pattern their security refactoring efforts against the recommended solutions for Generic Frameworks in order to completely eliminate the same classes of vulnerabilities from their existing applications, even if they can't easily port their applications to a framework which has already addressed those vulnerabilities.
+== Custom Application Frameworks ==
+Some vulnerabilities are unique to a specific application and can't be solved by a generic framework solution. For example, a generic framework might ship with a Social Security Number (SSN) validator, but a custom framework solution would be needed for a CustomWidgetItem validator. The SSN data type is well-defined and not unique to a specific application or business, but the CustomWidgetItem is unique to that application and has its own validation rules.
+Organizations should still customize application frameworks to support their own application-specific APIs and security controls. Developers can leverage these controls during development instead of having to build the controls in during their daily coding efforts. If developers use a CustomWidgetItem object that has already been validated by framework code, it is much more likely that they will use it safely than if they have to remember to do their own validation each time they use the object. By addressing the vulnerability once with a single framework customization, the application owner can protect all future development from introducing the vulnerability into new code.
+== Custom Code ==
+If none of the other solution options are possible for a given vulnerability class (or the solution still requires the developer to do something in order to leverage a framework feature), developers will be required to think about how to protect against that class in every line of code that they write. This is the least scalable of all of the solution models, which explains why current efforts to educate developers about all vulnerability classes hasn't resulted in secure software. Some classes of attacks, such as Abuse of Functionality, depend completely on the custom code and business logic of the application and cannot be abstracted at all into other solution models.
+The set of vulnerabilities which must be eliminated in custom code is only a small fraction of the total vulnerability space. By focusing training and testing efforts on just this set of issues, after addressing all other problems in a more scalable manner, developers have a much better chance of building secure applications in the future.
+= Periodic Table of Vulnerabilities =
+{|class="wikitable"
+! rowspan="2" colspan="2" align="center" style="background:#D8D8D8; border-width:3px 1px 3px 3px;"| '''VULNERABILITY'''
+! colspan="5" align="center" style="background:#D8D8D8; border-width:3px 3px 1px 1px;"|'''LOCATION OF SECURITY CONTROL'''
+|-
+! align="center" style="background:#D8D8D8; border-width:1px 1px 3px 1px;"|'''Standards'''
+! align="center" style="background:#D8D8D8; border-width:1px 1px 3px 1px;"|'''Infrastructure/Perimeter'''
+! align="center" style="background:#D8D8D8; border-width:1px 1px 3px 1px;"|'''Generic Framework'''
+! align="center" style="background:#D8D8D8; border-width:1px 1px 3px 1px;"|'''Custom Framework'''
+! align="center" style="background:#D8D8D8; border-width:1px 3px 3px 1px;"|'''Custom Code'''
+|-
+| width="11%" style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Abuse of Functionality|Abuse of Functionality]]'''|| width="4%" align="center" style="background:#f0f0f0; border-width:3px 1px 2px 1px;" | AF || width="17%" style="border-width:3px 1px 2px 1px;" | || width="17%" style="border-width:3px 1px 2px 1px;" | || width="17%" style="border-width:3px 1px 2px 1px;" | || width="17%" style="border-width:3px 1px 2px 1px;" | || width="17%" style="border-width:3px 3px 2px 1px;" | All features should have defined abuse cases and implemented protections against these abuses.
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Application Misconfiguration|Application Misconfiguration]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | AM || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Ensure proper application settings are deployed in configuration file/s. Varies by platform and technology stack.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | ||style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Brute Force (Generic) / Insufficient Anti-automation|Brute Force (Generic) / Insufficient Anti-automation]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | BF || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | 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.|| style="border-width:2px 1px 2px 1px;" | Provide configurable per-user/session request rate limits.|| style="border-width:2px 1px 2px 1px;" | Provide a common configurable anti-automation framework available to any feature.|| style="border-width:2px 3px 2px 1px;" | Any feature sensitive to high transaction rates should expose configurable rate limits per user or globally per feature.
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Brute Force Login|Brute Force Login]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | BL || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Provide capabilities to detect brute force attacks and help enforce lockout or CAPTCHA based on signals from the application.|| style="border-width:2px 1px 2px 1px;" | Provide configurable progressive lockout/delay for failed authentication requests to a single account and detection/alerting for fixed-password variable-username attacks. Provide configurable CAPTCHA enforcement.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Brute Force Session Identifier|Brute Force Session Identifier]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | BI || style="border-width:2px 1px 2px 1px;" | Define a new standard for transmitting session information.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Detect and alert on a configurable rate of session ID cache misses. Provide configurable session lockout if source IP for a session changes during an event. Ensure that token generation is secure, random, and from a sufficiently large key space.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Brute Force Predictable Resource Location/Insecure Indexing|Brute Force Predictable Resource Location/Insecure Indexing]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | BP || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Generic anti-automation response should trigger during spikes in 4XX responses.|| style="border-width:2px 1px 2px 1px;" | Provide a configurable GUID-based obfuscator for sensitive parameter values. Do not expose administrative interfaces on the same path as user interfaces.|| style="border-width:2px 1px 2px 1px;" | Require authentication wherever possible. Create independent interfaces for administrative access and enforce stricter authentication rules.|| style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Buffer Overflow|Buffer Overflow]]'''|| align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | BO || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Defend infrastructure from known exploit signatures (e.g. CodeRed) and alert/block parameter anomalies.|| style="border-width:2px 1px 2px 1px;" | Build on a memory-managed code platform or otherwise prohibit direct memory management.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Clickjacking|Clickjacking]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | CJ || style="border-width:2px 1px 2px 1px;" | Browser vendors should standardize on CSP directives to support safe framing options for framed sites.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Support configurable options for setting X-Frame-Options header and automatically embedding framebusting code in HTML/Script/CSS for older user agents that do not support XFO.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Content Spoofing|Content Spoofing]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | CS || style="border-width:2px 1px 2px 1px;" | Provide a new response status code for "File not found, but show custom 404 content body AND replace the URL displayed in the title bar because the current requested URL will confuse users".|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | If the framework supports user-supplied content, such content must be clearly marked as such in the display context.|| style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Cookie Theft/Session Hijacking|Cookie Theft/Session Hijacking]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | SH || style="border-width:2px 1px 2px 1px;" | Define a new standard for transmitting session information to replace cookies.|| style="border-width:2px 1px 2px 1px;" | Terminate/regenerate session if the session token is transmitted insecurely. Help enforce cookie/session management rules.|| style="border-width:2px 1px 2px 1px;" | Prevent leakage of session tokens with strict cookie parameters and other rules. Detect evidence of successful hijack to proactively terminate compromised sessions. Rotate the session token as often as possible.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Cross-Site Request Forgery|Cross-Site Request Forgery]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | XF || style="border-width:2px 1px 2px 1px;" | Change default browser behavior to look for policy file for cross-domain writes instead of "default allow", transitioning through CSP framework.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Automatically generate and check tokens for all POST requests by default, with configuration-based exclusion list. Disallow state changes via GET requests, enforcing RFC.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Cross-Site Scripting (XSS)|Cross-Site Scripting (XSS)]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | XS || style="border-width:2px 1px 2px 1px;" | 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.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | 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 content 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. || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Cross-Site Scripting (XSS) - DOM-Based|Cross-Site Scripting (XSS) - DOM-Based]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | XD || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | "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.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Denial of Service (Application Based)|Denial of Service (Application Based)]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | DA || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | See Brute Force (Generic)|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" | Profile resource-dependent transactions and build transaction queues and alerting when queues reach thresholds. Enforce transaction-based rate limits.
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Denial of Service (Connection Based)|Denial of Service (Connection Based)]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | DS || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | 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.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Directory Indexing|Directory Indexing]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | DI || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Disable directory listings in the web- or application-server configuration by default.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Fingerprinting|Fingerprinting]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | FP || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | 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.|| style="border-width:2px 1px 2px 1px;" | URL structure should not reveal the underlying technology. Default content should be removed when possible. Tools that assist development or debugging should not be hosted or accessible.|| || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Format String|Format String]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | FS || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Alert and/or block on known format string signatures.|| style="border-width:2px 1px 2px 1px;" | Prohibit access to vulnerable APIs and provide safe wrappers of those APIs instead.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - HTTP Request/Response Smuggling|HTTP Request/Response Smuggling]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | RG || style="border-width:2px 1px 2px 1px;" | Tighten RFC standards to describe precise behavior for malformed request/response data. Increase SSL adoption to prevent proxy tampering.|| style="border-width:2px 1px 2px 1px;" | Enforce strict parity match between requests and responses, discarding extraneous Content-Length headers and canonicalizing requests/responses.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - HTTP Response Splitting|HTTP Response Splitting]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | RS || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Automatically URL-encode CRLF characters in dynamic data before writing to HTTP response headers.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Implicit Logout|Implicit Logout]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | IG || style="border-width:2px 1px 2px 1px;" | Define a new standard for handling sessions. Define CSP or other standard for triggering a logout flow when user browses away from a site. At least destroy session cookies.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Detect when a user browses away from the site and automatically log the user out of the application.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Improper Filesystem Permissions|Improper Filesystem Permissions]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | IF || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Ensure that proper file and directory permissions are applied. Enforce stricter default permissions.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Improper Input Handling|Improper Input Handling]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | IH || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Provide canonicalization and positive validation APIs for common data and file types, with configurable rules to reject or sanitize bad data.|| style="border-width:2px 1px 2px 1px;" | Provide canonicalization and positive validation APIs for custom data and file types, strictly enforcing business rules, with configurable rules to reject or sanitize bad data.|| style="border-width:2px 3px 2px 1px;" | Never use primitives in custom code.
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Improper Output Handling|Improper Output Handling]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | OH || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Provide context-sensitive encoders for all common data types in all output contexts, ensuring no custom code can write directly to output.|| style="border-width:2px 1px 2px 1px;" | Provide context-sensitive encoders for all custom data types in all output contexts, ensuring no custom code can write directly to output.|| style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Information Leakage|Information Leakage]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | IL || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Alert, block, or sanitize classified data in responses. Automatically scrub HTML, JavaScript, CSS, and other data formats of comment data and stack traces. Configure platform to return generic error codes by default and log locally. || style="border-width:2px 1px 2px 1px;" | Provide common error-handling framework and APIs which take two error messages as parameters: one to be displayed to the user and one to be written to logs. Provide configurable content expiration/caching interface; default to no-cache, no-store.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" | Don't leak information via error parity mismatches.
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Insufficient Authentication/Authorization|Insufficient Authentication/Authorization]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | IA || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Provide configuration-based authentication and authorization platform.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" | Apply least-privilege principle to all transactions, requiring authentication and authorization where applicable.
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Insufficient Data Protection|Insufficient Data Protection]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | ID || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Provide a configuration-based suite of encryption utilities for all data security needs including HMAC, symmetric, password hash, and asymmetric encryption requirements.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Insufficient Password Recovery|Insufficient Password Recovery]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | IR || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Provide generic credential recovery with configurable "secret question" and multi-factor side-channel authentication functionality (e.g. SMS, email, etc.).|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Insufficient Process Validation|Insufficient Process Validation]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | IP || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Require state validation rules to be specified for multi-step flows.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" | Enforce state validation for asynchronous transactions.
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Insufficient Session Expiration|Insufficient Session Expiration]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | IS || style="border-width:2px 1px 2px 1px;" | Define a new standard for instructing the browser about session timeouts and how to handle them.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Provide and enforce configurable absolute and inactivity-based session timeouts.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Insufficient Transport Layer Protection|Insufficient Transport Layer Protection]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | IT || style="border-width:2px 1px 2px 1px;" | Fix DNS and browser technologies so that the intent of domain owners can be more strictly followed.|| style="border-width:2px 1px 2px 1px;" | Enforce Strict Transport Security and redirect any HTTP request to HTTPS.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Integer Overflow/Underflow|Integer Overflow/Underflow]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | IO || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Provide safe wrappers for primitive numeric types.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" | Never use primitives without strict checking for underflow/overflow conditions.
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - LDAP Injection|LDAP Injection]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | LI || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Provide safe libraries for LDAP communication which properly encode dynamic data.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Mail Command Injection|Mail Command Injection]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | MI || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Provide safe libraries for SMTP and IMAP interaction that properly encode dynamic data.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Null Byte Injection|Null Byte Injection]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | NB || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Alert and/or block on known null byte attacks.|| style="border-width:2px 1px 2px 1px;" | Provide safe libraries that automatically encode dynamic data in any context which uses null bytes as control characters.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - OS Commanding|OS Commanding]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | OC || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Build safe wrappers for system calls which prevent dynamic data from changing the intended meaning of the call.|| style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Path Traversal|Path Traversal]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | PT || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Canonicalize URLs and prevent directory access outside the web root.|| style="border-width:2px 1px 2px 1px;" | Provide safe libraries for accessing the file system which canonicalize path references and enforce proper access control.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Race Conditions|Race Conditions]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | RC || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Prevent singletons from instantiating class-scope objects. Provide transaction integrity for task queues.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Remote File Inclusion|Remote File Inclusion]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | RF || style="border-width:2px 1px 2px 1px;" | Define a standard for safe inclusion of 3rd-party code and content which enforces namespace separation and mediates namespace/DOM access.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Provide proxy library to sanitize/sandbox third-party code and content for safe inclusion (e.g. Caja).|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Routing Detour|Routing Detour]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | RD || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Provide configuration-based whitelist for WS Routing destinations.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Server Misconfiguration|Server Misconfiguration]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | SM || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Ensure proper application settings are deployed in configuration file/s. Provide secure default settings.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Session Fixation|Session Fixation]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | SF || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Do not create sessions using session IDs generated by the HTTP client. Expire and rotate session IDs whenever the privilege level associated with a session changes.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - SOAP Array Abuse, XML Attribute Blowup, XML Entity Expansion|SOAP Array Abuse, XML Attribute Blowup, XML Entity Expansion]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | SA || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Perform schema validation of XML structure on incoming requests.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - SQL Injection|SQL Injection]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | SI || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Provide safe libraries for communicating with SQL servers which enforce parameterized query patterns.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" | Do not create queries with dynamic data in stored procedures.
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - SSI Injection|SSI Injection]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | SS || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Do not support SSI with dynamic file names.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - URL Redirector Abuse|URL Redirector Abuse]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | UR || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Provide configurable white list for redirection URLs in 3XX responses, Refresh headers, and JavaScript redirects.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - Weak Authentication Methods|Weak HTTP Authentication Methods]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | WA || style="border-width:2px 1px 2px 1px;" | Define a new, safe standard for HTTP-based authentication. || style="border-width:2px 1px 2px 1px;" | Reject HTTP Basic Auth, NTLM, and Digest Authentication requests. Block or proxy inline 3rd-party content.|| style="border-width:2px 1px 2px 1px;" | Block or proxy inline 3rd-party content.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - XML External Entities|XML External Entities]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | XE || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Disable External Entities within the XML parser. Enforce strict, static, internal DTDs.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 2px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - XML Injection|XML Injection]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 2px 1px;" | XI || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 1px 2px 1px;" | Provide safe libraries for constructing XML documents which automatically encode dynamic data.|| style="border-width:2px 1px 2px 1px;" | || style="border-width:2px 3px 2px 1px;" |
+|-
+| style="background:#f0f0f0; border-width:2px 1px 3px 3px;" | '''[[OWASP Periodic Table of Vulnerabilities - XPath/XQuery Injection|XPath/XQuery Injection]]''' || align="center" style="background:#f0f0f0; border-width:2px 1px 3px 1px;" | XP || style="border-width:2px 1px 3px 1px;" | || style="border-width:2px 1px 3px 1px;" | || style="border-width:2px 1px 3px 1px;" | Provide safe libraries for constructing XPath queries with dynamic data. Provide safe libraries for XQuery construction which parameterize query values.|| style="border-width:2px 1px 3px 1px;" | || style="border-width:2px 3px 3px 1px;" |
+|}
-{{:Projects/OWASP_Periodic_Table_of_Vulnerabilities}}
+= Release Formats =
-= Periodic Table of Vulnerabilities v0.9 =
+* [[Media:Periodic Table Infographic.pdf|Compressed view]] - One-pager that highlights the vulnerability classes that developers will still have to worry about at the top, with "solved" vulnerabilities ordered toward the bottom.
+* Infographic - Cartoony, visually-appealing storyboard introduction of the project, its goals, and high-level approach.
+* [[OWASP_Periodic_Table_of_Vulnerabilities#tab=Periodic_Table_of_Vulnerabilities|Working View/Summary]] - Working view summarizes solutions in respective columns for quick reference but doesn't provide details. Links directly to detailed sections.
+* Solution Detail (see linked issues on summary view) - Detailed view combines references, detailed solution designs, discussion/controversy detail, and other relevant information for each solution recommendation. The detail view does NOT explain what each vulnerability/weakness is - it only references existing vulnerability descriptions from other projects (e.g. OWASP Top 10, WASC TCv2, CWE, etc.). A short summary of root cause(s) is included, but only to the level of depth required to suggest all of the solution design elements that need to be addressed.
+* Solution Checklist - Summary of solutions grouped by target (e.g. perimeter or framework) so that maintainers of standards, frameworks, and perimeter technologies can view the solutions required for their areas ONLY. May require templating to generate list automatically, or short summaries in place of detailed descriptions.
+* [http://periodictable.github.io/ Periodic Table Interactive View] - Minimal representation of the Periodic Table View combined with a legend mapping each symbol to the vulnerability name, related taxonomies, and solution targets. Rolling over each element gives solution highlights. Clicking an element opens the corresponding Solution Detail view.
+* Periodic Table Poster-Size View - Vulns/Weaknesses laid out like the table of chemical elements, with solution target along the top and some measure of severity progressing down through the "periods". Top 10 could be highlighted in some way. Issues may show up in multiple periods. Poster-size so we can get all the relevant information in each "element".
+* [[Media:OWASP_Periodic_Table_-_Letter_Size.pdf|Periodic Table Compact View]] - Minimal representation of the Periodic Table View combined with a legend mapping each symbol to the vulnerability name, related taxonomies, and solution targets. View is designed to fit on a single US Letter size piece of paper, printed in grayscale.
-test
+= Project About =
+{{:Projects/OWASP_Periodic_Table_of_Vulnerabilities}}
-__NOTOC__
+__NOTOC__ <headertabs /> <br>
-<headertabs />
+{{OWASP Builders}}
 [[Category:OWASP Project]]

Difference between revisions of "OWASP Periodic Table of Vulnerabilities"

Latest revision as of 05:42, 13 February 2016

Introduction

Browsers, Standards, and Protocols

Perimeter / Platform Technologies

Generic Application Frameworks

Custom Application Frameworks

Custom Code

Navigation menu

Personal tools

Namespaces

Variants

Views

More

Search

Navigation

Reference

Tools