11.07.2015 Views

Improving Web Application Security: Threats and - CGISecurity

Improving Web Application Security: Threats and - CGISecurity

Improving Web Application Security: Threats and - CGISecurity

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

624 Part V: Assessing Your <strong>Security</strong>Do You Use Declarative <strong>Security</strong> Attributes?Declarative security attributes can be displayed with tools such as Permview.exe.This greatly helps the consumers <strong>and</strong> administrators of your assemblies tounderst<strong>and</strong> the security requirements of your code.● Do you request minimum permissions?Search for “.RequestMinimum” strings to see if your code uses permissionrequests to specify its minimum permission requirements. You should do this toclearly document the permission requirements of your assembly.● Do you request optional or refuse permissions?Search for “.RequestOptional” <strong>and</strong> “.RequestRefuse” strings. If you use either ofthese two actions to develop least privileged code, be aware that your code can nolonger call strong named assemblies unless they are marked with theAllowPartiallyTrustedCallersAttribute.●●Do you use imperative security instead of declarative security?Sometime imperative checks in code are necessary because you need to applylogic to determine which permission to dem<strong>and</strong> or because you need a runtimevariable in the dem<strong>and</strong>. If you do not need specific logic, consider usingdeclarative security to document the permission requirements of your assembly.Do you mix class <strong>and</strong> member level attributes?Do not do this. Member attributes, for example on methods or properties, replaceclass-level attributes with the same security action <strong>and</strong> do not combine with them.Do You Call Assert?Scan your code for Assert calls. This may turn up instances of Debug.Assert. Lookfor where your code calls Assert on a CodeAccessPermission object. When youassert a code access permission, you short-circuit the code access security permissiondem<strong>and</strong> stack walk, which is a risky practice. What steps does your code take toensure that malicious callers do not take advantage of the assertion to access asecured resource or privileged operation? Review the following questions:● Do you use the dem<strong>and</strong>, assert pattern?Check that your code issues a Dem<strong>and</strong> prior to the Assert. Code should dem<strong>and</strong>a more granular permission to authorize callers prior to asserting a broaderpermission such as the unmanaged code permission.● Do you match Assert calls with RevertAssert?Check that each call to Assert is matched with a call to RevertAssert. The Assertis implicitly removed when the method that calls Assert returns, but it is goodpractice to explicitly call RevertAssert, as soon as possible after the Assert call.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!