ToolkitScriptManager -- XSS vulnerability RRS feed

  • Question

  • User11544886 posted

     Hi everyone,

    We’ve run into a problem with our ASP.NET 2.0 application while being audited by a third party for security. It seems that adopting the AJAX Control Toolkit has exposed us to an XSS vulnerability:

    1)    We’re using the AJAX Control Toolkit Script Manager control (from v. 2.0.20229, the last .NET 2.0 compatible build).
    2)    The exploit requires that the user authenticates successfully.
    3)    After login, the user pastes the following url into the browser:
    4)    The browser returns an aspx-file generated by the toolkit, e.g. CAWT4TOB.aspx. This file contains a huge amount of toolkit javascript, preceded by the following comment: //START AjaxControlToolkit.Common.Common.js
    5)    At the very bottom of this file, the following appears:

    //END AjaxControlToolkit.ListSearch.ListSearchBehavior.js
    (function() {var fn = function() {$get('ajaxScriptManager_HiddenField37c5d');}}alert('javascripthijacking and xss')//c9c4b0b8d4b').value += ';;AjaxControlToolkit, Version=1.0.20229.20821, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e:fi-FI:c5c982cc-4942-4683-9b48-c2c58277700f:e2e86ef9:1df13a87:c4c00916:9ea3f0e2:9e8e87e9:4c9865be:ba594826:c76f1358:69ce9abf';Sys.Application.remove_load(fn);};Sys.Application.add_load(fn);})();
    So basically the script manager itself is sanitizing user input properly, and thus allows for javascript injection. I wasn’t able to get the script to execute and display the pop-up, but the auditor says they can’t guarantee it’s not possible. Here's the relevant code from the ToolkitScriptManager.cs:


    protected override void OnLoad(EventArgs e)
    // Initialize
    _disabledScriptReferences = new List<ScriptReference>();
    _uncombinableScriptReferences = new List<scriptreference>();

    // Create a hidden field to track loaded scripts - load its contents if already present
    string hiddenFieldName = HiddenFieldName;
    string value = "";
    if (!IsInAsyncPostBack || (null == Page.Request.Form[hiddenFieldName]))
    RegisterHiddenField(Page, hiddenFieldName, value);
    //!!! This input isn't sanitized!
    value = Page.Request.Form[hiddenFieldName];

    // Get the list of already-loaded scripts from the page
    _scriptEntries = DeserializeScriptEntries(value, true);


     So what are my options here? The auditor recommends using the Microsoft Anti-Cross Site Scripting Library [1] to encode the input. However, this means we would have to make changes to the toolkit source and recompile the dll. This might be tricky given our current schedule. We also can’t remove the toolkit features from use without significant effort.

    Has anyone seen this kind of behavior before? Is there some simple solution I’m overlooking?  Google didn’t give me any real help, so I’m hoping someone can either provide me with a solution or give me evidence to prove that the injected script can never be executed.

    Tommi Lind
    Avanade Finland

    1)    http://msdn.microsoft.com/en-us/library/aa973813.aspx

    Monday, June 1, 2009 3:46 AM

All replies

  • User11544886 posted

    After receiving several emails requesting details on our resolution of this problem, here's a brief summary of what we eventually did:

    We ended up using Microsoft’s own ScriptManager control instead of the one provided with the toolkit. By doing this we lost the ability to use script combining, but according to some sources it was poorly implemented in the .NET 2.0 version of the toolkit to begin with.

    Before arriving at this solution we experimented with rewriting and rebuilding the Ajax library to better handle that input. If I recall correctly, we were unable to resolve the issue in this way despite the use of the AntiXss Library. I think this was mostly due to issues with accurately reproducing the problem.

    A user named nathanysmith has apparently created a work item related to the original problem: http://ajaxcontroltoolkit.codeplex.com/WorkItem/View.aspx?WorkItemId=26001

    In that work item he mentions that my original reference for the toolkit code is wrong, and the correct reference is
    // Write a handler to run on page load and update the hidden field tracking scripts loaded in the browser
    "(function() {{" +
    "var fn = function() {{" +
    "$get('{0}').value += '{1}';" +
    "Sys.Application.remove_load(fn);" +
    "}};" +
    "Sys.Application.add_load(fn);" +
    "}})();", System.Web.HttpUtility.HtmlEncode(hiddenFieldName), SerializeScriptEntries(scriptEntries, true)));"


    Hopefully this will help anyone else who finds themselves struggling with the same problem.

    Wednesday, May 19, 2010 4:00 AM
  • User1531513703 posted

    Hello !

    Thanks for sharing your experiences with ASP.NET Ajax and XSS. I have recently come across a similar issue. My site is being audited and the auditor mentioned exactly this same issue. I have, however, no idea how to fix this as this would interfere with the Ajax framework. The approach you mention involves creating a handler for the OnLoad event, but it is not clear to me how to implement it by looking at the piece of code you pasted. I can see that some hidden field name is being encoded, that's all. But it seems to me that is only part of the solution and something else is missing.

    Could you shed some light on to this? I am using ASP.NET 3.5 together with the Ajax Control toolkit version 40412 (for .NET 3.5)



    Tuesday, January 18, 2011 10:38 AM
  • Tuesday, January 18, 2011 10:33 PM
  • User1531513703 posted

    Hi Chetan

    Thanks for the tip. I came across the bug report you mention, but the patch they mention is unavailable. As for the ToolkitScriptManager.cs file to download, should I replace the original and recompile the whole Toolkit ? For that I would need to download the toolkit source code.

    What do you suggest?


    Wednesday, January 19, 2011 7:17 AM
  • User-2043905579 posted

    Hi, were you able to solve this issue?


    I have already downloaded the lastest version of the ajax control toolkit and modified the .cs of the toolkitscriptmanager to include the solution proposed but nothing has changed, i see the same output when accesing the "hacked" url.  

    Friday, February 11, 2011 2:21 PM
  • User1531513703 posted

    Hi !

    No, i haven't found a way around it. I get the feeling that this must be a low impact issue, otherwise this forum would be more active! I haven't found any useful information on the web. Strange, huh?

    Saturday, February 12, 2011 10:45 AM
  • User-2105458902 posted

    ToolkitScriptManager -- XSS vulnerability  

    1. Implement X-XSS-Protection into web.config into customHeaders  
    1. Implement AntiXssEncoder globally or for certain pages in web.config into httpRuntime with encoderType=AntiXssEncoder  
    1. Fix ToolkitScriptManager.cs -> OutputCombinedScriptFile() with AntiXssLibrary


       5.  The different approach

    - Get lattes version of AjaxControlToolkit from github. Build it. Replace < ToolkitScriptManager > with < ScriptManager>

    • - Add new reference of \System.Web.Optimization.dll
    • - Add new reference of AjaxControlToolkit.dll

    The latest version of AjaxControlToolkit have alredy implement Sanitizer

    Just go and build $\AjaxControlToolkit-master.NEW\AjaxControlToolkit-master\AjaxControlToolkit.HtmlEditor.Sanitizer

    Add reference like test example project in AjaxControlToolkit solution.


    - By the way, according "...original reference for the toolkit code is wrong, and the correct reference is". 

    Nope!!! Original code is OK. The problem is not in reference at all. Microsoft did tell you the problem correctly. Just use this fix: 

    System.Web.Security.AntiXss.AntiXssEncoder.HtmlEncode(data,false), into OutputCombinedScriptFile() function.

    - If you want to fix the problem in new version then you need new approach. Use this fix:

    public class ToolkitScriptManager : ScriptManager{}

    Other solution is to use HtmlSanitizer . Here is example for test.


    Friday, February 22, 2019 8:18 PM