Difference between revisions of "Positive security model"

Jump to: navigation, search
(Related Vulnerabilities)
(6 intermediate revisions by the same user not shown)
Line 2: Line 2:
[[Category:OWASP ASDR Project]]
[[Category:OWASP ASDR Project]]
[[ASDR Table of Contents]]__TOC__
Line 28: Line 27:
* [[Improper error handling]]
* [[Improper error handling]]
* [[Insecure Default Permissions]]
* [[Missing handler]]
* [[Permissions, Privileges, and ACLs]]
* [[Permissive Whitelist]]
==Related [[Controls]]==
==Related [[Controls]]==
Line 42: Line 37:
* [http://owasp-esapi-java.googlecode.com/svn/trunk/javadoc/index.html OWASP Enterprise Security API (ESAPI)]
* [[:Category:OWASP Enterprise Security API]]

Revision as of 07:27, 7 April 2009

This is a principle or a set of principles. To view all principles, please see the Principle Category page.


A "positive" security model (also known as "whitelist") is one that defines what is allowed, and rejects everything else. This should be contrasted with a "negative" (or "blacklist") security model, which defines what is disallowed, while implicitly allowing everything else.

The positive security model can be applied to a number of different application security areas. For example, when performing input validation, the positive model dictates that you should specify the characteristics of input that will be allowed, as opposed to trying to filter out bad input. In the access control area, the positive model is to deny access to everything, and only allow access to specific authorized resources or functions. If you've ever had to deal with a network firewall, then you've probably encountered this application of the positive model.

The benefit of using a positive model is that new attacks, not anticipated by the developer, will be prevented. However, the negative model can be quite tempting when you're trying to prevent an attack on your site. Ultimately, however, adopting the negative model means that you'll never be quite sure that you've addressed everything. You'll also end up with a long list of negative signatures to block that has to be maintained.



<% if ( ESAPI.accessController().isAuthorizedForFunction( ADMIN_FUNCTION ) ) { %>
 <a href="/doAdminFunction">ADMIN</a>
<% } else { %>
 <a href="/doNormalFunction">NORMAL</a>
<% } %>
In this example, if there is explicit authorization for the function then it is authorized. The default action is to execute the normal function.

Related Vulnerabilities

Related Controls