sDoraiswamy909497 (Community Member) asked a question.

February 6, 2019 at 11:18 AM
Addressing the XSS vulnerability in the jQuery .append() function

Hi Team,

 

When scanning one of our external libraries like https://cdnjs.cloudflare.com/ajax/libs/bootstrap-table/1.13.4/extensions/filter-control/bootstrap-table-filter-control.js

 

We find the flaw is reported in the code below,

$selectControl.append($('<option></option>').attr('value', value).text($('<div />').html(text).text()));

 

On analysis, we find that the above code is reported as a flaw due it the use of the .append function in jQuery stating that the above is vulnerable to XSS.

 

We have explored on the options to use the other equivalents but could not find ones.

 

Please suggest the suitable fix to address this use-case.

 

  • 3 answers
  • 6.66K views

  • Boy, Security Consultant (Veracode)

    HI @sDoraiswamy909497 (Community Member)​ ,

     

    Veracode Static Analysis is reporting a Basic XSS flaw for this JavaScript due to the use of the .html() function. As you are most likely aware of this function injects raw HTML into a DOM element, which if an attacker is able to use, they could abuse with XSS vectors like <script> or <img onerror> to run their script on your domain.

     

    Remediation for this type of vulnerability depends on how this is used. Typically Veracode Application Security Consulting recommends moving away from injecting raw HTML and instead using safer mechanisms like .textContent ( https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent ) to ensure a browser will not interpret any HTML.

     

    In this case it appears that this functionality is setting the incoming text to a div and then using .text() to get the text value. Presumably to turn something like "some <b>bold</b> text" into "some bold text" for use in dropdown controls for filtering a table.

    The danger with this is if the attacker is able to control 'text' they can cause their own HTML to be interpreted.

     

    Depending on your appetite for risk you can do either one of 2 things:

    1. Remediate by removing this functionality and just using 'text'. This would require forking the library and sending a pull request upstream. Possibly this behaviour can be made optional depending on a setting?
    2. Investigate all inputs and how they are used in your application and determine if they can be attacker controlled. If not, documenting this in a mitigation proposal ( https://help.veracode.com/reader/DGHxSJy3Gn3gtuSIN2jkRQ/~p4MSKOS8F8X8h0KwFTKoQ ) and having this reviewed by your security team.

     

    Remediation will remove the risk, even for all future usage of this functionality and is preferable though there may be business reasons for choosing mitigation. If you have any doubts on the best approach please contact your security team.

     

    Thank you,

    Boy Baukema

    Expand Post
    Selected as Best

  • Boy, Security Consultant (Veracode)

    HI @sDoraiswamy909497 (Community Member)​ ,

     

    Veracode Static Analysis is reporting a Basic XSS flaw for this JavaScript due to the use of the .html() function. As you are most likely aware of this function injects raw HTML into a DOM element, which if an attacker is able to use, they could abuse with XSS vectors like <script> or <img onerror> to run their script on your domain.

     

    Remediation for this type of vulnerability depends on how this is used. Typically Veracode Application Security Consulting recommends moving away from injecting raw HTML and instead using safer mechanisms like .textContent ( https://developer.mozilla.org/en-US/docs/Web/API/Node/textContent ) to ensure a browser will not interpret any HTML.

     

    In this case it appears that this functionality is setting the incoming text to a div and then using .text() to get the text value. Presumably to turn something like "some <b>bold</b> text" into "some bold text" for use in dropdown controls for filtering a table.

    The danger with this is if the attacker is able to control 'text' they can cause their own HTML to be interpreted.

     

    Depending on your appetite for risk you can do either one of 2 things:

    1. Remediate by removing this functionality and just using 'text'. This would require forking the library and sending a pull request upstream. Possibly this behaviour can be made optional depending on a setting?
    2. Investigate all inputs and how they are used in your application and determine if they can be attacker controlled. If not, documenting this in a mitigation proposal ( https://help.veracode.com/reader/DGHxSJy3Gn3gtuSIN2jkRQ/~p4MSKOS8F8X8h0KwFTKoQ ) and having this reviewed by your security team.

     

    Remediation will remove the risk, even for all future usage of this functionality and is preferable though there may be business reasons for choosing mitigation. If you have any doubts on the best approach please contact your security team.

     

    Thank you,

    Boy Baukema

    Expand Post
    Selected as Best

  • sDoraiswamy909497 (Community Member)

    Thanks for the reply.

    We mitigated the issue months back using our strategy and the project is completed,

    • CKONDURU100522 (Community Member)

      Hi ,

      Can you please help us how this issue is addressed? we are getting the same issue.

Topics (5)

No articles found
Loading

Ask the Community

Get answers, share a use case, discuss your favorite features, or get input from the community.