Archive

Archive for the ‘Secure Coding’ Category

WCF Authorization with Custom Principal

January 4th, 2010 Comments off

Hi, I am Syam Pinnaka, Sr. SDE in InfoSec tools team.

In AuthZ component of CISF, we have a requirement to perform authorization checks in a WCF service. Since CISF AuthZ module has a custom implementation of IPrincipal called as CISFPrincipal, Its looks little tricky to use the CISFPincipal in a WCF client. but WCF makes it easy with IAuthorizationPolicy interface as explained below.

In order to integrate a custom Principal with WCF, we need to set the “PrincipalPermissionMode” property to “Custom”. In addition, we also need to set the authorization policy that will be used to create the custom principal objet and supply it to WCF plumbing.

Here is a sample implementation.

Authorization Policy:

    public class CISFAuthorizationPolicy: IAuthorizationPolicy
    {
        // this method gets called after the authentication stage
        public bool Evaluate(EvaluationContext evaluationContext, ref object state)
        {            
                // Get the authenticated client identity
                IIdentity client = GetClientIdentity(evaluationContext);
                
                Microsoft.InformationSecurity.CISF.Security.AuthZServices.AuthZService auth = new AuthZService();
                User singleuser = auth.GetUserInformation(client.Name, ConfigurationManager.AppSettings["ApplicationName"]);

                // Set the custom principal
                evaluationContext.Properties["Principal"] = new CISF.Security.Principal.CISFPrincipal(client, singleuser);                            
                return true;
        }
     }

Configuration:

<behaviors>
    <serviceBehaviors>
    <behavior name='CISFCustomBehavior'>       
      <serviceAuthorization principalPermissionMode='Custom'>
        <authorizationPolicies>
          <add policyType='Service.CISFAuthorizationPolicy, Service' />
        </authorizationPolicies>
      </serviceAuthorization>
    </behavior>
  </serviceBehaviors>
</behaviors>

Once the custom Principal is set in evalutationContext, regular authorization checks can be carried out based on custom principal. If custom principal implements Roles, PrincipalPermission.Demand can be used for imperative security check.

Alternatively, ServiceAuthorizationManager can be used to centralize the authorization logic instead of spreading the authorization logic all over the WCF service code. We can override the “CheckAccess” method to carry out our custom authorization check. One shortcoming of this method would be to modify this logic as new methods are added to or removed from the WCF service.

Feel free to contact me at syamp@microsoft.com if you need more details about any of the above approaches.

Happy coding and Happy New year, 2010!

Categories: C#, CISF, Secure Coding Tags:

WCF Authorization with Custom Principal

January 4th, 2010 No comments

Hi, I am Syam Pinnaka, Sr. SDE in InfoSec tools team.

In AuthZ component of CISF, we have a requirement to perform authorization checks in a WCF service. Since CISF AuthZ module has a custom implementation of IPrincipal called as CISFPrincipal, Its looks little tricky to use the CISFPincipal in a WCF client. but WCF makes it easy with IAuthorizationPolicy interface as explained below.

In order to integrate a custom Principal with WCF, we need to set the “PrincipalPermissionMode” property to “Custom”. In addition, we also need to set the authorization policy that will be used to create the custom principal objet and supply it to WCF plumbing.

Here is a sample implementation.

Authorization Policy:

    public class CISFAuthorizationPolicy: IAuthorizationPolicy
    {
        // this method gets called after the authentication stage
        public bool Evaluate(EvaluationContext evaluationContext, ref object state)
        {            
                // Get the authenticated client identity
                IIdentity client = GetClientIdentity(evaluationContext);
                
                Microsoft.InformationSecurity.CISF.Security.AuthZServices.AuthZService auth = new AuthZService();
                User singleuser = auth.GetUserInformation(client.Name, ConfigurationManager.AppSettings["ApplicationName"]);

                // Set the custom principal
                evaluationContext.Properties["Principal"] = new CISF.Security.Principal.CISFPrincipal(client, singleuser);                            
                return true;
        }
     }

Configuration:

<behaviors>
    <serviceBehaviors>
    <behavior name='CISFCustomBehavior'>       
      <serviceAuthorization principalPermissionMode='Custom'>
        <authorizationPolicies>
          <add policyType='Service.CISFAuthorizationPolicy, Service' />
        </authorizationPolicies>
      </serviceAuthorization>
    </behavior>
  </serviceBehaviors>
</behaviors>

Once the custom Principal is set in evalutationContext, regular authorization checks can be carried out based on custom principal. If custom principal implements Roles, PrincipalPermission.Demand can be used for imperative security check.

Alternatively, ServiceAuthorizationManager can be used to centralize the authorization logic instead of spreading the authorization logic all over the WCF service code. We can override the “CheckAccess” method to carry out our custom authorization check. One shortcoming of this method would be to modify this logic as new methods are added to or removed from the WCF service.

Feel free to contact me at syamp@microsoft.com if you need more details about any of the above approaches.

Happy coding and Happy New year, 2010!

Categories: C#, CISF, Secure Coding Tags:

WCF Authorization with Custom Principal

January 4th, 2010 No comments

Hi, I am Syam Pinnaka, Sr. SDE in InfoSec tools team.

In AuthZ component of CISF, we have a requirement to perform authorization checks in a WCF service. Since CISF AuthZ module has a custom implementation of IPrincipal called as CISFPrincipal, Its looks little tricky to use the CISFPincipal in a WCF client. but WCF makes it easy with IAuthorizationPolicy interface as explained below.

In order to integrate a custom Principal with WCF, we need to set the “PrincipalPermissionMode” property to “Custom”. In addition, we also need to set the authorization policy that will be used to create the custom principal objet and supply it to WCF plumbing.

Here is a sample implementation.

Authorization Policy:

    public class CISFAuthorizationPolicy: IAuthorizationPolicy
    {
        // this method gets called after the authentication stage
        public bool Evaluate(EvaluationContext evaluationContext, ref object state)
        {            
                // Get the authenticated client identity
                IIdentity client = GetClientIdentity(evaluationContext);
                
                Microsoft.InformationSecurity.CISF.Security.AuthZServices.AuthZService auth = new AuthZService();
                User singleuser = auth.GetUserInformation(client.Name, ConfigurationManager.AppSettings["ApplicationName"]);

                // Set the custom principal
                evaluationContext.Properties["Principal"] = new CISF.Security.Principal.CISFPrincipal(client, singleuser);                            
                return true;
        }
     }

Configuration:

<behaviors>
    <serviceBehaviors>
    <behavior name='CISFCustomBehavior'>       
      <serviceAuthorization principalPermissionMode='Custom'>
        <authorizationPolicies>
          <add policyType='Service.CISFAuthorizationPolicy, Service' />
        </authorizationPolicies>
      </serviceAuthorization>
    </behavior>
  </serviceBehaviors>
</behaviors>

Once the custom Principal is set in evalutationContext, regular authorization checks can be carried out based on custom principal. If custom principal implements Roles, PrincipalPermission.Demand can be used for imperative security check.

Alternatively, ServiceAuthorizationManager can be used to centralize the authorization logic instead of spreading the authorization logic all over the WCF service code. We can override the “CheckAccess” method to carry out our custom authorization check. One shortcoming of this method would be to modify this logic as new methods are added to or removed from the WCF service.

Feel free to contact me at syamp@microsoft.com if you need more details about any of the above approaches.

Happy coding and Happy New year, 2010!

Categories: C#, CISF, Secure Coding Tags:

What’s happening with CAT.NET 2.0?

December 30th, 2009 Comments off

RV here…

Our pre alpha release included a command line tool showcasing newer version of CAT.NET based on tainted data flow analysis engine using Phoenix compiler infrastructure. It also included a configuration analysis engine which was capable of identifying insecure configuration in .config files. We are actively working on the potential beta release of CAT.NET tool focusing mainly on the core analysis and user experience areas. Here is a quick update on changes.

  • User Experience
    • Integration with Visual Studio 2010 code analysis infrastructure as FxCop rules
    • Easy analysis using FxCop command line or UI interface or VSTS Team Build.
  • Core Analysis
    • Updated tainted data flow analysis engine to track both tainted operands and source symbols
    • Lesser false positives and false negatives by detecting sanitizers and constant variables and instructions that affect the data flow.
    • New Data flow rule to detect XML Injection attacks
    • Updated configuration rules engine to detect clear text connection strings and credentials
    • Updated rules to detect insecure defaults, for example minRequiredPasswordLength attribute of membership providers add element.
    • Configuration rules updated to detect @page directive configuration overrides.

Here is a list of FxCop CAT.NET data flow rules.

image

Here is a list of FxCop CAT.NET configuration rules.

image

With tighter integration with visual studio code analysis the changes are going to make it much more easier to use CAT.NET analysis to detect application level security issues.

Happy New Year!

Categories: C#, CAT.NET, Secure Coding Tags:

What’s happening with CAT.NET 2.0?

December 30th, 2009 No comments

RV here…

Our pre alpha release included a command line tool showcasing newer version of CAT.NET based on tainted data flow analysis engine using Phoenix compiler infrastructure. It also included a configuration analysis engine which was capable of identifying insecure configuration in .config files. We are actively working on the potential beta release of CAT.NET tool focusing mainly on the core analysis and user experience areas. Here is a quick update on changes.

  • User Experience
    • Integration with Visual Studio 2010 code analysis infrastructure as FxCop rules
    • Easy analysis using FxCop command line or UI interface or VSTS Team Build.
  • Core Analysis
    • Updated tainted data flow analysis engine to track both tainted operands and source symbols
    • Lesser false positives and false negatives by detecting sanitizers and constant variables and instructions that affect the data flow.
    • New Data flow rule to detect XML Injection attacks
    • Updated configuration rules engine to detect clear text connection strings and credentials
    • Updated rules to detect insecure defaults, for example minRequiredPasswordLength attribute of membership providers add element.
    • Configuration rules updated to detect @page directive configuration overrides.

Here is a list of FxCop CAT.NET data flow rules.

image

Here is a list of FxCop CAT.NET configuration rules.

image

With tighter integration with visual studio code analysis the changes are going to make it much more easier to use CAT.NET analysis to detect application level security issues.

Happy New Year!

Categories: C#, CAT.NET, Secure Coding Tags:

What’s happening with CAT.NET 2.0?

December 30th, 2009 No comments

RV here…

Our pre alpha release included a command line tool showcasing newer version of CAT.NET based on tainted data flow analysis engine using Phoenix compiler infrastructure. It also included a configuration analysis engine which was capable of identifying insecure configuration in .config files. We are actively working on the potential beta release of CAT.NET tool focusing mainly on the core analysis and user experience areas. Here is a quick update on changes.

  • User Experience
    • Integration with Visual Studio 2010 code analysis infrastructure as FxCop rules
    • Easy analysis using FxCop command line or UI interface or VSTS Team Build.
  • Core Analysis
    • Updated tainted data flow analysis engine to track both tainted operands and source symbols
    • Lesser false positives and false negatives by detecting sanitizers and constant variables and instructions that affect the data flow.
    • New Data flow rule to detect XML Injection attacks
    • Updated configuration rules engine to detect clear text connection strings and credentials
    • Updated rules to detect insecure defaults, for example minRequiredPasswordLength attribute of membership providers add element.
    • Configuration rules updated to detect @page directive configuration overrides.

Here is a list of FxCop CAT.NET data flow rules.

image

Here is a list of FxCop CAT.NET configuration rules.

image

With tighter integration with visual studio code analysis the changes are going to make it much more easier to use CAT.NET analysis to detect application level security issues.

Happy New Year!

Categories: C#, CAT.NET, Secure Coding Tags:

How To: Use CAT.NET V2.0 CTP

December 30th, 2009 Comments off

Syed Aslam Basha here. I am a tester on the Information Security Tools team responsible for testing CAT.NET v2.0.

As the installer name suggests CATNETV20CMD, CAT.NET V2.0 CTP is command line version only. CAT.NET v2.0 CTP analyses assemblies for vulnerabilities and configuration files for misconfigurations. You can open the rules files present at C:\Program files\Microsoft Information Security tools\Microsoft Code Analysis for .NET(CAT.NET) v2.0\Rules\ConfigRules, to get an understanding of configuration rules. Example, configrule for trace, if trace is enabled it will be shown in report.

   1: <?xml version="1.0" encoding="utf-8"?>

   2: <ConfigurationRule xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" typeName="Microsoft.InformationSecurity.CodeAnalysis.Engines.RulesModel.ConfigurationRule, Microsoft.InformationSecurity.CodeAnalysis.Engines.RulesModel, Version=1.0.0.0, Culture=neutral, PublicKeyToken=b9ded31be328441b" enabled="false" comparisionType="AttributeCheck" isAndConditions="false">

   3:   <Information cultureName="en-US">

   4:     <Category>Web Security</Category>

   5:     <Certainity>50</Certainity>

   6:     <Description>Trace is enabled which can lead to information disclosure</Description>

   7:     <Email>anilkr@microsoft.com</Email>

   8:     <Name>Trace enabled attribute is set to true</Name>

   9:     <Owner>Anil Revuru</Owner>

  10:     <Resolution>Set enabled attribute to false</Resolution>

  11:     <RuleId>WEBCONFSEC07</RuleId>

  12:     <SeverityLevel>High</SeverityLevel>

  13:     <Url></Url>

  14:     <Problem>Enabled attribute is set to true</Problem>

  15:   </Information>

  16:   <Conditions>

  17:     <Condition conditionId="42C400DF-5130-4FDB-9EE3-8C944D92BBC8" configurationPath="/configuration/system.web/trace" attributeName="enabled" attributeValue="true" comparisionOperator="Equals" />

  18:   </Conditions>

  19: </ConfigurationRule>

  20:  

Steps to use CAT.NET v2.0:

  • Launch command prompt in administrator mode and go to C:\Program files\Microsoft Information Security tools\Microsoft Code Analysis for .NET(CAT.NET) v2.0.
  • Enter

    CATNetCmd.exe /file:"D:\MyApplication\bin\Application.dll" /configdir:"D:\MyApplication" /report:"D:\MyApplication\ApplicationReport.xml" /reportxsloutput:"D:\MyApplicaiton\ApplicationReport.htm"

  • /file and /configdir switches are mandatory, file is the path to the assembly to analyze and configdir path to the web.config file to analyze. It analyzes all web.configuration files under the folder and reports the issues. Total 40 rules are loaded, 33 config rules and 7 data flow rules.
  • Following are the command-line options available

    /file:<target>

    Required. The path of an assembly file to analyze. Multiple file paths and wildcards are not supported. This is a required parameter.

    /configdir:<target directory>

    Required. The path to a directory which contains .NET configuration files for analysis.

    /rules:<directory>

    Optional. The path to a file or directory that contains analysis rule(s).  The engine will use the default rules included with the product by default.

    /report:<file>

    Optional. The file to store the analysis report in.  By default, the report will be saved in ‘MicrosoftCodeAnalysisReport.xml’ in the current working directory.

    /reportxsl:<file>

    Optional. The XSL file to use to transform the report.  By default, the packaged XSL transform included in the product will be used.

    /reportxsloutput:<file>

    Optional. The output file to store the XSLT transform output in.  By default, the HTML report will be saved in ‘report.html’ in the current working directory.

    /verbose

    Optional. Enables flag to display verbose message when displaying results.

  • The CAT.NET report contains detailed information about dataflow and configuration analysis errors along with line numbers.
  • CATNETBlog1 

– Syed