Fail securely - Revision history

Travis Weston at 15:39, 17 May 2014

2014-05-17T15:39:38Z

Travis Weston at 15:21, 17 May 2014

2014-05-17T15:21:44Z

MediaWiki spam cleanup: Reverting to last version not containing links to www.textorolono.com

2009-05-27T18:31:00Z

Reverting to last version not containing links to www.textorolono.com

MediaWiki spam cleanup: Reverting to last version not containing links to s1.shard.jp

2009-05-27T16:00:29Z

Reverting to last version not containing links to s1.shard.jp

Deleted user at 12:09, 26 May 2009

2009-05-26T12:09:41Z

Deleted user at 19:51, 22 May 2009

2009-05-22T19:51:49Z

KirstenS at 12:26, 7 April 2009

2009-04-07T12:26:57Z

KirstenS at 18:52, 5 September 2008

2008-09-05T18:52:08Z

Jeff Williams at 03:40, 2 August 2008

2008-08-02T03:40:22Z

Jeff Williams at 03:39, 2 August 2008

2008-08-02T03:39:19Z

← Older revision		Revision as of 15:39, 17 May 2014
Line 1:		Line 1:
	{{Template:Principle}}		{{Template:Principle}}
−
−	~~{{Template:Stub}}~~

	[[Category:OWASP ASDR Project]]		[[Category:OWASP ASDR Project]]

@@ Line 3: / Line 3: @@
 {{Template:Stub}}
 [[Category:OWASP ASDR Project]]
@@ Line 32: / Line 31: @@
+  }
-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. 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.
 ==Related [[Vulnerabilities]]==
@@ Line 44: / Line 54: @@
 * [[Error handling]]
 ==References==
-* http://www.link1.com
+* https://buildsecurityin.us-cert.gov/articles/knowledge/principles/failing-securely
 [[Category:Principle]]

@@ Line 1: / Line 1: @@
 {{Template:Principle}}
@@ Line 26: / Line 25: @@
   try {
     codeWhichMayFail();
-    isAdmin = isUserInRole( âAdministratorâ );
+    isAdmin = isUserInRole( “Administrator” );
+  }
   catch (Exception ex)

@@ Line 1: / Line 1: @@
 http://www.textorolono.com
 {{Template:Principle}}
@@ Line 70: / Line 26: @@
   try {
     codeWhichMayFail();
-    isAdmin = isUserInRole( Ã¢ÂÂAdministratorÃ¢ÂÂ );
+    isAdmin = isUserInRole( âAdministratorâ );
+  }
   catch (Exception ex)

@@ Line 1: / Line 1: @@
 http://www.textorolono.com
 {{Template:Principle}}
@@ Line 26: / Line 70: @@
   try {
     codeWhichMayFail();
-    isAdmin = isUserInRole( âAdministratorâ );
+    isAdmin = isUserInRole( Ã¢ÂÂAdministratorÃ¢ÂÂ );
+  }
   catch (Exception ex)

← Older revision		Revision as of 12:26, 7 April 2009
Line 5:		Line 5:
	<br>		<br>
	[[Category:OWASP ASDR Project]]		[[Category:OWASP ASDR Project]]
−	~~[[ASDR Table of Contents]]__TOC__~~

← Older revision		Revision as of 18:52, 5 September 2008
Line 2:		Line 2:

	{{Template:Stub}}		{{Template:Stub}}
		+
		+	<br>
		+	[[Category:OWASP ASDR Project]]
		+	[[ASDR Table of Contents]]__TOC__
		+

	==Description==		==Description==

← Older revision		Revision as of 03:40, 2 August 2008
Line 11:		Line 11:

	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.		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.
−
−	~~[[Category:FIXME\|This is screwy]]~~

	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.		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.

@@ Line 12: / Line 12: @@
 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.
-[[Category:FIXME this is all screwed up]]
+[[Category:FIXME|This is screwy]]
 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.