Part of our client's development process includes running a static code scan with the [Veracode](http://www.veracode.com) security tool. Veracode warns of a security flaw in the most recent stable release of the AJAX Control Toolkit that it describes as "Use of Externally-Controlled Input to Select Classes or Code ('Unsafe Reflection') ".
It locates this flaw at [ToolkitScriptManager.cs](http://ajaxcontroltoolkit.codeplex.com/SourceControl/changeset/view/d864443e4a38#Server/AjaxControlToolkit/ToolkitScriptManager/ToolkitScriptManager.cs) line 730, which is right after a call to System.Reflection.Assembly.Load().
The Veracode description of this type of flaw is as follows:
>A call uses reflection in an unsafe manner. An attacker can specify the class name to be instantiated, which may create unexpected control flow paths through the application. Depending on how reflection is being used, the attack vector may allow the attacker to bypass security checks or otherwise cause the application to behave in an unexpected manner. Even if the object does not implement the specified interface and a ClassCastException is thrown, the constructor of the user-supplied class name will have already executed.
There's also a link to [CWE 470](http://cwe.mitre.org/data/definitions/470.html) which includes more detailed information for this type of error.
I don't know enough about the architecture of the AJAX Control Toolkit to know what assemblies are supposed to be loaded by ToolkitScriptManager or what code paths might allow a different assembly to be loaded as a result of malicious input.
If it would be undesirable to refactor out the call to System.Reflection.Assembly.Load(), any mitigating circumstances that I could take back to my client's security team would be greatly appreciated. Is the assembly name checked against a whitelist before loading? Are there other guards here against malicious input?
Comments: Starting with the v15.1 release, we have removed the ToolkitScriptManager due to various issues it caused. So, the described problem no longer exists.
It locates this flaw at [ToolkitScriptManager.cs](http://ajaxcontroltoolkit.codeplex.com/SourceControl/changeset/view/d864443e4a38#Server/AjaxControlToolkit/ToolkitScriptManager/ToolkitScriptManager.cs) line 730, which is right after a call to System.Reflection.Assembly.Load().
The Veracode description of this type of flaw is as follows:
>A call uses reflection in an unsafe manner. An attacker can specify the class name to be instantiated, which may create unexpected control flow paths through the application. Depending on how reflection is being used, the attack vector may allow the attacker to bypass security checks or otherwise cause the application to behave in an unexpected manner. Even if the object does not implement the specified interface and a ClassCastException is thrown, the constructor of the user-supplied class name will have already executed.
There's also a link to [CWE 470](http://cwe.mitre.org/data/definitions/470.html) which includes more detailed information for this type of error.
I don't know enough about the architecture of the AJAX Control Toolkit to know what assemblies are supposed to be loaded by ToolkitScriptManager or what code paths might allow a different assembly to be loaded as a result of malicious input.
If it would be undesirable to refactor out the call to System.Reflection.Assembly.Load(), any mitigating circumstances that I could take back to my client's security team would be greatly appreciated. Is the assembly name checked against a whitelist before loading? Are there other guards here against malicious input?
Comments: Starting with the v15.1 release, we have removed the ToolkitScriptManager due to various issues it caused. So, the described problem no longer exists.