OWASP - User contributions [en]

The Insecure-Bootstrapping Principle

2008-07-19T01:14:15Z

Cduffey346: Inserted template as a placeholder

{{Template:Principle}}

Last revision (mm/dd/yy): '''{{REVISIONMONTH}}/{{REVISIONDAY}}/{{REVISIONYEAR}}'''

==Description==

A principle is a simple rule that helps to guide security decisions in complex situations.
# Start with a one-sentence description of the principle
# Describe the principle and how it should be applied to security decisions

==Examples==

===Short example name===
: A short example description, small picture, or sample code with [http://www.site.com links]

===Short example name===
: A short example description, small picture, or sample code with [http://www.site.com links]

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]
* [[Vulnerabiltiy 2]]

==Related [[Controls]]==

* [[Controls 1]]
* [[Controls 2]]

==References==

* http://www.link1.com
* [http://www.link2.com Title for the link2]

Reduce Surface Area

2008-07-19T01:13:25Z

Cduffey346: Added template as placeholder

Don't trust user input

2008-07-19T01:12:22Z

Cduffey346:

Don't trust user input

2008-07-19T01:11:53Z

Cduffey346: Inserted template as a placeholder

Least privilege

2008-07-02T01:26:57Z

Cduffey346:

{{Template:Principle}}

{{Template:Stub}}

==Description==

The principle of least privilege recommends that accounts have the least amount of privilege required to perform their business processes. This encompasses user rights, resource permissions such as CPU limits, memory, network, and file system permissions.

==Examples==

===Administrative Priviledges Granted to a Middleware Server===
: For example, if a middleware server only requires access to the network, read access to a database table, and the ability to write to a log, this describes all the permissions that should be granted. Under no circumstances should the middleware be granted administrative privileges.

===Connecting to the Database as Root===
: In this example PHP code, only a SELECT statement from the database is issued. There is no reason to connect to the database as root. Instead, a user should be created with only the necessary access to the database that can be used to perform the SELECT query.
<?php
$host = 'localhost';
$userID = 'root';
$password = 'password';
$db = mysql_connect($host, $userID, $password) or die ('Error connecting to mysql');
$name = 'testdatabase';
mysql_select_db($name);
$sql="SELECT * FROM theTable";
$result=mysql_query($sql);
?>

==Related [[Vulnerabilities]]==

* [[Failure to drop privileges when reasonable]]
* [[Failure to check whether privileges were dropped successfully]]
* [[Least Privilege Violation]]

==Related [[Controls]]==

* [[Access control]]
* [[Authorization]]

==References==

* [http://web.mit.edu/Saltzer/www/publications/protection/ The Protection of Information in Computer Systems]

Separation of duties

2008-06-17T00:43:18Z

Cduffey346: Added Related Controls

{{Template:Principle}}

{{Template:Stub}}

==Description==

The rule of thumb for separation of duties is that the entity that approves an action, the entity that carries out an action, and the entity that monitors that action must be separate. Separation of duties is a prevelant control in both the accounting and IT communities. The goal is the eliminate the possibility of a single user from carrying out and concealing a prohibited action. By separating the authorization, implementation and monitoring roles fraud can only be successfully carried out through the collusion of multiple parties. Support for segregation of duties should be found in both application features (e.g., role-based access), and should be built into the System Development Lifecycle of the application (e.g., restricting developer access to production libraries). Certain roles have different levels of trust than normal users. In particular, Administrators are different to normal users. In general, administrators should not be users of the application.

==Examples==

===Equipment Purchase===
: Someone who requests a computer cannot also sign for it, nor should they directly receive the computer. This prevents the user from requesting many computers, and claiming they never arrived.

===System User/Administrator===
: An administrator should be able to turn the system on or off, set password policy but shouldn’t be able to log on to the storefront as a super privileged user, such as being able to “buy” goods on behalf of other users.

==Related [[Vulnerabilities]]==

* [[Log Forging]]
* [[Least Privilege Violation]]
* [[Permissions, Privileges, and ACLs]]

==Related [[Controls]]==

* [[Access control]]
* [[Authorization]]

==References==

* [http://www.isaca.org/Content/ContentGroups/Certification3/CISA1/Segregation-Of-Duties.pdf ISACA Separation of Duties Matrix]

[[Category:Principle]]

Least privilege

2008-06-17T00:38:06Z

Cduffey346: Added template, and related controls

Talk:ASDR TOC Principles

2008-06-17T00:33:05Z

Cduffey346: New page: The Secure Coding Principles and CLASP principle duplicate principles already listed in the table of contents. Suggest they be removed from the ASDR and have the contents of the Secure Cod...

The Secure Coding Principles and CLASP principle duplicate principles already listed in the table of contents. Suggest they be removed from the ASDR and have the contents of the Secure Coding Page and CLASP page referenced in each the corresponding ASDR principles.
--[[User:Cduffey346|Cduffey346]] 20:33, 16 June 2008 (EDT)

Positive security model

2008-06-17T00:27:08Z

Cduffey346: Added template, vulnerabilities, controls, example, and reference

{{Template:Principle}}

==Description==

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.

==Examples==

===isAuthorized===

<% 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]]==

* [[Authentication Logic Error]]
* [[Improper error handling]]
* [[Insecure Default Permissions]]
* [[Missing handler]]
* [[Permissions, Privileges, and ACLs]]
* [[Permissive Whitelist]]

==Related [[Controls]]==

* [[Authorization]]
* [[Error handling]]
* [[Web Application Firewall]]

==References==

* [http://owasp-esapi-java.googlecode.com/svn/trunk/javadoc/index.html OWASP Enterprise Security API (ESAPI)]

[[Category:Principle]]

Fix security issues correctly

2008-06-08T21:03:04Z

Cduffey346: Template conformity

{{Template:Principle}}

{{Template:Stub}}

==Description==

Once a security issue has been identified, it is important to develop a test for it, and to understand the root cause of the issue. When design patterns are used, it is likely that the security issue is widespread amongst all code bases, so developing the right fix without introducing regressions is essential.

==Examples==

===Integration Testing===
: A user has found that they can see another user’s balance by adjusting their cookie. The fix seems to be relatively straightforward, but as the cookie handling code is shared amongst all applications, a change to just one application will trickle through to all other applications. The fix must therefore be tested on all affected applications.

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]

==Related [[Controls]]==

* [[Controls 1]]

==References==

*

[[Category:Principle]]

Keep security simple

2008-06-08T20:57:46Z

Cduffey346: Conform to Principles Template

{{Template:Principle}}

==Description==

Attack surface area and simplicity go hand in hand. Certain software engineering fads prefer overly complex approaches to what would otherwise be relatively straightforward and simple code. Developers should avoid the use of double negatives and complex architectures when a simpler approach would be faster and simpler.

==Examples==

===Entity Beans vs. Global Variables===
:Although it might be fashionable to have a slew of singleton entity beans running on a separate middleware server, it is more secure and faster to simply use global variables with an appropriate mutex mechanism to protect against race conditions.

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]

==Related [[Controls]]==

* [[Controls 1]]

==References==

* See [[How to write insecure code]] for a tongue-in-cheek discussion of keeping security simple.

[[Category:Principle]]

Fail securely

2008-06-08T20:25:52Z

Cduffey346: Added template

{{Template:Principle}}

{{Template:Stub}}

==Description==

Handling errors securely is a key aspect of secure coding. There are two different types of errors that deserve special attention. The first is exceptions that occur in the processing of a countermeasure itself. It's important that these exceptions do not enable behavior that the countermeasure would normally not allow. As a developer, you should consider that there are generally three possible outcomes from a security mechanism:
* allow the operation
* disallow the operation
* exception

In general, you should design your security mechanism so that a failure will follow the same execution path as disallowing the operation. For example, security methods like isAuthorized(), isAuthenticated(), and validate() should all return false if there is an exception during processing.

The other type of security-relevant exception is outside specific security mechanisms, but may affect the control flow that invokes such mechanisms.

==Examples==

===isAdmin===

isAdmin = true;
try {
codeWhichMayFail();
isAdmin = isUserInRole( “Administrator” );
}
catch (Exception ex)
{
log.write(ex.toString());
}

If codeWhichMayFail() fails, the user is an admin by default. This is obviously a security risk.

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]

==Related [[Controls]]==

* [[Error handling]]

==References==

* http://www.link1.com

[[Category:Principle]]

Defense in depth

2008-06-08T20:07:04Z

Cduffey346: Changed redundant security controls to layered, removed section in description about the first security mechanism being 100% effective and replaced it with an example regarding 2-factor authentication

{{Template:Principle}}

{{Template:Stub}}

==Description==

The principle of defense-in-depth is that layered security mechanisms increase security of the system as a whole. If an attack causes one security mechanism to fail, other mechanisms may still provide the necessary security to protect the system. For example, it is not a good idea to totally rely on a firewall to provide security for an internal-use-only application, as firewalls can usually be circumvented by a determined attacker (even if it requires a physical attack or a social engineering attack of some sort). Other security mechanisms should be added to complement the protection that a firewall affords (e.g., surveillance cameras, and security awareness training) that address different attack vectors.

Implementing a defense-in-depth strategy can add to the complexity of an application, which runs counter to the “simplicity” principle often practiced in security. That is, one could argue that adding new protection functionality adds additional complexity that might bring new risks with it. The total risk to the system needs to be weighed. For example, an application with username/password-based authentication may not benefit from increasing the required password length from eight characters to 15 characters as the added complexity may result in users writing their passwords down, thus decreasing the overall security to the system; however, adding a smart-card requirement to authenticate to the application would enhance the security of the application by adding a complementary layer to the authentication process.

==Examples==

===Vulnerable Administrative Interface===
:A failed authentication control to the [[Administrative Interface]] is unlikely to be enable to anonymous attack on the system as a whole if it correctly gates access to production management networks, checks for administrative user authorization, and logs all access.

==Related [[Vulnerabilities]]==

==Related [[Controls]]==

The Principle of Defense-in-Depth does not relate to a particular control or subset of controls. It is a design principle to guide the selection of controls for an application to ensure its resilience against different forms of attack, and to reducce to probability of a single-point of failure in the security of the system.

==References==

* [http://www.nsa.gov/snac/support/defenseindepth.pdf National Security Agency Defense In Depth Guide]
* [[CLASP Security Principles]]

[[Category:Principle]]

Separation of duties

2008-06-04T00:24:01Z

Cduffey346:

{{Template:Principle}}

{{Template:Stub}}

==Description==

The rule of thumb for separation of duties is that the entity that approves an action, the entity that carries out an action, and the entity that monitors that action must be separate. Separation of duties is a prevelant control in both the accounting and IT communities. The goal is the eliminate the possibility of a single user from carrying out and concealing a prohibited action. By separating the authorization, implementation and monitoring roles fraud can only be successfully carried out through the collusion of multiple parties. Support for segregation of duties should be found in both application features (e.g., role-based access), and should be built into the System Development Lifecycle of the application (e.g., restricting developer access to production libraries). Certain roles have different levels of trust than normal users. In particular, Administrators are different to normal users. In general, administrators should not be users of the application.

==Examples==

===Equipment Purchase===
: Someone who requests a computer cannot also sign for it, nor should they directly receive the computer. This prevents the user from requesting many computers, and claiming they never arrived.

===System User/Administrator===
: An administrator should be able to turn the system on or off, set password policy but shouldn’t be able to log on to the storefront as a super privileged user, such as being able to “buy” goods on behalf of other users.

==Related [[Vulnerabilities]]==

* [[Log Forging]]
* [[Least Privilege Violation]]
* [[Permissions, Privileges, and ACLs]]

==Related [[Controls]]==

* [[Controls 1]]

==References==

* [http://www.isaca.org/Content/ContentGroups/Certification3/CISA1/Segregation-Of-Duties.pdf ISACA Separation of Duties Matrix]

[[Category:Principle]]

Detect intrusions

2008-05-28T00:20:44Z

Cduffey346:

{{Template:Principle}}

==Description==

Detecting intrusions requires three elements:
* the capability to log security-relevant events
* procedures to ensure the logs are monitored regularly
* procedures to properly respond to an intrusion once detected

You should log all security relevant information. Perhaps you can detect a problem by reviewing the logs that you couldn't detect at runtime. But you must log enough information. In particular, all use of security mechanisms should be logged, with enough information to help track down the offender. Additionally, the logging functionality in the application should also provide a method of managing the logged information. If the security analyst is unable to parse through the event logs to determine which events are actionable, then logging events provide little to no value.

Detecting intrusions is important because otherwise you give the attacker unlimited time to perfect an attack. If you detect intrusions perfectly, then an attacker will only get one attempt before he is detected and prevented from launching more attacks. Remember, if you receive a request that a legitimate user could not have generated - it is an attack and you should respond appropriately. Logging provides a forensic function for your application/site. If it is brought down or hacked, you can trace the culprit and check what went wrong. If the user uses an anonymizing proxy, having good logs will still help as "what happened" is logged and the exploit can be fixed more easily.

Don't rely on other technologies to detect intrusions. Your code is the only component of the system that has enough information to truly detect attacks. Nothing else will know what parameters are valid, what actions the user is allowed to select, etc. It must built into the application.

==Examples==

===Short example name===
:This is a place holder. A better example of logging using the ESAPI will go here.
public void testLogHTTPRequest() throws ValidationException, IOException, AuthenticationException {
System.out.println("logHTTPRequest");
String[] ignore = {"password","ssn","ccn"};
TestHttpServletRequest request = new TestHttpServletRequest();
// FIXME: AAA modify to return the actual string logged (so we can test)
Logger.getLogger("logger", "logger").logHTTPRequest(Logger.SECURITY, request, Arrays.asList(ignore) );
request.addParameter("one","one");
request.addParameter("two","two1");
request.addParameter("two","two2");
request.addParameter("password","jwilliams");
Logger.getLogger("logger", "logger").logHTTPRequest(Logger.SECURITY, request, Arrays.asList(ignore) );
}

==Related [[Vulnerabilities]]==

* [[Vulnerability 1]]

==Related [[Controls]]==

* [[Controls 1]]

==References==

* [http://www.owasp.org/index.php/ESAPI_Secure_Coding_Guideline#Logging_and_Intrusion_Detection ESAPI Logging and Intrusion Detection]

==Categories==

[[Category:Principle]]

Defense in depth

2008-05-26T16:27:19Z

Cduffey346:

{{Template:Principle}}

{{Template:Stub}}

==Description==

The principle of defense-in-depth is that redundant security mechanisms increase security. If one mechanism fails, perhaps the other one will still provide the necessary security. For example, it is not a good idea to rely on a firewall to provide security for an internal-use-only application, as firewalls can usually be circumvented by a determined attacker (even if it requires a physical attack or a social engineering attack of some sort).

Implementing a defense-in-depth strategy can add to the complexity of an application, which runs counter to the “simplicity” principle often practiced in security. That is, one could argue that new protection functionality adds additional complexity that might bring new risks with it. The risks need to be weighed. For example, a second mechanism may make no sense when the first mechanism is believed to be 100% effective; therefore, there is not much reason for introducing the additional solution, which may pose new risks. But usually the risks in additional complexity are minimal compared to the risk the protection mechanism seeks to reduce.

==Examples==

===Vulnerable Administrative Interface===
:A failed authentication control to the [[Administrative Interface]] is unlikely to be enable to anonymous attack on the system as a whole if it correctly gates access to production management networks, checks for administrative user authorization, and logs all access.

==Related [[Vulnerabilities]]==

==Related [[Controls]]==

==References==

* [http://www.nsa.gov/snac/support/defenseindepth.pdf National Security Agency Defense In Depth Guide]
* [[CLASP Security Principles]]

[[Category:Principle]]

Defense in depth

2008-05-25T12:19:27Z

Cduffey346: Added the rest of the template sections; expanded the description slightly; added a reference.

{{Template:Principle}}

{{Template:Stub}}

==Description==

The principle of defense in depth calls for a set of layered controls that each present unique obstacles for an attacker. Controls used in defense in depth posture enhance the resilience of an application as the failure of one control will not result in the exploitation of the system as a whole. An application using defense in depth would include controls that fit the “protect, detect, and react” paradigm. This means that the application would not just implement controls that prevent an attack from occurring, but would also be capable of detecting a successful attack and response procedures to support the recovery of the application.

With secure coding, this may take the form of tier-based validation, centralized auditing controls, and requiring users to be logged on all pages.

==Examples==

===Vulnerable Administrative Interface===
:A flawed administrative interface is unlikely to be vulnerable to anonymous attack if it correctly gates access to production management networks, checks for administrative user authorization, and logs all access.

==Related [[Vulnerabilities]]==

==Related [[Controls]]==

==References==

* [http://www.nsa.gov/snac/support/defenseindepth.pdf National Security Agency Defense In Depth Guide]

[[Category:Principle]]

Defense in depth

2008-05-23T21:31:04Z

Cduffey346: Began the conforming the article to the Principles Template

{{Template:Principle}}

{{Template:Stub}}

==Description==

The principle of defense in depth suggests that where one control would be reasonable, more controls that approach risks in different fashions are better. Controls, when used in depth, can make severe vulnerabilities extraordinarily difficult to exploit and thus unlikely to occur.

With secure coding, this may take the form of tier-based validation, centralized auditing controls, and requiring users to be logged on all pages.

==Examples==

===Vulnerable Administrative Interface===
:A flawed administrative interface is unlikely to be vulnerable to anonymous attack if it correctly gates access to production management networks, checks for administrative user authorization, and logs all access.

[[Category:Principle]]

Talk:Assume attackers have source code

2008-05-23T21:12:24Z

Cduffey346: /* Possible Candidate for Removal */

== Possible Candidate for Removal ==

I believe the content in this article could be folded in with the [[Avoid security by obscurity]] article. In essence, the reliance on compiled code to hide the vulnerabilities that may be apparent in the source code is a form of Security Through Obscurity.

You're right, but I think it's a useful principle and should be
separate. Most developers don't realize that their code is not
a secret. We could make Security by Obscurity a category. Or we
could just note that this is a form of security by obscurity and
provide a link. [[User:Jeff Williams|Jeff Williams]] 07:25, 23 May 2008 (EDT)

I don't know if it is quite broad enough to become a Category; perhaps linking
to [[Avoid security by obscurity]] would be a better way to go. --[[User:Cduffey346|Cduffey346]] 17:12, 23 May 2008 (EDT)

Talk:Assume attackers have source code

2008-05-23T00:28:22Z

Cduffey346: Possible Candidate for Removal