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 "Fail securely"
| (18 intermediate revisions by 6 users not shown) | |||
| Line 1: | Line 1: | ||
| − | {{Template: | + | {{Template:Principle}} |
| + | |||
| + | [[Category:OWASP ASDR Project]] | ||
| + | |||
| + | |||
| + | ==Description== | ||
| + | |||
| + | Handling errors securely is a key aspect of secure coding. There are two types of errors that deserve special attention. The first is exceptions that occur in the processing of a security control 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. If security controls can throw exceptions, they must be very clear about exactly what that condition means. | ||
| + | |||
| + | The other type of security-relevant exception is in code that is not part of a security control. These exceptions are security-relevant if they affect whether the application properly invokes the control. An exception might cause a security method not to be invoked when it should, or it might affect the initialization of variables used in the security control. | ||
| + | |||
| + | ==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. The fix is simple, in this case. It involves a simple reversing of the logic. In the example instance, this is very easy to do. | ||
| + | |||
| + | isAdmin = false; | ||
| + | try { | ||
| + | codeWhichMayFail(); | ||
| + | isAdmin = isUserInrole( "Administrator" ); | ||
| + | } | ||
| + | catch (Exception ex) | ||
| + | { | ||
| + | log.write(ex.toString()); | ||
| + | } | ||
| + | |||
| + | This example is also an example of the [[Least privilege]] principle, which states you should never grant more access than required. If codeWhichmayFail() requires admin access, we should be verifying that admin access before we run that code. | ||
| + | |||
| + | ==Related [[Vulnerabilities]]== | ||
| + | |||
| + | * [[Vulnerability 1]] | ||
| + | |||
| + | |||
| + | ==Related [[Controls]]== | ||
| + | |||
| + | * [[Error handling]] | ||
| + | |||
| + | ==Related [[Principles]]== | ||
| + | |||
| + | * [[Least privilege]] | ||
| + | |||
| + | ==References== | ||
| + | |||
| + | * https://buildsecurityin.us-cert.gov/articles/knowledge/principles/failing-securely | ||
| − | |||
[[Category:Principle]] | [[Category:Principle]] | ||
Latest revision as of 15:39, 17 May 2014
This is a principle or a set of principles. To view all principles, please see the Principle Category page.
Description
Handling errors securely is a key aspect of secure coding. There are two types of errors that deserve special attention. The first is exceptions that occur in the processing of a security control 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. If security controls can throw exceptions, they must be very clear about exactly what that condition means.
The other type of security-relevant exception is in code that is not part of a security control. These exceptions are security-relevant if they affect whether the application properly invokes the control. An exception might cause a security method not to be invoked when it should, or it might affect the initialization of variables used in the security control.
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. The fix is simple, in this case. It involves a simple reversing of the logic. In the example instance, this is very easy to do.
isAdmin = false;
try {
codeWhichMayFail();
isAdmin = isUserInrole( "Administrator" );
}
catch (Exception ex)
{
log.write(ex.toString());
}
This example is also an example of the Least privilege principle, which states you should never grant more access than required. If codeWhichmayFail() requires admin access, we should be verifying that admin access before we run that code.
Related Vulnerabilities
