Testing Tips

Since there isn t just one type of attack that managed code introduces, below are several tips when security testing managed code that you should use when testing your application.

  • Run FxCop. FxCop is a great tool that can catch a lot of common coding errors. Be sure to enable all the security rules. Also, look at all of the places that use SuppressMessage to see whether the developer has a valid reason for suppressing the FxCop message.

  • Analyze all asserts. Because an assert stops the CLR from performing a stack walk on all the callers , determine whether an untrusted caller can call into the method doing the assert.

  • Limit the scope of an assert. There aren t many reasons for an assert to span several lines of code. Sometimes developers use the permissions security attribute to apply the assert at the method level because that s easier. If only one line of code needs the assert, scope it to just that one line. RevertAssert should also be used instead of allowing the assert to go out of scope.

  • Look for broad asserts. If possible, run with the least number of permissions needed for your application to execute. This tip is especially true for Web applications. If a Web application doesn t need to run at FullTrust, choose another policy that reduces the permissions of the AppDomain. Also, most asserts can also limit access to resources. For instance, if you need to read only a single file, there is no reason to give all access to any file on the machine.

  • Look for luring attacks. If your application allows partially trusted callers to execute code, you should test for luring attacks. Start by analyzing all of the public interfaces that an attacker can call. If the method is protected by a link demand, see if the link demand can be bypassed. Methods that assert a permission should also demand a permission that trusted callers would have, but not an attacker, for instance, using a custom permission attribute.

  • Look for and review unsafe code. The /unsafe switch enables the application to use unsafe code when compiling. Review all unsafe code blocks.

  • Look for use of PermitOnly and Deny to sandbox code. Any code that uses PermitOnly and Deny in order to sandbox permissions should be considered a bug. Instead, the code should use a restricted AppDomain.

  • Verify that exceptions don t disclose too much information. Because exception cases aren t always hit when performing functionality testing, analyze the application s exception code to see whether any sensitive data can be returned to malicious users.

  • Attempt exception filtering attacks. Look for places where permissions elevate an actual user s privileges. Make sure that malicious code can not cause an exception inthe code that can be handled in the attack s code, which could cause elevating of permissions.

More Info  

For more information about testing managed code, refer to the security checklist at http://msdn.microsoft.com/library/en-us/dnpag2/html/SecurityCodeReviewIndex.asp .



Hunting Security Bugs
Hunting Security Bugs
ISBN: 073562187X
EAN: 2147483647
Year: 2004
Pages: 156

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net