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"
(→Overview) |
Cduffey346 (talk | contribs) (Added template) |
||
| Line 3: | Line 3: | ||
{{Template:Stub}} | {{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: | 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: | ||
| Line 14: | Line 14: | ||
The other type of security-relevant exception is outside specific security mechanisms, but may affect the control flow that invokes such mechanisms. | 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; | isAdmin = true; | ||
| Line 27: | Line 30: | ||
If codeWhichMayFail() fails, the user is an admin by default. This is obviously a security risk. | 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]] | [[Category:Principle]] | ||
Revision as of 20:25, 8 June 2008
This is a principle or a set of principles. To view all principles, please see the Principle Category page.
This article is a stub. You can help OWASP by expanding it or discussing it on its Talk page.
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
Related Controls
